On Thu, Aug 24, 2006 at 02:51:50AM -0400, Jasbinder Bali wrote:
> Well, the server side code is in ECPG because thats the easiest choice i
> could see.
> I really don't know how difficult or beneficial would SPI be. Haven't heard
> of SPI before.
> I was under the impression that ECPG and libpg are the only two choices a
> developer has in postgresql for database related activities.
ECPG and libpq are client libraries. Server-side functions can use
those libraries to make connections to the same or a different
database, but a function can use SPI to execute commands in the
same backend in which it's running without having to make a separate
client connection. That's more efficient and the commands the
function runs will be executed in the same transaction as the
function itself, so if the calling transaction rolls back then
statements the function executed will roll back. If the function
had executed statements over a separate connection, committed them,
and closed the connection, then those statements wouldn't roll back
even if the function's transaction rolled back.
> I am using char in postgres function as an analogue for char* in C. Is this
> correct?
> The link that you gave says varchar* in C has varchar as its analogue in
> postgresql.
If the function accepts a text argument then see the copytext() and
concat_text() examples that show how to work with such data. Look
at the examples that use the version-1 calling conventions, the
ones that are declared like this:
PG_FUNCTION_INFO_V1(copytext);
Datum
copytext(PG_FUNCTION_ARGS)
{
...
}
--
Michael Fuhr
