Re: [JDBC] Regarding GSoc Application - Mailing list pgsql-hackers

>>  I agree that JNI isn't required -- we're going to
>> have to study the pl/java system a bit to determine the best way to
>> hook in.  This could end up getting us into the 'biting of more than
>> can chew' territory admittedly, but Atri is enthusiastic and wants to
>> give it a go.
>
>Well. maybe I spoke too soon...JNI is probably the best route.  Since
>SPI is off the table, all we're really pulling in from pl/java is the
>(non-trivial) proper installation of a jvm into a postgres process.
>pl/java is essentially a wrapper to JNI that does postgres to jni type
>conversion and builds a database driven class lookup system that
>allows building the java environment inside the database.   That part
>is not needed at all; since we're not going to install our routines as
>pl/java installed they will be installed into a separate and more
>typical class path from a jvm point of view. There are no exposed
>routines in pljava.so that allow for easy manual invocation of a java
>routine -- it's all pretty much hardwired to the language function
>call handler system.
>
>This begs the question about why pl/java should be used at all. Well,
>as I said the jvm insertion into postgres is non-trivial so that alone
>is worth something.  Maybe though we should just rip out the jvm guts
>that we really need (mostly some parts of backend.c and some of the
>type files) and do a completely standalone jni wrapper.  pl/java's
>build system is a mess anyways so we're not losing all that much in
>trying to go off on our own and do something.  OTOH, throwing a build
>system on top of the growing pile of things to do is turning this into
>a daunting project vs the (admittedly cobbled together) approach I was
>hoping to do earlier.  Anyways, it's really Atri's call if he's
>comfortable proceeding.

Hi All,

I think we are back on the initial approach I proposed(hooking directly into
the JVM and executing Java code that calls JDBC).I think the best way to do
this is create a JVM that executes the Java code and give the control of the
JVM to the native API.

I agree,the only need of Pl/Java that is apparent here is the need of the
Java internals(JDK et al).If we set them up independently,then,we can have
the FDW wrapping JDBC directly through JNI.JNI would call pure Java
functions to connect to the JDBC.

I think we can proceed with this.Once we are done with the API calling Java
functions,I think the rest of the path is easily mapped(writing Java
functions to connect to JDBC).

Please let me know your opinions on this.

Atri