Skip site navigation (1) Skip section navigation (2)

Re: PG functions in Java: maybe use gcj?

From: Barry Lind <blind(at)xythos(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: PG functions in Java: maybe use gcj?
Date: 2002-10-31 03:57:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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?


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
> 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(at)postgresql(dot)org)

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2002-10-31 03:59:39
Subject: Re: Turning the PLANNER off
Previous:From: Tom LaneDate: 2002-10-31 03:45:44
Subject: Re: float output precision questions

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group