pljava revisited

From: "Thomas Hallgren" <thhal(at)mailblocks(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: pljava revisited
Date: 2003-12-10 15:18:59
Message-ID: br7dbl$2q2i$1@news.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,
I'm working on a new pl/java prototype that I hope will become production
quality some time in the future. Before my project gets to far, I'd like to
gather some input from other users. I've taken a slightly different approach
than what seems to be the case for other attempts that I've managed to dig
up. Here's some highlights in my approach:

1. A new Java VM is spawned for each connection. I know that this will give
a performance hit when a new connection is created. The alternative however,
implies that all calls becomes inter-process calls which I think is a much
worse scenario. Especially since most modern environments today has some
kind of connection pooling. Another reason is that the connections
represents sessions and those sessions gets a very natural isolation using
separate VM's. A third reason is that the "current connection" would become
unavailable in a remote process (see #5).

2. There's no actual Java code in the body of a function. Simply a reference
to a static method. My reasoning is that when writing (and debugging) java,
you want to use your favorite IDE. Mixing Java with SQL just gets messy.

3. As opposed to the Tcl, Python, and Perl, that for obvious reasons uses
strings, my pl/java will use native types wherever possible. A flag can be
added to the function definition if real objects are preferred instead of
primitives (motivated by the fact that the primitives cannot reflect NULL
values).

4. The code is actually written using JNI and C++ but without any templates,
no &-style object references, no operator overloads, external class
libraries etc. I use C++ simply to get better quality, readability and
structure on the code.

5. I plan to write a JDBC layer using JNI on top of the SPI calls to enable
JDBC functionality on the current connection. Some things will be limited
(begin/commit etc. will not be possible to do here for instance).

Current status is that my first calls from Postgres to Java has been made.
Lot's of work remain.

What are your thoughts and ideas?

Thomas Hallgren

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2003-12-10 15:30:22 Re: ERROR: Index pg_toast_8443892_index is not a btree
Previous Message Florian G. Pflug 2003-12-10 13:57:08 Re: Strange permission problem regarding pg_settings