Re: [JDBC] Regarding GSoc Application

On Wed, Apr 11, 2012 at 8:17 PM, Atri Sharma <atri(dot)jiit(at)gmail(dot)com> wrote:
>
> 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
>

Hi all,

I just had a small doubt I wanted to clarify.I initially said in my
proposal that I would be using SPI for getting the FDW API to call
Pl/Java functions,but now,after discussion with the community,I have
changed the approach and I will be using JNI Invocation API instead
for the same purpose.

I wanted to know if I need to send a modified proposal for the same or
the original proposal shall still hold good.

Atri

--
Regards,

Atri
l'apprenant