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" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > 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 > >[EMAIL PROTECTED] > > > > > >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 > ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org