Add to java.

diff --git a/doc/TODO.detail/java b/doc/TODO.detail/java
index 27ba4a9dc72c0735210a72fbe97c6df0331257a4..3fa9d517c2d2b8e1f9ffb9e69c5a6e26a029555e 100644 (file)
--- a/doc/TODO.detail/java
+++ b/doc/TODO.detail/java
@@ -965,3 +965,139 @@ TIP 5: Have you checked our extensive FAQ?
 
 http://www.postgresql.org/users-lounge/docs/faq.html
 
+From [email protected] Mon Dec  3 13:53:24 2001
+Return-path: <[email protected]>
+Received: from west.navpoint.com (west.navpoint.com [207.106.42.13])
+       by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fB3IrNS29264
+       for <[email protected]>; Mon, 3 Dec 2001 13:53:24 -0500 (EST)
+Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
+       by west.navpoint.com (8.11.6/8.10.1) with ESMTP id fB3IrO213373
+       for <[email protected]>; Mon, 3 Dec 2001 13:53:24 -0500 (EST)
+Received: from postgresql.org (postgresql.org [64.49.215.8])
+       by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id fB3Iq1N35610
+       for <[email protected]>; Mon, 3 Dec 2001 12:52:02 -0600 (CST)
+       (envelope-from [email protected])
+Received: from tiger.tigrasoft (fw.tigrasoft.hu [195.70.42.161])
+       by postgresql.org (8.11.3/8.11.4) with ESMTP id fAU95km73601
+       for <[email protected]>; Fri, 30 Nov 2001 04:05:46 -0500 (EST)
+       (envelope-from [email protected])
+Received: from freemail.hu ([192.168.0.200])
+       by tiger.tigrasoft (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id KAA11457
+       for <[email protected]>; Fri, 30 Nov 2001 10:05:45 +0100
+X-Authentication-Warning: tiger.tigrasoft: Host [192.168.0.200] claimed to be freemail.hu
+Message-ID: <[email protected]>
+Date: Fri, 30 Nov 2001 10:14:12 +0100
+From: Laszlo Hornyak <[email protected]>
+Reply-To: [email protected]
+User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913
+X-Accept-Language: hu, en-us
+MIME-Version: 1.0
+To: [email protected]
+Subject: [GENERAL] java stored procedures
+Content-Type: text/plain; charset=us-ascii; format=flowed
+Content-Transfer-Encoding: 7bit
+Precedence: bulk
+Sender: [email protected]
+Status: OR
+
+Hi!
+
+A few months ago I asked if anyone started working on PL/JAVA, the 
+ansver was no. Now I started to write a java stored procedure language 
+and environment for PostgreSQL. Some code is already working, and it is 
+geting interresting. So, I would like to ask you to write me your ideas, 
+suggestions, etc for this environment.
+The source code will be available under GPL when it is worth for 
+distributing it (this will take for a while).
+thanks.
+
+Laszlo Hornyak
+
+
+---------------------------(end of broadcast)---------------------------
+TIP 4: Don't 'kill -9' the postmaster
+
+From [email protected] Tue Dec  4 13:14:09 2001
+Return-path: <[email protected]>
+Received: from west.navpoint.com (west.navpoint.com [207.106.42.13])
+       by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fB4IE3r15972
+       for <[email protected]>; Tue, 4 Dec 2001 13:14:04 -0500 (EST)
+Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
+       by west.navpoint.com (8.11.6/8.10.1) with ESMTP id fB4IE2Y07122
+       for <[email protected]>; Tue, 4 Dec 2001 13:14:02 -0500 (EST)
+Received: from postgresql.org (postgresql.org [64.49.215.8])
+       by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id fB4I9HN76662
+       for <[email protected]>; Tue, 4 Dec 2001 12:09:17 -0600 (CST)
+       (envelope-from [email protected])
+Received: from belphigor.mcnaught.org ([216.151.155.121])
+       by postgresql.org (8.11.3/8.11.4) with ESMTP id fB4Hwsm96365;
+       Tue, 4 Dec 2001 12:58:59 -0500 (EST)
+       (envelope-from [email protected])
+Received: (from doug@localhost)
+       by belphigor.mcnaught.org (8.11.6/8.9.3) id fB4Hwlo07786;
+       Tue, 4 Dec 2001 12:58:47 -0500
+X-Authentication-Warning: belphigor.mcnaught.org: doug set sender to [email protected] using -f
+To: Barry Lind <[email protected]>
+cc: Laszlo Hornyak <[email protected]>, [email protected],
+   [email protected]
+Subject: Re: [GENERAL] java stored procedures
+References: <[email protected]> <[email protected]>
+       <[email protected]> <[email protected]>
+From: Doug McNaught <[email protected]>
+Date: 04 Dec 2001 12:58:47 -0500
+In-Reply-To: Barry Lind's message of "Tue, 04 Dec 2001 08:44:50 -0800"
+Message-ID: <[email protected]>
+Lines: 42
+User-Agent: Gnus/5.0806 (Gnus v5.8.6) XEmacs/21.1 (20 Minutes to Nikko)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=us-ascii
+Precedence: bulk
+Sender: [email protected]
+Status: OR
+
+Barry Lind <[email protected]> writes:
+
+> Having one jvm that all the postgres backend processes communicate with makes
+> the whole feature much more complicated, but is necessary in my opinion.
+
+Agreed.  Also, the JVM is a multithreaded app, and running it inside a
+non-threaded program (the backend) might cause problems. 
+
+> Then the question becomes how does the jvm process interact with the database
+> since they are two different processes.  You will need some sort of
+> interprocess communication between the two to execute sql statements.  This
+> could be accomplished by using the existing jdbc driver.  But the bigest
+> problem here is getting the transaction semantics right.  How does a sql
+> statement being run by a java stored procedure get access to the same
+> connection/transaction as the original client?  What you don't want happening
+> is that sql issued in a stored java procedure executes in a different
+> transaction as the caller, what would rollback of the stored function call
+> mean in that case?
+
+I think you would have to to expose the SPI layer to Java running in a
+separate process, either using an RMI server written in C or a custom
+protocol over a TCP socket (Java of course can't do Unix sockets).
+This raises some thorny issues of authentication and security but I
+don't think they're insurmountable.  You could, for example, create a
+cryptographically strong "cookie" in the backend when a Java function
+is called.  The cookie would be passed to the Java function when it
+gets invoked, and then must be passed back to the SPI layer in order
+for the latter to accept the call.  A bit clunky but should be safe as
+far as I can see.
+
+The cookie would be needed anyhow, I think, in order for the SPI layer 
+to be able to find the transaction that the Java function was
+originally invoked in.
+
+You could make the SPI layer stuff look like a normal JDBC driver to
+user code--PL/Perl does this kind of thing with the Perl DBI
+interface.
+
+-Doug
+-- 
+Let us cross over the river, and rest under the shade of the trees.
+   --T. J. Jackson, 1863
+
+---------------------------(end of broadcast)---------------------------
+TIP 1: subscribe and unsubscribe commands go to [email protected]
+