Horton
Menu

Thread

  1. ECPG: FETCH ALL|n FROM cursor - Memory allocation?

    Lee Kindness <lkindness@csl.co.uk> — 2002-04-25T11:42:00Z

    Assuming the following fetch statement in embedded SQL/C:

 EXEC SQL FETCH ALL IN selectFromTable_cur INTO
	:array1,
	:array2;

is memory automatically allocated (by experimentation I guess so)?
Should the input pointers be NULL initialised? How should the memory
be freed?

Assuming the following fetch statement:

 while( 1 )
 {
  EXEC SQL FETCH 1000 IN selectFromTable_cur INTO
	 :array1,
	 :array2;
  if( (sqlca.sqlcode < 0) || (sqlca.sqlcode != 0) )
   break;
 }

is memory automatically allocated (by experimentation I guess so)?
Should the input pointers be NULL initialised before each fetch, or
only before the first one? How should the memory be freed?

Any pointers to useful documentation?

Thanks, Lee Kindness.

  2. Re: ECPG: FETCH ALL|n FROM cursor - Memory allocation?

    Michael Meskes <meskes@postgresql.org> — 2002-04-25T13:07:13Z

    On Thu, Apr 25, 2002 at 12:42:00PM +0100, Lee Kindness wrote:
> Assuming the following fetch statement in embedded SQL/C:
> 
>  EXEC SQL FETCH ALL IN selectFromTable_cur INTO
> 	:array1,
> 	:array2;
> 
> is memory automatically allocated (by experimentation I guess so)?

Only if the pointers are NULL. If they have a value libecpg assumes that
this value points to enough memory to store all data.

> 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.

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

  3. Re: [INTERFACES] ECPG: FETCH ALL|n FROM cursor - Memory allocation?

    Christof Petig <christof@petig-baender.de> — 2002-05-06T07:37:18Z

    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

  4. Re: [INTERFACES] ECPG: FETCH ALL|n FROM cursor - Memory allocation?

    Lee Kindness <lkindness@csl.co.uk> — 2002-05-06T10:24:36Z

    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
 >

  5. Re: [INTERFACES] ECPG: FETCH ALL|n FROM cursor - Memory allocation?

    Michael Meskes <meskes@postgresql.org> — 2002-05-06T10:59:58Z

    On Mon, May 06, 2002 at 09:37:18AM +0200, Christof Petig wrote:
> 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 

That's why I discourage the usage of ECPGfree_auto_mem by the user.
There is only one reason why the symbol is not static and that is that
it is used by another module in libecpg.

I never thought about this as an end user routine, it's just meant as a
clean up method in case of an error during statement execution.

BTW Christof, ECPGfree_auto_mem is used by testdynalloc.pgc. Maybe we
should change that.

> this method (any allocated memory regions are stored in a list, if you 
> never call ECPGfree_auto_mem, this list grows and grows).

That is not true. Before a statement is executed libecpg calls
ECPGclear_auto_mem which just frees ecpg's own structure but not the
memory used for data.

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

  6. Re: [INTERFACES] ECPG: FETCH ALL|n FROM cursor - Memory allocation?

    Michael Meskes <meskes@postgresql.org> — 2002-05-06T11:00:51Z

    On Mon, May 06, 2002 at 11:24:36AM +0100, Lee Kindness wrote:
> 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?

No. No matter who allocates the memory. You have to free it yourself.

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

  7. Re: [INTERFACES] ECPG: FETCH ALL|n FROM cursor - Memory allocation?

    Christof Petig <christof@petig-baender.de> — 2002-05-06T12:47:31Z

    Lee Kindness wrote:
> 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?

No, I only said: Never mix free and ECPGfree_auto_mem because 
ECPGfree_auto_mem will double free it if you free'd it already.

And also: it might be a good idea to kill the undocumented function (and 
the list).

And: You need to free it (by one of the two methods above).

> 
> I think this highlights the need for some documentation on this
> aspect.

Yes it does.

   Christof