
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


Sun, 29 Feb 2004 14:20:19 -0500
Andrew Dunstan <andrew@dunslane.net>
Server Side PL support

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 calls
>
>Note 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.com
>
>
>On 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
>>    
>>
>
>  
>


Sun, 29 Feb 2004 18:40:59 -0500
Andrew Dunstan <andrew@dunslane.net>
Re: Server Side PL support
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...
>
> 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 calls
> >
> >Note 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.com
> >
> >
> >On 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?
>
>                http://archives.postgresql.org
>



Mon, 1 Mar 2004 21:10:47 +0100
"Thomas Hallgren" <thhal@mailblocks.com>
Re: Server Side PL support