Обсуждение: Pl/Java and GCJ
Hi, I've made some very encouraging tests using The GNU version of Java known as GCJ together with my Pl/Java implementation . At present I use GCJ just like any other JVM, i.e. as an interpreter. This is not very optimal since GCJ can compile all Java code into shared libraries just like it would compile C or C++ code. Putting it short, there's a tradeoff between adhering to the proposed standard for SQL/Java mapping and using precompiled shared objects. Pre-loaded modules loaded by the postmaster for instance, can never be standard although it will help boost performance a great deal. I guess that extending the proposed functionality is OK as long as attempts are made to follow the standard whenever possible. To do this, I'd like some advice concerning loading of shared libraries that are the result of a jar file gcj compilation. Today, using a "normal" JVM, I can install modules in the form of jar files into the database. The modules can then be used dynamically and on demand by Pl/Java. Using GCJ, I'd like to have the same semantics from a user perspective (since they are modelled from the standard proposal) but behind the scene the jar file should be compiled into a shared library which then is made available to postgres. Question is, where do I store the shared object, and how do I load it? Ideally, I'd like it to be stored in the database and subject to normal grant/revoke rights etc. but dlopen() will hardly look there. So instead, I'd like to store it somewhere in the filesystem on the server where postmaster runs. Is PostgreSQL doing something similar in other places today (i.e. install a shared library on the server using SQL commands issued from the client)? Any thoughts and/or ideas on this are greatly appreciated. More on Pl/Java here: http://gborg.postgresql.org/project/pljava Kind Regards, Thomas Hallgren
Thomas Hallgren wrote: > Hi, > I've made some very encouraging tests using The GNU version of Java known as > GCJ together with my Pl/Java implementation . At present I use GCJ just like > any other JVM, i.e. as an interpreter. This is not very optimal since GCJ > can compile all Java code into shared libraries just like it would compile C > or C++ code. > > Putting it short, there's a tradeoff between adhering to the proposed > standard for SQL/Java mapping and using precompiled shared objects. > Pre-loaded modules loaded by the postmaster for instance, can never be > standard although it will help boost performance a great deal. > > I guess that extending the proposed functionality is OK as long as attempts > are made to follow the standard whenever possible. To do this, I'd like some > advice concerning loading of shared libraries that are the result of a jar > file gcj compilation. > > Today, using a "normal" JVM, I can install modules in the form of jar files > into the database. The modules can then be used dynamically and on demand by > Pl/Java. Using GCJ, I'd like to have the same semantics from a user > perspective (since they are modelled from the standard proposal) but behind > the scene the jar file should be compiled into a shared library which then > is made available to postgres. Question is, where do I store the shared > object, and how do I load it? Ideally, I'd like it to be stored in the > database and subject to normal grant/revoke rights etc. but dlopen() will > hardly look there. So instead, I'd like to store it somewhere in the > filesystem on the server where postmaster runs. > > Is PostgreSQL doing something similar in other places today (i.e. install a > shared library on the server using SQL commands issued from the client)? Any > thoughts and/or ideas on this are greatly appreciated. It seems this would be handled just like we handle C functions today, that is you create a shared object file, it sits in the file system, and you LOAD the object into your backend, or you record it via CREATE FUNCTION and specify the pathname. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
"Bruce Momjian" <pgman@candle.pha.pa.us> wrote in message > It seems this would be handled just like we handle C functions today, > that is you create a shared object file, it sits in the file system, and > you LOAD the object into your backend, or you record it via CREATE > FUNCTION and specify the pathname. > I'm not sure that just handling it as C functions will get me what I want. Consider the following use-case: 1. A user starts a psql client to a server. The user has no access to the file system on the server. 2. Using the psql, a jar file is installed in some schema using the sqlj.install_jar function (provided by pl/java). The jar contains a deployment descriptor (i.e. SQL commands that executes the necessary 'CREATE FUNCTION', etc.). 3. The user uses some installed function. This works today using interpreted code and I don't want the user interaction changed when the code is compiled. I.e. I'd like for my gcj version of Pl/Java to automatically compile the .jar file into a shared object (on demand in step 3), store it so that it doesn't conflict with other shared objects, but still be able to handle permissions (GRANT/REVOKE) etc. correctly on the corresponding jar entries in the table. In essence, the server will perform the compilation "on the fly" and needs a place in the filesystem where it can store the result. Perhaps a directory in the current database root would be sufficient and then name the objects using the OID of the entry in the jar table? Associated triggers would remove the file when the corresponding row is deleted. I want Pl/Java to be housebroken, so if there's any conventions that could be applied here, please let me know. - thomas