Re: ECPG: FETCH ALL|n FROM cursor - Memory allocation? - Mailing list pgsql-interfaces

From Lee Kindness
Subject Re: ECPG: FETCH ALL|n FROM cursor - Memory allocation?
Date
Msg-id 15574.23012.920919.499183@kelvin.csl.co.uk
Whole thread Raw
In response to Re: ECPG: FETCH ALL|n FROM cursor - Memory allocation?  (Christof Petig <christof@petig-baender.de>)
Responses Re: ECPG: FETCH ALL|n FROM cursor - Memory allocation?  (Michael Meskes <meskes@postgresql.org>)
List pgsql-interfaces
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:>
>>Shouldthe input pointers be NULL initialised? How should the memory> >>be freed?> > > > > > A simple free() will do.
Youalso 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
thesetwo! ECPGfree_auto_mem will free even memory > which has already been free'd by the user, perhaps we should get
ridof > this method (any allocated memory regions are stored in a list, if you > never call ECPGfree_auto_mem, this
listgrows and grows).> >     Christof> 
 


pgsql-interfaces by date:

Previous
From: Kenny Carruthers
Date:
Subject: Using C functions with triggers
Next
From: Michael Meskes
Date:
Subject: Re: ECPG: FETCH ALL|n FROM cursor - Memory allocation?