Minutes from Pl/Java - next step IRC - Mailing list pgsql-hackers

Participants
Dave Cramer
Thomas Hallgren
Laszlo Hornyak

Throughout this document, the solutions are called Pl/J (using remote calls
and one JVM) and Pl/Java (using one JVM per connection).

1. Common interfaces.
Laszlo provided Thomas with an URL so that he could download their solution.
We agreed that the ISO standard should be used as the common denominator
when possible. The PostgreSQL parser will need a couple of changes in order
to accomodate the standard. Thomas expressed some concern regarding the ISO
proposal regarding how to resolve classes in jars since it violates standard
Java loader semantics . Laszlo agreed.

1a. Common interface for maintaining jar files:
Laszlo didn't have any solution other than a file system based classloader
yet. Thomas suggested that they'd use his. It allowes jar files to be loaded
into the database, execution of associated deployment scripts, and comes
with a class loader optimized for database loading.

There was some discussions regarding the feasibility to store the jar files
in the database versus storing them in the file system. Thomas explained
that storing them in the file system was bad, because it a) assumes that the
user of Pl/Java have access to the filesystem on the server and b) will be
very hard to control using GRANT/REVOKE permissions on the code as such and
c) is non-standard.

1b. Common interface for the functions:
The Pl/J solution doesn't have triggers. Pl/J comes with an extendable type
system that Laszlo is thinking of marrying with PostgreSQL's own system.
Thomas concurred. Set's and Tuples are not supported by Pl/J. Thomas again
suggested that Pl/J could borrow this from Pl/Java since the latter
implements this using java.sql.ResultSet and this is what ISO suggests.
Laszlo was willing to do this as long as it didn't tie his solution to
PostgreSQL. One of the objectives with Pl/J is to be database independent.

2. Things to collaborate on.
We agreed that Pl/J should look at the jar management functionality from
Pl/Java. We also agreed that Pl/J should look at the handling of Triggers,
and passing of Set's and Complex Types implemented by Pl/Java. Thomas
downloaded the Pl/J project and is currently examining its interfaces to see
if there's anything that can be used in Pl/Java.

3. Sharing C-code:
We decided not to attempt sharing on the C-code level. The objectives for
the projects are different. Pl/J is aimed to be database agnostic while
Pl/Java is written exclusively for PostgreSQL. Laszlo and Dave don't want to
worry about call optimization in the first iteration. Thomas thinks that the
design patterns as such must be different in a solution that uses IPC.
Thomas also referred to the post he made on this thread (as a reply to Rob)
where he gave his view on sharing C-code.

We agreed that this should be no problem. Pl/J does not aim to be part of
the PostgreSQL distribution. Pl/Java might, but if it does, it will be as
one of the pl<lang> modules and thus, somewhat separate anyway.