Re: PG functions in Java: maybe use gcj? - Mailing list pgsql-hackers
From | Barry Lind |
---|---|
Subject | Re: PG functions in Java: maybe use gcj? |
Date | |
Msg-id | 3DC0AA42.4000205@xythos.com Whole thread Raw |
In response to | PG functions in Java: maybe use gcj? (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: PG functions in Java: maybe use gcj?
|
List | pgsql-hackers |
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? or 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/BEprotocol but instead probably use jni calls. thanks, --Barry 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 > gcj. > > 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@postgresql.org) >
pgsql-hackers by date: