"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