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
>