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: