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

From: Michael Meskes <meskes(at)postgresql(dot)org>
To: Lee Kindness <lkindness(at)csl(dot)co(dot)uk>
Cc: PostgreSQL Interfaces <pgsql-interfaces(at)postgresql(dot)org>, Mark Aves <maves(at)csl(dot)co(dot)uk>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ECPG: FETCH ALL|n FROM cursor - Memory allocation?
Date: 2002-04-25 13:07:13
Message-ID: 20020425130713.GC10341@feivel.credativ.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-interfaces

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(at)Fam-Meskes(dot)De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message mlw 2002-04-25 13:49:40 Re: Block size: 8K or 16K?
Previous Message mlw 2002-04-25 13:04:07 Block size: 8K or 16K?

Browse pgsql-interfaces by date

  From Date Subject
Next Message Lee Kindness 2002-04-25 14:11:20 ecpg error code -601
Previous Message Lee Kindness 2002-04-25 11:42:00 ECPG: FETCH ALL|n FROM cursor - Memory allocation?