On Tue, Apr 10, 2012 at 11:07 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
> 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.
merlin
