On Tue, Apr 10, 2012 at 10:41 PM, Atri Sharma <atri.j...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
