I am not sure I follow. Are you suggesting:
1) create function takes java source and then calls gcj to compile it
to native and build a .so from it that would get called at runtime?
2) create function takes java source and just compiles to java .class
files and the runtime invokes the gcj java interpreter.
or I guess you could do both at the same time.
In either case I am concerned about licensing issues. gcj is not under
a BSD style license. Depending on what you need you are either dealing
with regular GPL, LGPL, or LGPL with a special java exception.
I beleive (without giving it too much thought) that doing either 1 or 2
above would end up linking GPL code into postgres. This can be worked
around by requiring the the necessary gcj libraries be installed
separately and detected at configure time (like is done elsewhere). But
is does (I think) present a problem for commercial products that would
like to redistribute postgres with pljava.
Another challenge here it that the java code is going to want to use the
jdbc api when communicating with the database. One difficulty here is
getting jdbc to be part of the same transaction as the calling java
function. Such that if the java stored procedure selects or updates
data it is doing it in the same transaction as the caller of the
function. Today the jdbc driver only knows how to communicate via the
FE/BE protocol which will end up creating a new process and transaction.
The jdbc driver would need to not use the FE/BE protocol but instead
probably use jni calls.
Tom Lane wrote:
> I had an interesting conversation today with Tom Tromey and Andrew Haley
> of Red Hat about how to implement "pljava" for Postgres. Rather than
> futzing with an external JVM, their thought is to use gcj (gcc compiling
> Java). It sounds like this approach would mostly just work, modulo
> needing to use a small amount of C++ code to call the defined APIs for
> This would not be a perfect solution: gcj isn't yet ported everywhere,
> and it would probably not play nice on machines where the standard C
> library isn't thread-safe. But it seems a lot more within reach than
> the approaches we've discussed in the past.
> I'm not volunteering to try to do this, but I wanted to toss the idea
> up in the air and see if anyone wants to try it. Tom and Andrew
> indicated they'd be willing to help out with advice etc for anyone
> who wants to take on the project.
> regards, tom lane
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2002-10-31 03:59:39|
|Subject: Re: Turning the PLANNER off |
|Previous:||From: Tom Lane||Date: 2002-10-31 03:45:44|
|Subject: Re: float output precision questions |