Actually my function accepts char, so what should be the SQL analogue for
that in postgres?
Thanks,
Jas
On 8/24/06, Michael Fuhr <mike(at)fuhr(dot)org> wrote:
>
> 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
>