Re: Package support for Postgres - Mailing list pgsql-hackers

From Bill Studenmund
Subject Re: Package support for Postgres
Date
Msg-id Pine.NEB.4.33.0110170601040.3492-100000@vespasia.home-net.internetconnect.net
Whole thread Raw
In response to Re: Package support for Postgres  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Package support for Postgres
List pgsql-hackers
On Thu, 18 Oct 2001, Peter Eisentraut wrote:

> Bill Studenmund writes:
>
> > Could you please give me an example of how to do this, say for plperl or
> > plpython? Just showing how two functions made with CREATE FUNCTION can use
> > global variables will be fine. This example will help me understand how
> > they work.
>
> For PL/Tcl you use regular Tcl global variables:
>
> create function produce(text) returns text as '
>     global foo; set foo $1;
> ' language pltcl;
>
> create function consume() returns text as '
>     global foo; return $foo;
> ' language pltcl;
>
> There is also a mechanism for one procedure to save private data across
> calls.
>
> For PL/Python you use a global dictionary:
>
> create function produce(text) returns text as '
>     GD["key"] = args[0]
> ' language plpython;
>
> create function consume() returns text as '
>     return GD["key"]
> ' language plpython;
>
> There is also a dictionary for private data.

Private to what?

> For PL/Perl I'm not sure if something has been implemented.  In C you can
> use shared memory, and for PL/sh you would use temp files of course.  ;-)

Thank you. I can now experiment with them to see how they do.

I've never thought of adding package variables for C routines; there are
other options open. :-)

Oh, by shared memory, do you mean SYSV Shared Memory (like how the
backends talk) or just memory shared between routines? I ask as part of
the idea with these variables is that they are backend-specific. So C
routines actually should NOT used SYSV Shared Mem. :-)

Take care,

Bill



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PQstatus() detect change in connection...
Next
From: Tom Lane
Date:
Subject: Re: may be bug in pg_dumpall in 7.0.3