Re: [JDBC] Regarding GSoc Application

On Tue, Apr 10, 2012 at 10:41 PM, Atri Sharma <atri(dot)jiit(at)gmail(dot)com> wrote:
>>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).

yeah -- it sound plausible. I think the next step is to pull one of
the fdw projects that is working and currently builds with pgxs. Make
sure it is bsd licensed and that you retain the original copyright in
the code (feel free to add your own). The mysql_fdw project for
example is a good candidate. After that we need to strip out all the
mysql specific parts so that we have a basic skeleton of the fdw
wrapper that still builds. From there we will need to build in the
jni calls as well as jvm initialization code we are going to more or
less directly copy from pl/java, but one thing at a time: IMO,
getting the jvm installed and executing a 'hello world' jni is a good
milestone to reach before getting into all the mechanics of the remote
querying.

The jvm initialization code in pl/java we are going to use is in
src/C/pljava/backend.c. A lot of the initialization work done there
is irrelevant to what we are trying to do but there are some very
important bits like the on_proc_exit handler that does cleanup when
the postgres process exits. Ideally we can drop just the stuff we
need from there and get our project to compile.

merlin