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
 >