Re: ECPG: FETCH ALL|n FROM cursor - Memory allocation?
От | Lee Kindness |
---|---|
Тема | Re: ECPG: FETCH ALL|n FROM cursor - Memory allocation? |
Дата | |
Msg-id | 15574.23012.920919.499183@kelvin.csl.co.uk обсуждение исходный текст |
Ответ на | Re: ECPG: FETCH ALL|n FROM cursor - Memory allocation? (Christof Petig <christof@petig-baender.de>) |
Ответы |
Re: ECPG: FETCH ALL|n FROM cursor - Memory allocation?
|
Список | 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 по дате отправления: