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.
>

I agree,atm I'll work on getting JNI set up and to build a JVM using it and
getting the "Hello,World" running in it in PostGreSQl.

I'll keep you posted,

Atri