Server Side PL support
I have been taking a brief look at pltcl, and particularly its ability
to preload modules. By comparison with most of the core product this
seems to be somewhat out of date and unpolished (e.g. hardcoded path to
libpgtcl.so, no use of schemas for the supporting tables, lack of
comments). Since my understanding of tcl is extremely rusty, I didn't
dig further than that. However, I am interested in getting a similar
facility working for plperl, and thus wanted to start a discussion on
what general facilities could/should be made available to server side
PLs. Or should we just assume that each PL will create it's own support
tables?
cheers
andrew
Yes. I am looking at a few of these things (preloading, intra-perl
calling, array and tuple return), and I understand that CommandPrompt is
doing some plperl work too. They already have a plperl which does
triggers. My question was not "what functionality do we need from PLs?"
but rather "what do PLs need from the core for good support?" I
particularly had catalog support in mind, but there could be other areas
too.
I'm glad to see you support the efforts to make plperl something more
useful. One idea I had for a GForge/GBorg project when that gets going
is a place for collaborating on experimental plperl work, before it gets
merged back to the core.
cheers
andrew
elein wrote:
Show quoted text
This is a very interesting topic. Joe Conway
has a very good idea of pl requirements since
he just implemented pl/R.Some requirements for pl languages are these:
* support query execution
* support trigger functions
* allocating storage for per statement function calls
This is like the SD[] dictionary in plpythonu.
* support for all built-in datatypes, e.g. easy
array support for pl languages which have
natural arrays, sets or dictionaries.
* enable easy fastpath functionality
or similar pl to pl function callsNote that array support, trigger and query support
for plperl does not yet exist.IMHO extended support for plperl should have a relatively
high priority. We are actively reaching out to the
perl community and full support of the interface is
important. Collaboration on the implementation is
also possible--it has been discussed with some perl folks.elein
elein@varlena.comOn Sun, Feb 29, 2004 at 02:20:19PM -0500, Andrew Dunstan wrote:
I have been taking a brief look at pltcl, and particularly its ability
to preload modules. By comparison with most of the core product this
seems to be somewhat out of date and unpolished (e.g. hardcoded path to
libpgtcl.so, no use of schemas for the supporting tables, lack of
comments). Since my understanding of tcl is extremely rusty, I didn't
dig further than that. However, I am interested in getting a similar
facility working for plperl, and thus wanted to start a discussion on
what general facilities could/should be made available to server side
PLs. Or should we just assume that each PL will create it's own support
tables?cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
Import Notes
Reply to msg id not found: 20040229113754.B25767@cookie.varlena.com
The Pl/Java (the JNI version) will utilize a class loader that uses tables
in the SQLJ schema. Java has a fairly extensive mechanism for "module"
loading so I think it's hard to collaborate on that.
The Java standard came up with an idea that I think is pretty neat that
other pl<lang>'s might use. When a module (a jar file) is initially loaded
into the database, it may contain a deployment descriptor that contains SQL
statements that will be executed. Typically those statements creates
functions, grants access etc. A corresponding descriptor exists for unload.
Regarding the lib<language>.so as such, I think it would be very nice if
PostgreSQL followed the standard and prepended "lib" to the library name on
a Unix machine (I want the SQL create statement for the module should refer
to "pljava" regardless of operating system). I can't name the library
pljava.so on Unix since the Java loader will expect the standard name.
Regards,
Thomas Hallgren
"Andrew Dunstan" <andrew@dunslane.net> wrote in message
news:4042788B.4040007@dunslane.net...
Show quoted text
Yes. I am looking at a few of these things (preloading, intra-perl
calling, array and tuple return), and I understand that CommandPrompt is
doing some plperl work too. They already have a plperl which does
triggers. My question was not "what functionality do we need from PLs?"
but rather "what do PLs need from the core for good support?" I
particularly had catalog support in mind, but there could be other areas
too.I'm glad to see you support the efforts to make plperl something more
useful. One idea I had for a GForge/GBorg project when that gets going
is a place for collaborating on experimental plperl work, before it gets
merged back to the core.cheers
andrew
elein wrote:
This is a very interesting topic. Joe Conway
has a very good idea of pl requirements since
he just implemented pl/R.Some requirements for pl languages are these:
* support query execution
* support trigger functions
* allocating storage for per statement function calls
This is like the SD[] dictionary in plpythonu.
* support for all built-in datatypes, e.g. easy
array support for pl languages which have
natural arrays, sets or dictionaries.
* enable easy fastpath functionality
or similar pl to pl function callsNote that array support, trigger and query support
for plperl does not yet exist.IMHO extended support for plperl should have a relatively
high priority. We are actively reaching out to the
perl community and full support of the interface is
important. Collaboration on the implementation is
also possible--it has been discussed with some perl folks.elein
elein@varlena.comOn Sun, Feb 29, 2004 at 02:20:19PM -0500, Andrew Dunstan wrote:
I have been taking a brief look at pltcl, and particularly its ability
to preload modules. By comparison with most of the core product this
seems to be somewhat out of date and unpolished (e.g. hardcoded path to
libpgtcl.so, no use of schemas for the supporting tables, lack of
comments). Since my understanding of tcl is extremely rusty, I didn't
dig further than that. However, I am interested in getting a similar
facility working for plperl, and thus wanted to start a discussion on
what general facilities could/should be made available to server side
PLs. Or should we just assume that each PL will create it's own support
tables?cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?