Re: [INTERFACES] ECPG: FETCH ALL|n FROM cursor - Memory allocation?
Lee Kindness <lkindness@csl.co.uk>
From: Lee Kindness <lkindness@csl.co.uk>
To: Christof Petig <christof@petig-baender.de>
Cc: Michael Meskes <meskes@postgresql.org>,
Lee Kindness <lkindness@csl.co.uk>, PostgreSQL Interfaces <pgsql-interfaces@postgresql.org>, Mark Aves <maves@csl.co.uk>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2002-05-06T10:24:36Z
Lists: pgsql-hackers
Okay, lets see if i've got this right... If I allocate the memory before the FETCH then I (naturally) free it. However If I NULL initialise the pointer then libecpg will allocate the memory and I must NOT free it - libecpg will free it automatically... Yeah? I think this highlights the need for some documentation on this aspect. Regards, Lee Kindness. Christof Petig writes: > Michael Meskes wrote: > > On Thu, Apr 25, 2002 at 12:42:00PM +0100, Lee Kindness wrote: > >>Should the input pointers be NULL initialised? How should the memory > >>be freed? > > > > > > A simple free() will do. You also can free all automatically > > allocated memory from the most recent executed statement by calling > > ECPGfree_auto_mem(). But this is not documented and will never be. > > > > The correct way is to free(array1) and free(array2) while libecpg will > > free the internal structures when the next statement is executed. > > Never, never mix these two! ECPGfree_auto_mem will free even memory > which has already been free'd by the user, perhaps we should get rid of > this method (any allocated memory regions are stored in a list, if you > never call ECPGfree_auto_mem, this list grows and grows). > > Christof >