2001-02-07 12:50:55 +08:00
|
|
|
|
From pgsql-hackers-owner+M4145@postgresql.org Sat Feb 3 05:54:06 2001
|
|
|
|
|
|
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
|
|
|
|
|
|
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id FAA22302
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Sat, 3 Feb 2001 05:54:04 -0500 (EST)
|
|
|
|
|
|
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
|
|
|
|
|
|
by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f13Ap4q95132;
|
|
|
|
|
|
Sat, 3 Feb 2001 05:51:04 -0500 (EST)
|
|
|
|
|
|
(envelope-from pgsql-hackers-owner+M4145@postgresql.org)
|
|
|
|
|
|
Received: from mail.retep.org.uk ([216.126.85.184])
|
|
|
|
|
|
by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f13AnIq94863
|
|
|
|
|
|
for <pgsql-hackers@postgresql.org>; Sat, 3 Feb 2001 05:49:18 -0500 (EST)
|
|
|
|
|
|
(envelope-from peter@retep.org.uk)
|
|
|
|
|
|
Received: from heather.retep.org.uk ([193.113.118.193])
|
|
|
|
|
|
(authenticated)
|
|
|
|
|
|
by mail.retep.org.uk (8.11.1/8.11.1) with ESMTP id f13AlnO94823;
|
|
|
|
|
|
Sat, 3 Feb 2001 05:47:49 -0500 (EST)
|
|
|
|
|
|
(envelope-from peter@retep.org.uk)
|
|
|
|
|
|
Message-Id: <5.0.2.1.0.20010203103036.009efec0@mail.retep.org.uk>
|
|
|
|
|
|
X-Sender: peter@mail.retep.org.uk
|
|
|
|
|
|
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
|
|
|
|
|
|
Date: Sat, 03 Feb 2001 10:46:24 +0000
|
|
|
|
|
|
To: Alex Pilosov <alex@pilosoft.com>, tomasz konefal <twkonefal@yahoo.ca>
|
|
|
|
|
|
From: Peter Mount <peter@retep.org.uk>
|
|
|
|
|
|
Subject: Re: [HACKERS] TODO list: Allow Java server-side programming
|
|
|
|
|
|
Cc: pgsql-hackers@postgresql.org
|
|
|
|
|
|
In-Reply-To: <Pine.BSO.4.10.10102021453160.9372-100000@spider.pilosoft.c
|
|
|
|
|
|
om>
|
|
|
|
|
|
References: <20010202194049.38902.qmail@web12003.mail.yahoo.com>
|
|
|
|
|
|
Mime-Version: 1.0
|
|
|
|
|
|
Content-Type: text/plain; charset="us-ascii"; format=flowed
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
At 14:57 02/02/01 -0500, Alex Pilosov wrote:
|
|
|
|
|
|
>On Fri, 2 Feb 2001, tomasz konefal wrote:
|
|
|
|
|
|
>
|
|
|
|
|
|
> > could someone please clarify what "Allow Java
|
|
|
|
|
|
> > server-side programming" actually means? what are the
|
|
|
|
|
|
> > limitations of using java and jdbc with pgsql?
|
|
|
|
|
|
>
|
|
|
|
|
|
>It means to embed Java interpreter inside postgres, and allow writing
|
|
|
|
|
|
>stored procedures and triggers in Java.
|
|
|
|
|
|
|
|
|
|
|
|
Thats correct. Basically you are talking of something like PL/Java. The
|
|
|
|
|
|
Java side would be simple, but its linking the JVM to the backend that's
|
|
|
|
|
|
the problem.
|
|
|
|
|
|
|
|
|
|
|
|
It's been a while since I delved into the backend, but unless it's changed
|
|
|
|
|
|
from fork() to threading, I don't really see this happening, unless someone
|
|
|
|
|
|
who knows C that well knows of a portable way of communicating between two
|
|
|
|
|
|
processes - other than RMI. If that could be solved, then you could use JNI
|
|
|
|
|
|
to interface the JVM.
|
|
|
|
|
|
|
|
|
|
|
|
I know some people think this would slow the backend down, but it's only
|
|
|
|
|
|
the instanciation of the JVM thats slow, hence the other reason fork() is
|
|
|
|
|
|
holding this back. Ideally you would want the JVM to be running with
|
|
|
|
|
|
PostMaster, and then each backend can then use the JVM as and when necessary.
|
|
|
|
|
|
|
|
|
|
|
|
Obviously you wouldn't want a JVM in every installation, but there are a
|
|
|
|
|
|
lot of good reasons to have this capability. For example, as part of the
|
|
|
|
|
|
course I did this week, we used Tomcat (Servlet/JSP/Web server). Now
|
|
|
|
|
|
there's no reason why Tomcat could run within the same JVM. JBoss is
|
|
|
|
|
|
another good example (EJB Server). The JBoss team have actually got Tomcat
|
|
|
|
|
|
to run within the same JVM. Doesn't hinder performance at all, but does
|
|
|
|
|
|
reduce the memory footprint.
|
|
|
|
|
|
|
|
|
|
|
|
This is a good future thing to look into (why not for 8.0 ;-) ). If we
|
|
|
|
|
|
could find an _optional_ way of hooking the backend direct into the JVM, we
|
|
|
|
|
|
could get PostgreSQL into a lot of new areas. It also would make things
|
|
|
|
|
|
like CORBA etc a doddle.
|
|
|
|
|
|
|
|
|
|
|
|
PS: I'm writing down notes of the course to go onto the JDBC web site this
|
|
|
|
|
|
weekend, so there's some nice things for EJB, RMI, Corba etc.
|
|
|
|
|
|
|
|
|
|
|
|
More later, Peter
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
From pgsql-hackers-owner+M4153@postgresql.org Sat Feb 3 11:54:12 2001
|
|
|
|
|
|
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
|
|
|
|
|
|
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id LAA13446
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Sat, 3 Feb 2001 11:54:12 -0500 (EST)
|
|
|
|
|
|
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
|
|
|
|
|
|
by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f13GrZq17345;
|
|
|
|
|
|
Sat, 3 Feb 2001 11:53:35 -0500 (EST)
|
|
|
|
|
|
(envelope-from pgsql-hackers-owner+M4153@postgresql.org)
|
|
|
|
|
|
Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18])
|
|
|
|
|
|
by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f13GnZq17000
|
|
|
|
|
|
for <pgsql-hackers@postgresql.org>; Sat, 3 Feb 2001 11:49:37 -0500 (EST)
|
|
|
|
|
|
(envelope-from peter_e@gmx.net)
|
|
|
|
|
|
Received: from fwd06.sul.t-online.com
|
|
|
|
|
|
by mailout04.sul.t-online.com with smtp
|
|
|
|
|
|
id 14P5rE-0000zq-00; Sat, 03 Feb 2001 17:48:16 +0100
|
|
|
|
|
|
Received: from peter.localdomain (520083510237-0001@[212.185.245.12]) by fmrl06.sul.t-online.com
|
|
|
|
|
|
with esmtp id 14P5r6-0YvD60C; Sat, 3 Feb 2001 17:48:08 +0100
|
|
|
|
|
|
Date: Sat, 3 Feb 2001 17:56:33 +0100 (CET)
|
|
|
|
|
|
From: Peter Eisentraut <peter_e@gmx.net>
|
|
|
|
|
|
To: Peter Mount <peter@retep.org.uk>
|
|
|
|
|
|
cc: Alex Pilosov <alex@pilosoft.com>, tomasz konefal <twkonefal@yahoo.ca>,
|
|
|
|
|
|
<pgsql-hackers@postgresql.org>
|
|
|
|
|
|
Subject: Re: [HACKERS] TODO list: Allow Java server-side programming
|
|
|
|
|
|
In-Reply-To: <5.0.2.1.0.20010203103036.009efec0@mail.retep.org.uk>
|
|
|
|
|
|
Message-ID: <Pine.LNX.4.30.0102031746220.8648-100000@peter.localdomain>
|
|
|
|
|
|
MIME-Version: 1.0
|
|
|
|
|
|
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
|
|
|
|
|
X-Sender: 520083510237-0001@t-dialin.net
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
Peter Mount writes:
|
|
|
|
|
|
|
|
|
|
|
|
> Thats correct. Basically you are talking of something like PL/Java. The
|
|
|
|
|
|
> Java side would be simple, but its linking the JVM to the backend that's
|
|
|
|
|
|
> the problem.
|
|
|
|
|
|
|
|
|
|
|
|
I've tried that recently, here's how it looks as far as Linux JVMs go:
|
|
|
|
|
|
|
|
|
|
|
|
* Kaffe has a very polluted name space. Calls to its own functions get
|
|
|
|
|
|
resolved to PostgreSQL, and vice versa. Crash and burn result. The Kaffe
|
|
|
|
|
|
folks have admitted that this should be fixed but I didn't look farther
|
|
|
|
|
|
yet.
|
|
|
|
|
|
|
|
|
|
|
|
* The Sun/Blackdown JVM didn't work at all (not even 'java -version')
|
|
|
|
|
|
until I upgraded my libc. Then a simple test run crashes with an "error
|
|
|
|
|
|
external to JVM"; at first it looked like a segfault when referencing a
|
|
|
|
|
|
string constant. In gdb I saw myself faced with about 10 threads running
|
|
|
|
|
|
when nothing was going on yet, at which point I was too exhausted to
|
|
|
|
|
|
proceed.
|
|
|
|
|
|
|
|
|
|
|
|
* IBM's offering didn't work at all. I don't recall the problem anymore
|
|
|
|
|
|
but I think it didn't even link correctly.
|
|
|
|
|
|
|
|
|
|
|
|
So currently I don't see how this could become a mainstream project, let
|
|
|
|
|
|
alone across platforms.
|
|
|
|
|
|
|
|
|
|
|
|
> I know some people think this would slow the backend down, but it's only
|
|
|
|
|
|
> the instanciation of the JVM thats slow, hence the other reason fork() is
|
|
|
|
|
|
> holding this back. Ideally you would want the JVM to be running with
|
|
|
|
|
|
> PostMaster, and then each backend can then use the JVM as and when necessary.
|
|
|
|
|
|
|
|
|
|
|
|
But how do the other languages cope? Starting up a new Perl for each
|
|
|
|
|
|
backend can't be so cheap either.
|
|
|
|
|
|
|
|
|
|
|
|
--
|
|
|
|
|
|
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
From pgsql-hackers-owner+M4154@postgresql.org Sat Feb 3 12:37:02 2001
|
|
|
|
|
|
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
|
|
|
|
|
|
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id MAA00813
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Sat, 3 Feb 2001 12:37:01 -0500 (EST)
|
|
|
|
|
|
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
|
|
|
|
|
|
by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f13Haiq21225;
|
|
|
|
|
|
Sat, 3 Feb 2001 12:36:44 -0500 (EST)
|
|
|
|
|
|
(envelope-from pgsql-hackers-owner+M4154@postgresql.org)
|
|
|
|
|
|
Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222])
|
|
|
|
|
|
by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f13HX9q20913
|
|
|
|
|
|
for <pgsql-hackers@postgresql.org>; Sat, 3 Feb 2001 12:33:09 -0500 (EST)
|
|
|
|
|
|
(envelope-from alex@pilosoft.com)
|
|
|
|
|
|
Received: from localhost (alexmail@localhost)
|
|
|
|
|
|
by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id MAA09231;
|
|
|
|
|
|
Sat, 3 Feb 2001 12:36:01 -0500 (EST)
|
|
|
|
|
|
Date: Sat, 3 Feb 2001 12:36:01 -0500 (EST)
|
|
|
|
|
|
From: Alex Pilosov <alex@pilosoft.com>
|
|
|
|
|
|
To: Peter Mount <peter@retep.org.uk>
|
|
|
|
|
|
cc: Alex Pilosov <alex@pilosoft.com>, tomasz konefal <twkonefal@yahoo.ca>,
|
|
|
|
|
|
pgsql-hackers@postgresql.org
|
|
|
|
|
|
Subject: Re: [HACKERS] TODO list: Allow Java server-side programming
|
|
|
|
|
|
In-Reply-To: <5.0.2.1.0.20010203103036.009efec0@mail.retep.org.uk>
|
|
|
|
|
|
Message-ID: <Pine.BSO.4.10.10102031220470.10437-100000@spider.pilosoft.com>
|
|
|
|
|
|
MIME-Version: 1.0
|
|
|
|
|
|
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
On Sat, 3 Feb 2001, Peter Mount wrote:
|
|
|
|
|
|
|
|
|
|
|
|
> It's been a while since I delved into the backend, but unless it's
|
|
|
|
|
|
> changed from fork() to threading, I don't really see this happening,
|
|
|
|
|
|
> unless someone who knows C that well knows of a portable way of
|
|
|
|
|
|
> communicating between two processes - other than RMI. If that could be
|
|
|
|
|
|
> solved, then you could use JNI to interface the JVM.
|
|
|
|
|
|
There are many ways one can do this:
|
|
|
|
|
|
a) each backend will have a JVM linked in (shared object). This is the
|
|
|
|
|
|
way perl/tcl/ruby is embedded, and it works pretty nice. But, Java
|
|
|
|
|
|
['s memory requirement] sucks, therefore, this may not be the optimal
|
|
|
|
|
|
way.
|
|
|
|
|
|
|
|
|
|
|
|
> I know some people think this would slow the backend down, but it's
|
|
|
|
|
|
> only the instanciation of the JVM thats slow, hence the other reason
|
|
|
|
|
|
> fork() is holding this back. Ideally you would want the JVM to be
|
|
|
|
|
|
> running with PostMaster, and then each backend can then use the JVM as
|
|
|
|
|
|
> and when necessary.
|
|
|
|
|
|
b) since JVM is threaded, it may be more efficient to have a dedicated
|
|
|
|
|
|
process running JVM, and accepting some sort of IPC connections from
|
|
|
|
|
|
postgres processes. The biggest problem here is SPI, there aren't a good
|
|
|
|
|
|
way for that JVM to talk back to database.
|
|
|
|
|
|
|
|
|
|
|
|
c) temporarily, to have quick working code, you can reach java using hacks
|
|
|
|
|
|
using programming languages already built into postgres. Both TCL (tcl
|
|
|
|
|
|
blend) and Perl (JPL and another hack which name escapes me) are able to
|
|
|
|
|
|
execute java code. SPI is possible, I think both of these bindings are
|
|
|
|
|
|
two-way (you can go perl-java-perl-java). Might be worth a quick try?
|
|
|
|
|
|
-alex
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
From pgsql-hackers-owner+M4164@postgresql.org Sun Feb 4 04:23:42 2001
|
|
|
|
|
|
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
|
|
|
|
|
|
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id EAA04260
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Sun, 4 Feb 2001 04:23:41 -0500 (EST)
|
|
|
|
|
|
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
|
|
|
|
|
|
by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f149Nhx75443;
|
|
|
|
|
|
Sun, 4 Feb 2001 04:23:43 -0500 (EST)
|
|
|
|
|
|
(envelope-from pgsql-hackers-owner+M4164@postgresql.org)
|
|
|
|
|
|
Received: from me.tm.ee (adsl895.estpak.ee [213.168.23.133])
|
|
|
|
|
|
by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f149Mgx75338
|
|
|
|
|
|
for <pgsql-hackers@postgresql.org>; Sun, 4 Feb 2001 04:22:42 -0500 (EST)
|
|
|
|
|
|
(envelope-from hannu@tm.ee)
|
|
|
|
|
|
Received: from tm.ee (IDENT:hannu@localhost.localdomain [127.0.0.1])
|
|
|
|
|
|
by me.tm.ee (8.9.3/8.9.3) with ESMTP id LAA01488;
|
|
|
|
|
|
Sun, 4 Feb 2001 11:18:09 +0200
|
|
|
|
|
|
Message-ID: <3A7D1E51.E383AB7F@tm.ee>
|
|
|
|
|
|
Date: Sun, 04 Feb 2001 11:18:09 +0200
|
|
|
|
|
|
From: Hannu Krosing <hannu@tm.ee>
|
|
|
|
|
|
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.17 i686)
|
|
|
|
|
|
X-Accept-Language: en
|
|
|
|
|
|
MIME-Version: 1.0
|
|
|
|
|
|
To: Peter Mount <peter@retep.org.uk>
|
|
|
|
|
|
CC: Alex Pilosov <alex@pilosoft.com>, tomasz konefal <twkonefal@yahoo.ca>,
|
|
|
|
|
|
pgsql-hackers@postgresql.org
|
|
|
|
|
|
Subject: Re: [HACKERS] TODO list: Allow Java server-side programming
|
|
|
|
|
|
References: <20010202194049.38902.qmail@web12003.mail.yahoo.com> <5.0.2.1.0.20010203103036.009efec0@mail.retep.org.uk>
|
|
|
|
|
|
Content-Type: text/plain; charset=UTF-8
|
|
|
|
|
|
Content-Transfer-Encoding: 7bit
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
Peter Mount wrote:
|
|
|
|
|
|
>
|
|
|
|
|
|
> At 14:57 02/02/01 -0500, Alex Pilosov wrote:
|
|
|
|
|
|
> >On Fri, 2 Feb 2001, tomasz konefal wrote:
|
|
|
|
|
|
> >
|
|
|
|
|
|
> > > could someone please clarify what "Allow Java
|
|
|
|
|
|
> > > server-side programming" actually means? what are the
|
|
|
|
|
|
> > > limitations of using java and jdbc with pgsql?
|
|
|
|
|
|
> >
|
|
|
|
|
|
> >It means to embed Java interpreter inside postgres, and allow writing
|
|
|
|
|
|
> >stored procedures and triggers in Java.
|
|
|
|
|
|
>
|
|
|
|
|
|
> Thats correct. Basically you are talking of something like PL/Java. The
|
|
|
|
|
|
> Java side would be simple, but its linking the JVM to the backend that's
|
|
|
|
|
|
> the problem.
|
|
|
|
|
|
>
|
|
|
|
|
|
> It's been a while since I delved into the backend, but unless it's changed
|
|
|
|
|
|
> from fork() to threading,
|
|
|
|
|
|
|
|
|
|
|
|
Someone posted here recently his port/tweaks of backend so that it used
|
|
|
|
|
|
threads instead of fork(). IIRC it was done to be used inside a java
|
|
|
|
|
|
client in an embedded system.
|
|
|
|
|
|
|
|
|
|
|
|
----------------
|
|
|
|
|
|
Hannu
|
|
|
|
|
|
|
|
|
|
|
|
From pgsql-hackers-owner+M4168@postgresql.org Sun Feb 4 06:54:27 2001
|
|
|
|
|
|
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
|
|
|
|
|
|
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id GAA19741
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Sun, 4 Feb 2001 06:54:26 -0500 (EST)
|
|
|
|
|
|
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
|
|
|
|
|
|
by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f14BsOx83329;
|
|
|
|
|
|
Sun, 4 Feb 2001 06:54:24 -0500 (EST)
|
|
|
|
|
|
(envelope-from pgsql-hackers-owner+M4168@postgresql.org)
|
|
|
|
|
|
Received: from mail.retep.org.uk ([216.126.85.184])
|
|
|
|
|
|
by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f14Bs9x83240
|
|
|
|
|
|
for <pgsql-hackers@postgresql.org>; Sun, 4 Feb 2001 06:54:09 -0500 (EST)
|
|
|
|
|
|
(envelope-from peter@retep.org.uk)
|
|
|
|
|
|
Received: from heather.retep.org.uk ([193.113.241.180])
|
|
|
|
|
|
(authenticated)
|
|
|
|
|
|
by mail.retep.org.uk (8.11.1/8.11.1) with ESMTP id f14BqkR83161;
|
|
|
|
|
|
Sun, 4 Feb 2001 06:52:46 -0500 (EST)
|
|
|
|
|
|
(envelope-from peter@retep.org.uk)
|
|
|
|
|
|
Message-Id: <5.0.2.1.0.20010204114942.00a0c8d0@mail.retep.org.uk>
|
|
|
|
|
|
X-Sender: peter@mail.retep.org.uk
|
|
|
|
|
|
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
|
|
|
|
|
|
Date: Sun, 04 Feb 2001 11:51:21 +0000
|
|
|
|
|
|
To: Peter Eisentraut <peter_e@gmx.net>
|
|
|
|
|
|
From: Peter Mount <peter@retep.org.uk>
|
|
|
|
|
|
Subject: Re: [HACKERS] TODO list: Allow Java server-side programming
|
|
|
|
|
|
Cc: Alex Pilosov <alex@pilosoft.com>, tomasz konefal <twkonefal@yahoo.ca>,
|
|
|
|
|
|
<pgsql-hackers@postgresql.org>
|
|
|
|
|
|
In-Reply-To: <Pine.LNX.4.30.0102031746220.8648-100000@peter.localdomain>
|
|
|
|
|
|
References: <5.0.2.1.0.20010203103036.009efec0@mail.retep.org.uk>
|
|
|
|
|
|
Mime-Version: 1.0
|
|
|
|
|
|
Content-Type: text/plain; charset="us-ascii"; format=flowed
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
At 17:56 03/02/01 +0100, Peter Eisentraut wrote:
|
|
|
|
|
|
>Peter Mount writes:
|
|
|
|
|
|
>
|
|
|
|
|
|
> > Thats correct. Basically you are talking of something like PL/Java. The
|
|
|
|
|
|
> > Java side would be simple, but its linking the JVM to the backend that's
|
|
|
|
|
|
> > the problem.
|
|
|
|
|
|
>
|
|
|
|
|
|
>I've tried that recently, here's how it looks as far as Linux JVMs go:
|
|
|
|
|
|
|
|
|
|
|
|
[snip]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
>So currently I don't see how this could become a mainstream project, let
|
|
|
|
|
|
>alone across platforms.
|
|
|
|
|
|
|
|
|
|
|
|
I don't think it would be, but it would be a good side-project. Over time
|
|
|
|
|
|
the various JVM's should become better to interface with.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
> > I know some people think this would slow the backend down, but it's only
|
|
|
|
|
|
> > the instanciation of the JVM thats slow, hence the other reason fork() is
|
|
|
|
|
|
> > holding this back. Ideally you would want the JVM to be running with
|
|
|
|
|
|
> > PostMaster, and then each backend can then use the JVM as and when
|
|
|
|
|
|
> necessary.
|
|
|
|
|
|
>
|
|
|
|
|
|
>But how do the other languages cope? Starting up a new Perl for each
|
|
|
|
|
|
>backend can't be so cheap either.
|
|
|
|
|
|
|
|
|
|
|
|
But a lot cheaper than Java.
|
|
|
|
|
|
|
|
|
|
|
|
Peter
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
From pgsql-hackers-owner+M4169@postgresql.org Sun Feb 4 06:57:24 2001
|
|
|
|
|
|
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
|
|
|
|
|
|
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id GAA19817
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Sun, 4 Feb 2001 06:57:23 -0500 (EST)
|
|
|
|
|
|
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
|
|
|
|
|
|
by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f14BvLx83711;
|
|
|
|
|
|
Sun, 4 Feb 2001 06:57:21 -0500 (EST)
|
|
|
|
|
|
(envelope-from pgsql-hackers-owner+M4169@postgresql.org)
|
|
|
|
|
|
Received: from mail.retep.org.uk ([216.126.85.184])
|
|
|
|
|
|
by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f14Bv7x83611
|
|
|
|
|
|
for <pgsql-hackers@postgresql.org>; Sun, 4 Feb 2001 06:57:07 -0500 (EST)
|
|
|
|
|
|
(envelope-from peter@retep.org.uk)
|
|
|
|
|
|
Received: from heather.retep.org.uk ([193.113.241.180])
|
|
|
|
|
|
(authenticated)
|
|
|
|
|
|
by mail.retep.org.uk (8.11.1/8.11.1) with ESMTP id f14BtjR83557;
|
|
|
|
|
|
Sun, 4 Feb 2001 06:55:45 -0500 (EST)
|
|
|
|
|
|
(envelope-from peter@retep.org.uk)
|
|
|
|
|
|
Message-Id: <5.0.2.1.0.20010204115139.009f1c50@mail.retep.org.uk>
|
|
|
|
|
|
X-Sender: peter@mail.retep.org.uk
|
|
|
|
|
|
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
|
|
|
|
|
|
Date: Sun, 04 Feb 2001 11:54:20 +0000
|
|
|
|
|
|
To: Alex Pilosov <alex@pilosoft.com>
|
|
|
|
|
|
From: Peter Mount <peter@retep.org.uk>
|
|
|
|
|
|
Subject: Re: [HACKERS] TODO list: Allow Java server-side programming
|
|
|
|
|
|
Cc: Alex Pilosov <alex@pilosoft.com>, tomasz konefal <twkonefal@yahoo.ca>,
|
|
|
|
|
|
pgsql-hackers@postgresql.org
|
|
|
|
|
|
In-Reply-To: <Pine.BSO.4.10.10102031220470.10437-100000@spider.pilosoft.
|
|
|
|
|
|
com>
|
|
|
|
|
|
References: <5.0.2.1.0.20010203103036.009efec0@mail.retep.org.uk>
|
|
|
|
|
|
Mime-Version: 1.0
|
|
|
|
|
|
Content-Type: text/plain; charset="us-ascii"; format=flowed
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
At 12:36 03/02/01 -0500, Alex Pilosov wrote:
|
|
|
|
|
|
>On Sat, 3 Feb 2001, Peter Mount wrote:
|
|
|
|
|
|
|
|
|
|
|
|
[snip]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
> > I know some people think this would slow the backend down, but it's
|
|
|
|
|
|
> > only the instanciation of the JVM thats slow, hence the other reason
|
|
|
|
|
|
> > fork() is holding this back. Ideally you would want the JVM to be
|
|
|
|
|
|
> > running with PostMaster, and then each backend can then use the JVM as
|
|
|
|
|
|
> > and when necessary.
|
|
|
|
|
|
>b) since JVM is threaded, it may be more efficient to have a dedicated
|
|
|
|
|
|
>process running JVM, and accepting some sort of IPC connections from
|
|
|
|
|
|
>postgres processes. The biggest problem here is SPI, there aren't a good
|
|
|
|
|
|
>way for that JVM to talk back to database.
|
|
|
|
|
|
|
|
|
|
|
|
That was my other idea, but it is the IPC thats problematical. You would
|
|
|
|
|
|
still need to do some native api to implement some messaging system between
|
|
|
|
|
|
the two.
|
|
|
|
|
|
|
|
|
|
|
|
However, at the other extreme there is RPC, which is possible now, but
|
|
|
|
|
|
would be a lot slower.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
>c) temporarily, to have quick working code, you can reach java using hacks
|
|
|
|
|
|
>using programming languages already built into postgres. Both TCL (tcl
|
|
|
|
|
|
>blend) and Perl (JPL and another hack which name escapes me) are able to
|
|
|
|
|
|
>execute java code. SPI is possible, I think both of these bindings are
|
|
|
|
|
|
>two-way (you can go perl-java-perl-java). Might be worth a quick try?
|
|
|
|
|
|
|
|
|
|
|
|
Might be one way to go...
|
|
|
|
|
|
|
|
|
|
|
|
Peter
|
|
|
|
|
|
|
|
|
|
|
|
>-alex
|
|
|
|
|
|
>
|
|
|
|
|
|
|
|
|
|
|
|
|
2001-06-28 02:07:11 +08:00
|
|
|
|
From pgsql-jdbc-owner+M884@postgresql.org Wed Jun 27 13:36:09 2001
|
|
|
|
|
|
Return-path: <pgsql-jdbc-owner+M884@postgresql.org>
|
|
|
|
|
|
Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
|
|
|
|
|
|
by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f5RHa9q05483
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Wed, 27 Jun 2001 13:36:09 -0400 (EDT)
|
|
|
|
|
|
Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28])
|
|
|
|
|
|
by postgresql.org (8.11.3/8.11.1) with SMTP id f5RHaAa03078
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Wed, 27 Jun 2001 13:36:10 -0400 (EDT)
|
|
|
|
|
|
(envelope-from pgsql-jdbc-owner+M884@postgresql.org)
|
|
|
|
|
|
Received: from net2.micro-automation.com (net2.micro-automation.com [64.7.141.29])
|
|
|
|
|
|
by postgresql.org (8.11.3/8.11.1) with SMTP id f5RHOka96908
|
|
|
|
|
|
for <pgsql-jdbc@postgresql.org>; Wed, 27 Jun 2001 13:24:46 -0400 (EDT)
|
|
|
|
|
|
(envelope-from Dave@micro-automation.net)
|
|
|
|
|
|
Received: (qmail 32671 invoked from network); 27 Jun 2001 17:24:39 -0000
|
|
|
|
|
|
Received: from eboxwest.ebox.com (HELO INSPIRON) (206.51.23.194)
|
|
|
|
|
|
by net2.micro-automation.com with SMTP; 27 Jun 2001 17:24:39 -0000
|
|
|
|
|
|
Reply-To: <Dave@micro-automation.net>
|
|
|
|
|
|
From: "Dave Cramer" <Dave@micro-automation.net>
|
|
|
|
|
|
To: "'Barry Lind'" <barry@xythos.com>
|
|
|
|
|
|
cc: <pgsql-jdbc@postgresql.org>
|
|
|
|
|
|
Subject: [JDBC] RE: Todo/missing? (was Re: [ADMIN] High memory usage [PATCH])
|
|
|
|
|
|
Date: Wed, 27 Jun 2001 13:22:42 -0400
|
|
|
|
|
|
Organization: Micro Automation Inc.
|
|
|
|
|
|
Message-ID: <008301c0ff2d$c885d880$0201a8c0@INSPIRON>
|
|
|
|
|
|
MIME-Version: 1.0
|
|
|
|
|
|
Content-Type: text/plain;
|
|
|
|
|
|
charset="us-ascii"
|
|
|
|
|
|
Content-Transfer-Encoding: 7bit
|
|
|
|
|
|
X-Priority: 3 (Normal)
|
|
|
|
|
|
X-MSMail-Priority: Normal
|
|
|
|
|
|
X-Mailer: Microsoft Outlook, Build 10.0.2616
|
|
|
|
|
|
Importance: Normal
|
|
|
|
|
|
In-Reply-To: <3B39352E.6060904@xythos.com>
|
|
|
|
|
|
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
|
|
|
|
|
|
X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/)
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-jdbc-owner@postgresql.org
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
Barry,
|
|
|
|
|
|
|
|
|
|
|
|
The getXXXFunctions aren't implemented
|
|
|
|
|
|
Some of the other functions are correct for version 7.1 but not for
|
|
|
|
|
|
previous versions. Ie. The row length, etc. I think the driver should
|
|
|
|
|
|
get the version and determine what is correct for each version.
|
|
|
|
|
|
|
|
|
|
|
|
I think this is incorrect.
|
|
|
|
|
|
public boolean supportsSelectForUpdate() throws SQLException
|
|
|
|
|
|
{
|
|
|
|
|
|
// XXX-Not Implemented
|
|
|
|
|
|
return false;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
There are a number of things here which are hard coded, and possible
|
|
|
|
|
|
wrong.
|
|
|
|
|
|
|
|
|
|
|
|
I started to work on this, but since I am going on vacation next week I
|
|
|
|
|
|
have a number of fires to get down to a slow burn before I go.
|
|
|
|
|
|
|
|
|
|
|
|
Dave
|
|
|
|
|
|
|
|
|
|
|
|
-----Original Message-----
|
|
|
|
|
|
From: Barry Lind [mailto:barry@xythos.com]
|
|
|
|
|
|
Sent: June 26, 2001 9:22 PM
|
|
|
|
|
|
To: Dave Cramer
|
|
|
|
|
|
Cc: pgsql-jdbc@postgresql.org
|
|
|
|
|
|
Subject: Re: Todo/missing? (was Re: [ADMIN] High memory usage [PATCH])
|
|
|
|
|
|
|
|
|
|
|
|
Dave,
|
|
|
|
|
|
|
|
|
|
|
|
Can you give a little more detail on what you mean by 'Improved
|
|
|
|
|
|
DatabaseMetaData'? What specific areas are currently lacking?
|
|
|
|
|
|
|
|
|
|
|
|
thanks,
|
|
|
|
|
|
--Barry
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
>>On Mon, Jun 25, 2001 at 10:56:18PM -0400, Dave Cramer wrote:
|
|
|
|
|
|
>>
|
|
|
|
|
|
>>>I have to agree, we need to compile a todo list.
|
|
|
|
|
|
>>>
|
|
|
|
|
|
>>>Mine would include:
|
|
|
|
|
|
>>>
|
|
|
|
|
|
>>>1) Comprehensive test suite. This may be available already.
|
|
|
|
|
|
>>>2) Updateable resultSet
|
|
|
|
|
|
>>>3) Improved DatabaseMetaData
|
|
|
|
|
|
>>>4) Compatible blob support
|
|
|
|
|
|
>>>
|
|
|
|
|
|
>
|
|
|
|
|
|
> Added to official PostgreSQL TODO:
|
|
|
|
|
|
>
|
|
|
|
|
|
> * JDBC
|
|
|
|
|
|
> * Comprehensive test suite. This may be available already.
|
|
|
|
|
|
> * Updateable resultSet
|
|
|
|
|
|
> * Improved DatabaseMetaData
|
|
|
|
|
|
> * Compatible blob support
|
|
|
|
|
|
>
|
|
|
|
|
|
>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
|
|
|
|
TIP 4: Don't 'kill -9' the postmaster
|
|
|
|
|
|
|
2001-07-13 03:59:55 +08:00
|
|
|
|
From pgsql-jdbc-owner+M968@postgresql.org Sun Jul 8 18:59:29 2001
|
|
|
|
|
|
Return-path: <pgsql-jdbc-owner+M968@postgresql.org>
|
|
|
|
|
|
Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
|
|
|
|
|
|
by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f68MxTl05403
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Sun, 8 Jul 2001 18:59:29 -0400 (EDT)
|
|
|
|
|
|
Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28])
|
|
|
|
|
|
by postgresql.org (8.11.3/8.11.1) with SMTP id f68MxWa07043
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Sun, 8 Jul 2001 18:59:32 -0400 (EDT)
|
|
|
|
|
|
(envelope-from pgsql-jdbc-owner+M968@postgresql.org)
|
|
|
|
|
|
Received: from mailout02.sul.t-online.de (mailout02.sul.t-online.com [194.25.134.17])
|
|
|
|
|
|
by postgresql.org (8.11.3/8.11.1) with ESMTP id f68MrGa05368
|
|
|
|
|
|
for <pgsql-jdbc@postgresql.org>; Sun, 8 Jul 2001 18:53:16 -0400 (EDT)
|
|
|
|
|
|
(envelope-from peter_e@gmx.net)
|
|
|
|
|
|
Received: from fwd06.sul.t-online.de
|
|
|
|
|
|
by mailout02.sul.t-online.de with smtp
|
|
|
|
|
|
id 15JNQP-0004x9-00; Mon, 09 Jul 2001 00:53:13 +0200
|
|
|
|
|
|
Received: from peter.localdomain (520083510237-0001@[212.185.245.47]) by fmrl06.sul.t-online.com
|
|
|
|
|
|
with esmtp id 15JNQH-0xfc00C; Mon, 9 Jul 2001 00:53:05 +0200
|
|
|
|
|
|
Date: Mon, 9 Jul 2001 00:55:37 +0200 (CEST)
|
|
|
|
|
|
From: Peter Eisentraut <peter_e@gmx.net>
|
|
|
|
|
|
To: <pgsql-jdbc@postgresql.org>
|
|
|
|
|
|
Subject: [JDBC] To do list for DatabaseMetaData
|
|
|
|
|
|
Message-ID: <Pine.LNX.4.30.0107090041240.677-100000@peter.localdomain>
|
|
|
|
|
|
MIME-Version: 1.0
|
|
|
|
|
|
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
|
|
|
|
|
X-Sender: 520083510237-0001@t-dialin.net
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-jdbc-owner@postgresql.org
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
Since DatabaseMetaData seems to have been a subject of interest lately I
|
|
|
|
|
|
have composed a list of concrete things that need to be done there.
|
|
|
|
|
|
|
|
|
|
|
|
The spec of DatabaseMetaData is here:
|
|
|
|
|
|
http://java.sun.com/j2se/1.3/docs/api/java/sql/DatabaseMetaData.html
|
|
|
|
|
|
|
|
|
|
|
|
All the functions listed in the spec and not listed below I have recently
|
|
|
|
|
|
checked and updated for correctness and compliance. Thus, this list is
|
|
|
|
|
|
complete. Functions marked with '?' I have not checked yet.
|
|
|
|
|
|
|
|
|
|
|
|
If someone wants to tackle some of the getThings() functions, a
|
|
|
|
|
|
description of the system catalogs is in the Developer's Guide. Also note
|
|
|
|
|
|
that some functions currently incorrectly handle the case of null patterns
|
|
|
|
|
|
vs. "" patterns vs. "%" patterns.
|
|
|
|
|
|
|
|
|
|
|
|
At least two parameters obtained by a DatabaseMetaData method are
|
|
|
|
|
|
user-tunable on the server side. The only way to get at those numbers
|
|
|
|
|
|
currently is to use SHOW and parse the NOTICE: it sends back (which is
|
|
|
|
|
|
impossible in the days of internationalized messages), so a nice
|
|
|
|
|
|
side-project would be to implement a get_config_variable(text) returns
|
|
|
|
|
|
text (better names possible) function to allow easier access.
|
|
|
|
|
|
|
|
|
|
|
|
Now the list:
|
|
|
|
|
|
|
|
|
|
|
|
allProceduresAreCallable() not all procedures listed are
|
|
|
|
|
|
callable (triggers, in/out)
|
|
|
|
|
|
allTablesAreSelectable() should this check access
|
|
|
|
|
|
privileges or what?
|
|
|
|
|
|
getSQLKeywords() outdated, could be automated like
|
|
|
|
|
|
keywords.sgml
|
|
|
|
|
|
getNumericFunctions() decide what exactly is a "numeric function"?
|
|
|
|
|
|
getStringFunctions() ditto
|
|
|
|
|
|
getSystemFunctions() ditto
|
|
|
|
|
|
getTimeDateFunctions() ditto
|
|
|
|
|
|
getExtraNameCharacters() server allows \200 to \377, how
|
|
|
|
|
|
does this fit in with Unicode?
|
|
|
|
|
|
getMaxColumnNameLength() 32 is hard-coded here, maybe query server
|
|
|
|
|
|
getMaxColumnsInIndex() this should be detected from server
|
|
|
|
|
|
getMaxColumnsInTable() this limit is probably shaky
|
|
|
|
|
|
getMaxConnections() could query the server for this
|
|
|
|
|
|
(SHOW, see above)
|
|
|
|
|
|
getMaxCursorNameLength() 32 hard-coded
|
|
|
|
|
|
getMaxSchemaNameLength() will be 32 when done
|
|
|
|
|
|
getMaxProcedureNameLength() 32 hard-coded
|
|
|
|
|
|
getMaxCatalogNameLength() should be NAMEDATALEN
|
|
|
|
|
|
doesMaxRowSizeIncludeBlobs() since we don't have blobs, should
|
|
|
|
|
|
this throw an exception?
|
|
|
|
|
|
getMaxStatements() questionable, see comment there
|
|
|
|
|
|
getMaxTableNameLength() 32 hard-coded
|
|
|
|
|
|
getMaxUserNameLength() 32 hard-coded
|
|
|
|
|
|
getDefaultTransactionIsolation() This is configurable in 7.2.
|
|
|
|
|
|
(SHOW, see above)
|
|
|
|
|
|
getProcedures() missing catalog (database) and
|
|
|
|
|
|
remarks columns
|
|
|
|
|
|
getProcedureColumns() only dummy implementation
|
|
|
|
|
|
getTables() fails to handle pre-7.1 servers
|
|
|
|
|
|
(relkind 'v')
|
|
|
|
|
|
getSchemas() This should throw an exception.
|
|
|
|
|
|
getTableTypes() ?
|
|
|
|
|
|
getColumns() ?
|
|
|
|
|
|
getColumnPrivileges() not implemented
|
|
|
|
|
|
getTablePrivileges() not implemented
|
|
|
|
|
|
getBestRowIdentifier() only dummy implementation
|
|
|
|
|
|
getVersionColumns() not implemented
|
|
|
|
|
|
getPrimaryKeys() ?
|
|
|
|
|
|
getImportedKeys() ?
|
|
|
|
|
|
getExportedKeys() not implemented
|
|
|
|
|
|
getCrossReference() not implemented
|
|
|
|
|
|
getTypeInfo() ?
|
|
|
|
|
|
getIndexInfo() ?
|
|
|
|
|
|
getUDTs() ?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
--
|
|
|
|
|
|
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
|
|
|
|
TIP 6: Have you searched our list archives?
|
|
|
|
|
|
|
|
|
|
|
|
http://www.postgresql.org/search.mpl
|
|
|
|
|
|
|
2001-09-04 05:17:53 +08:00
|
|
|
|
From pgsql-general-owner+M14602@postgresql.org Sat Sep 1 00:50:49 2001
|
|
|
|
|
|
Return-path: <pgsql-general-owner+M14602@postgresql.org>
|
|
|
|
|
|
Received: from server1.pgsql.org (server1.pgsql.org [64.39.15.238] (may be forged))
|
|
|
|
|
|
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id f814onF24433
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Sat, 1 Sep 2001 00:50:49 -0400 (EDT)
|
|
|
|
|
|
Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
|
|
|
|
|
|
by server1.pgsql.org (8.11.6/8.11.6) with ESMTP id f814pNq39726;
|
|
|
|
|
|
Fri, 31 Aug 2001 23:51:23 -0500 (CDT)
|
|
|
|
|
|
(envelope-from pgsql-general-owner+M14602@postgresql.org)
|
|
|
|
|
|
Received: from ns1.austin.rr.com (ns1.austin.rr.com [24.93.35.62])
|
|
|
|
|
|
by postgresql.org (8.11.3/8.11.4) with ESMTP id f81439f96700
|
|
|
|
|
|
for <pgsql-general@postgresql.org>; Sat, 1 Sep 2001 00:03:09 -0400 (EDT)
|
|
|
|
|
|
(envelope-from rsanford@nolimitsystems.com)
|
|
|
|
|
|
Received: from mightywombat (cs662523-179.houston.rr.com [66.25.23.179])
|
|
|
|
|
|
by ns1.austin.rr.com (8.12.0.Beta16/8.12.0.Beta16) with SMTP id f813x7pX027417
|
|
|
|
|
|
for <pgsql-general@postgresql.org>; Fri, 31 Aug 2001 22:59:07 -0500
|
|
|
|
|
|
From: "Robert J. Sanford, Jr." <rsanford@nolimitsystems.com>
|
|
|
|
|
|
To: <pgsql-general@postgresql.org>
|
|
|
|
|
|
Subject: Re: [GENERAL] PL/java?
|
|
|
|
|
|
Date: Fri, 31 Aug 2001 23:02:04 -0500
|
|
|
|
|
|
Message-ID: <HOEFIONAHHKFEFENBMNOAEPPCBAA.rsanford@nolimitsystems.com>
|
|
|
|
|
|
MIME-Version: 1.0
|
|
|
|
|
|
Content-Type: text/plain;
|
|
|
|
|
|
charset="US-ASCII"
|
|
|
|
|
|
Content-Transfer-Encoding: 7bit
|
|
|
|
|
|
X-Priority: 3 (Normal)
|
|
|
|
|
|
X-MSMail-Priority: Normal
|
|
|
|
|
|
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
|
|
|
|
|
|
Importance: Normal
|
|
|
|
|
|
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
|
|
|
|
|
|
In-Reply-To: <MAEFKNDLAHNIFMAIEGHJCEKJCDAA.knight@phunc.com>
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-general-owner@postgresql.org
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
note - i don't work for any of the companies whose products
|
|
|
|
|
|
are mentioned below. i have performed evaluations of these
|
|
|
|
|
|
products and the support provided when attempting to determine
|
|
|
|
|
|
what platform my company's systems should run on. unfortunately,
|
|
|
|
|
|
i did not choose orion and i am suffering for it now...
|
|
|
|
|
|
|
|
|
|
|
|
some goober blathered thusly:
|
|
|
|
|
|
> Have you ever actually used Java on an enterprise-level
|
|
|
|
|
|
> application? Ever see the Tomcat webserver? It uses
|
|
|
|
|
|
> 100MB of memory, drives the load on our server up to 8,
|
|
|
|
|
|
> and doesn't serve nearly as fast apache. Do you really
|
|
|
|
|
|
> want that in your database?
|
|
|
|
|
|
|
|
|
|
|
|
first - don't complain about java because you or someone
|
|
|
|
|
|
in your group/department/company made a poor decision on
|
|
|
|
|
|
what tools to use. that's like complaining about mexican
|
|
|
|
|
|
food when the only experience you have is eating an out-
|
|
|
|
|
|
dated frozen burrito from the 7-11 freezer.
|
|
|
|
|
|
|
|
|
|
|
|
when looking at the performance of java you have to take
|
|
|
|
|
|
a look at two things - first you have to compare various
|
|
|
|
|
|
java implementations against each other and then you have
|
|
|
|
|
|
to compare the best java implementations against native
|
|
|
|
|
|
c/c++ code. the following link does that. the java tests
|
|
|
|
|
|
include tomcat, orion, websphere, and resin. jrun and
|
|
|
|
|
|
weblogic were originally included in the testing but
|
|
|
|
|
|
were both removed at their companies' request.
|
|
|
|
|
|
|
|
|
|
|
|
the tests also compare orion vs microsoft asp running on
|
|
|
|
|
|
win2k and iis5. all tests run on the same hardware.
|
|
|
|
|
|
|
|
|
|
|
|
what i believe these tests clearly demonstrate is that
|
|
|
|
|
|
java is not the problem, the implementation applications
|
|
|
|
|
|
based on java is. i also do not believe that tomcat is
|
|
|
|
|
|
a fair representation of java performance in that it is
|
|
|
|
|
|
intended to be a reference implementation. as such, the
|
|
|
|
|
|
code base should sacrifice performance for clarity.
|
|
|
|
|
|
|
|
|
|
|
|
http://www.orionserver.com/benchmarks/benchmark.html
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
while not in the benchmark i would also like to
|
|
|
|
|
|
recommend jetty as an app server. it is an opensource,
|
|
|
|
|
|
100% java web and application server. in its base form
|
|
|
|
|
|
it is "just" a web, servlet, and jsp engine. it does,
|
|
|
|
|
|
however, have contributed code providing integration
|
|
|
|
|
|
with other j2ee opensource projects such as the JBoss
|
|
|
|
|
|
EJB engine.
|
|
|
|
|
|
|
|
|
|
|
|
you can find the jetty home page at:
|
|
|
|
|
|
http://jetty.mortbay.com/
|
|
|
|
|
|
|
|
|
|
|
|
and then they blathered some more:
|
|
|
|
|
|
> Compare the speed of Oracle 8 with 8i if you don't
|
|
|
|
|
|
> believe me. The stability is also much worse. Ever
|
|
|
|
|
|
> see a JVM on any platform that didn't crash if you
|
|
|
|
|
|
> looked at it cockeyed? Ever really trust the garbage
|
|
|
|
|
|
> collection? I don't. I've found a memory leak in IBM
|
|
|
|
|
|
> developed java libraries. Gotta restart that app
|
|
|
|
|
|
> every once in a while to reclaim system resources it
|
|
|
|
|
|
> gobbled up and never gave back.
|
|
|
|
|
|
|
|
|
|
|
|
some mention was made regarding the performance of
|
|
|
|
|
|
the oracle8i application server. well, oracle has
|
|
|
|
|
|
realized that their performance was sub-optimal and
|
|
|
|
|
|
rectified the situation by licensing the orion server
|
|
|
|
|
|
for oracle9i. while money and politics most certainly
|
|
|
|
|
|
play a part in any licensing arrangement they must
|
|
|
|
|
|
also realize that making customers happy through the
|
|
|
|
|
|
performance of their applications will lead to more
|
|
|
|
|
|
money. the link to the press release is below.
|
|
|
|
|
|
|
|
|
|
|
|
http://www.oracle.com/corporate/press/index.html?759347.html
|
|
|
|
|
|
|
|
|
|
|
|
all of that being said...
|
|
|
|
|
|
|
|
|
|
|
|
i don't think that the person that started this thread
|
|
|
|
|
|
did anything wrong by making the request they did. that
|
|
|
|
|
|
is what opensource is all about - contributions, even
|
|
|
|
|
|
just contributions of ideas, are welcomed. even so, there
|
|
|
|
|
|
are several options that i see for getting it implemented:
|
|
|
|
|
|
1) its an open source project so implement it yourself.
|
|
|
|
|
|
while i have never worked on modifying the code base
|
|
|
|
|
|
i am extremely confident that the current developers
|
|
|
|
|
|
will be more than willing to give you advice and
|
|
|
|
|
|
pointers.
|
|
|
|
|
|
2) if #1 is not feasible either because you don't have
|
|
|
|
|
|
the time, the inclination, or the experience then
|
|
|
|
|
|
you can write a contract that will pay one of the
|
|
|
|
|
|
postgres developers to implement it for you.
|
|
|
|
|
|
3) if that isn't feasible you can try to get a volunteer
|
|
|
|
|
|
to do so.
|
|
|
|
|
|
4) if that isn't feasible then you either have to live
|
|
|
|
|
|
with what you have, go elsewhere, or be quiet.
|
|
|
|
|
|
|
|
|
|
|
|
to the person that blathered thusly in response to the
|
|
|
|
|
|
request for java:
|
|
|
|
|
|
> Merits of the language notwithstanding, I'd rather
|
|
|
|
|
|
> not have a buggy, still under development
|
|
|
|
|
|
> (depreciating everything under the sun with every
|
|
|
|
|
|
> new iteration) JVM parasite in my DB.
|
|
|
|
|
|
|
|
|
|
|
|
informed and intelligent debate is good. given that i
|
|
|
|
|
|
believe such to be true, i would request that you
|
|
|
|
|
|
refrain from blathering such vitriol and uninformed
|
|
|
|
|
|
nonsense. not only is it for the good of the people
|
|
|
|
|
|
on the list who don't want to hear it but it will
|
|
|
|
|
|
also do you good by not telling everyone out there
|
|
|
|
|
|
that you are a very silly person that doesn't deal
|
|
|
|
|
|
with logic and/or facts.
|
|
|
|
|
|
|
|
|
|
|
|
to everyone else on the list - if we all contribute
|
|
|
|
|
|
a penny we could probably buy enough burritos from
|
|
|
|
|
|
7-11 to make sure that his hands and mouth are busy
|
|
|
|
|
|
for a good long while.
|
|
|
|
|
|
|
|
|
|
|
|
rjsjr
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2001-09-04 23:40:18 +08:00
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
|
|
|
|
TIP 3: if posting/reading through Usenet, please send an appropriate
|
|
|
|
|
|
subscribe-nomail command to majordomo@postgresql.org so that your
|
|
|
|
|
|
message can get through to the mailing list cleanly
|
|
|
|
|
|
|
|
|
|
|
|
From pgsql-general-owner+M14597@postgresql.org Fri Aug 31 23:23:15 2001
|
|
|
|
|
|
Return-path: <pgsql-general-owner+M14597@postgresql.org>
|
|
|
|
|
|
Received: from server1.pgsql.org (server1.pgsql.org [64.39.15.238] (may be forged))
|
|
|
|
|
|
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id f813NEF20222
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Fri, 31 Aug 2001 23:23:14 -0400 (EDT)
|
|
|
|
|
|
Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
|
|
|
|
|
|
by server1.pgsql.org (8.11.6/8.11.6) with ESMTP id f813Njq38048;
|
|
|
|
|
|
Fri, 31 Aug 2001 22:23:46 -0500 (CDT)
|
|
|
|
|
|
(envelope-from pgsql-general-owner+M14597@postgresql.org)
|
|
|
|
|
|
Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222])
|
|
|
|
|
|
by postgresql.org (8.11.3/8.11.4) with ESMTP id f812Yuf42942
|
|
|
|
|
|
for <pgsql-general@postgresql.org>; Fri, 31 Aug 2001 22:35:04 -0400 (EDT)
|
|
|
|
|
|
(envelope-from alex@pilosoft.com)
|
|
|
|
|
|
Received: from localhost (alexmail@localhost)
|
|
|
|
|
|
by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id WAA20075;
|
|
|
|
|
|
Fri, 31 Aug 2001 22:35:23 -0400 (EDT)
|
|
|
|
|
|
Date: Fri, 31 Aug 2001 22:35:23 -0400 (EDT)
|
|
|
|
|
|
From: Alex Pilosov <alex@pilosoft.com>
|
|
|
|
|
|
To: Alex Knight <knight@phunc.com>
|
|
|
|
|
|
cc: pgsql-general@postgresql.org
|
|
|
|
|
|
Subject: [WAY OT] Re: [GENERAL] PL/java?
|
|
|
|
|
|
In-Reply-To: <MAEFKNDLAHNIFMAIEGHJCEKJCDAA.knight@phunc.com>
|
|
|
|
|
|
Message-ID: <Pine.BSO.4.10.10108312220140.19501-100000@spider.pilosoft.com>
|
|
|
|
|
|
MIME-Version: 1.0
|
|
|
|
|
|
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-general-owner@postgresql.org
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
On Fri, 31 Aug 2001, Alex Knight wrote:
|
|
|
|
|
|
|
|
|
|
|
|
> It is generally wiser to split the webservers from the appservers;
|
|
|
|
|
|
> that will save on memory footprints from each respectively. That alone
|
|
|
|
|
|
> can give each machine a specific task to accomplish... generally more
|
|
|
|
|
|
> efficiently. But I would assume you know this.
|
|
|
|
|
|
|
|
|
|
|
|
And it is wise to split database from middleware, and not try to saddle
|
|
|
|
|
|
PostgreSQL with requirements to support Java in-process. _IF_ java stored
|
|
|
|
|
|
procedures are implemented, it should be via something like a) oracle's
|
|
|
|
|
|
extproc (start a separate process to load the function) b) some of perl
|
|
|
|
|
|
java tools (they start a jdk in a separate process and communicate with it
|
|
|
|
|
|
using RMI).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Problem with java-pgsql integration is the threads model: Java really
|
|
|
|
|
|
really wants threads. Postgres doesn't do threads. So if most simple way
|
|
|
|
|
|
is attempted, you will incur overhead of starting up JVM for each backend
|
|
|
|
|
|
(a few seconds as opposed to milliseconds) and non-shared 30M of memory
|
|
|
|
|
|
per backend (as opposed to currently <3 megs of non-shared memory per
|
|
|
|
|
|
backend).
|
|
|
|
|
|
|
|
|
|
|
|
> Using something like WebLogic, WebSphere, or Orion would be a wiser
|
|
|
|
|
|
> approach. For the company with the low budget, Orion is only something
|
|
|
|
|
|
> like $2000, and it has full J2EE support, including EJBs, etc. Try
|
|
|
|
|
|
> finding that kind of richness in Tomcat. Also, Orion takes up only
|
|
|
|
|
|
> 40-50mb at start, which is really fairly reasonable; ram is cheap
|
|
|
|
|
|
> anyways... a server that has to perform complicated algorithms to a
|
|
|
|
|
|
> large audience but has hardly any ram shouldn't be on the internet
|
|
|
|
|
|
> anyways; unless it can handle it.
|
|
|
|
|
|
|
|
|
|
|
|
_ONLY_ 40-50Mb?! Egads, I'm hard pressed to find any other piece of
|
|
|
|
|
|
(non-windows, non-java) software that takes 40-50M just to start up!
|
|
|
|
|
|
|
|
|
|
|
|
I worked with both CrapLogic and CrapSphere. Weblogic takes 20-60 seconds
|
|
|
|
|
|
to start up on P3-800, that, IMHO, is ridiculous.
|
|
|
|
|
|
|
|
|
|
|
|
It is not only issue of memory, its easy to throw memory at the problem,
|
|
|
|
|
|
its an issue of _incremental use_ of memory. As you scale
|
|
|
|
|
|
|
|
|
|
|
|
> I feel that you don't really have enough experience with _java_ to
|
|
|
|
|
|
> judge it accurately. Frankly, the JVM is quite small nowadays,
|
|
|
|
|
|
> considering the amount of base classes that sit in memory much of the
|
|
|
|
|
|
> time. And the JVMs are really much faster these days. Java is still
|
|
|
|
|
|
> slow for 2 reasons: 1) Developers who don't optimize their code as
|
|
|
|
|
|
> they write it, 2) Bytecode interpretation is and probably never will
|
|
|
|
|
|
> be as fast as something like C/C++. But it certainly isn't the JVM
|
|
|
|
|
|
> itself slowing it down because of some "extended memory" that it lives
|
|
|
|
|
|
> in. Any reasonable server should have absolutely no problems if the
|
|
|
|
|
|
> jvm is implemented _properly_ (which many packages do not do), etc. If
|
|
|
|
|
|
> you're comparing Java to perl, yes, certainly it's a bit more of a
|
|
|
|
|
|
> beast, but perl quite simply can't keep up in speed and feature
|
|
|
|
|
|
> richness (when was the last time you secured your perl code in a
|
|
|
|
|
|
> redistributable fashion?)
|
|
|
|
|
|
_WHY_ the heck do all base classes need to be in memory all the time? Why
|
|
|
|
|
|
are they so huge? Libc is _far far_ smaller, and libstdc++ is tiny
|
|
|
|
|
|
compared to all the java standard library.
|
|
|
|
|
|
|
|
|
|
|
|
You know what the answer to it is: Because they are ALL written in java,
|
|
|
|
|
|
as opposed to more sane languages like perl which handcode their "standard
|
|
|
|
|
|
libraries" or the most important pieces of them in C.
|
|
|
|
|
|
|
|
|
|
|
|
Perl is far faster than java in about any practical application I did.
|
|
|
|
|
|
Again, the issue is not speed of JVM versus PP (perl virtual machine), if
|
|
|
|
|
|
you did number crunching in perl and java, they would probably be at par.
|
|
|
|
|
|
Its an issue of standard libraries. They are _horribly slow_. Perl's
|
|
|
|
|
|
hashtables are a very nice piece of optimized C code. Java's hashtables
|
|
|
|
|
|
are written in Java. Need I say more? Java's AWT was a dog. Swing is a dog
|
|
|
|
|
|
and a half, because they reimplemented all the things that are commonly
|
|
|
|
|
|
done in C in Java.
|
|
|
|
|
|
|
|
|
|
|
|
> The only mistake the developers can make is poorly implementing the
|
|
|
|
|
|
> jvm, but most certainly not Java itself. I've been working on
|
|
|
|
|
|
> architecting and building enterprise level sites and applications for
|
|
|
|
|
|
> nearly 8 years now, and I've seen too many people try to implement
|
|
|
|
|
|
> perl cgi websites for enterprise sites and watch them choke and crawl
|
|
|
|
|
|
> to their knees because of poor system resource handling, lack of
|
|
|
|
|
|
> scalability, etc... I most certainly don't consider a single webserver
|
|
|
|
|
|
> with an appserver and tiny database to be enterprise level either (not
|
|
|
|
|
|
> that I'm inferring you said it was).
|
|
|
|
|
|
You cannot compare a perl CGI script and a J2EE server. Its like comparing
|
|
|
|
|
|
a webserver you wrote yourself vs apache! There are application servers
|
|
|
|
|
|
(or more closely, code libraries) for perl that match what J2EE provides.
|
|
|
|
|
|
|
|
|
|
|
|
--
|
|
|
|
|
|
Alex Pilosov | http://www.acedsl.com/home.html
|
|
|
|
|
|
CTO - Acecape, Inc. | AceDSL:The best ADSL in the world
|
|
|
|
|
|
325 W 38 St. Suite 1005 | (Stealth Marketing Works! :)
|
|
|
|
|
|
New York, NY 10018 |
|
|
|
|
|
|
|
|
|
|
|
|
|
2001-09-04 05:17:53 +08:00
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
|
|
|
|
TIP 3: if posting/reading through Usenet, please send an appropriate
|
|
|
|
|
|
subscribe-nomail command to majordomo@postgresql.org so that your
|
|
|
|
|
|
message can get through to the mailing list cleanly
|
|
|
|
|
|
|
2001-11-30 07:13:19 +08:00
|
|
|
|
From pgsql-hackers-owner+M14652=candle.pha.pa.us=pgman@postgresql.org Thu Oct 25 22:24:44 2001
|
|
|
|
|
|
Return-path: <pgsql-hackers-owner+M14652=candle.pha.pa.us=pgman@postgresql.org>
|
|
|
|
|
|
Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
|
|
|
|
|
|
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id f9Q1Oim04694
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Thu, 25 Oct 2001 21:24:44 -0400 (EDT)
|
|
|
|
|
|
Received: from postgresql.org (webmail.postgresql.org [216.126.85.28])
|
|
|
|
|
|
by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id f9Q1CeR31737
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Thu, 25 Oct 2001 20:21:26 -0500 (CDT)
|
|
|
|
|
|
(envelope-from pgsql-hackers-owner+M14652=candle.pha.pa.us=pgman@postgresql.org)
|
|
|
|
|
|
Received: from smaug.polygnosis.com (smaug.polygnosis.com [195.139.160.201])
|
|
|
|
|
|
by postgresql.org (8.11.3/8.11.4) with ESMTP id f9Q16NP39474
|
|
|
|
|
|
for <pgsql-hackers@postgresql.org>; Thu, 25 Oct 2001 21:06:23 -0400 (EDT)
|
|
|
|
|
|
(envelope-from gunnar@smaug.polygnosis.com)
|
|
|
|
|
|
Received: (from gunnar@localhost)
|
|
|
|
|
|
by smaug.polygnosis.com (8.11.0/8.11.0) id f9Q15nC01560;
|
|
|
|
|
|
Fri, 26 Oct 2001 03:05:49 +0200
|
|
|
|
|
|
To: tweekie <None@news.tht.net>
|
|
|
|
|
|
cc: pgsql-hackers@postgresql.org
|
|
|
|
|
|
Subject: Re: [HACKERS] java virtual machine
|
|
|
|
|
|
References: <3bd825e2_1@Usenet.com>
|
|
|
|
|
|
From: Gunnar =?iso-8859-1?q?R=F8nning?= <gunnar@polygnosis.com>
|
|
|
|
|
|
Date: 26 Oct 2001 03:05:49 +0200
|
|
|
|
|
|
In-Reply-To: <3bd825e2_1@Usenet.com>
|
|
|
|
|
|
Message-ID: <m28zdzmcr6.fsf@smaug.polygnosis.com>
|
|
|
|
|
|
Lines: 19
|
|
|
|
|
|
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
|
|
|
|
|
|
MIME-Version: 1.0
|
|
|
|
|
|
Content-Type: text/plain; charset=iso-8859-1
|
|
|
|
|
|
Content-Transfer-Encoding: 8bit
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
* tweekie <None@news.tht.net> wrote:
|
|
|
|
|
|
|
|
|
|
|
|
|
| I asked this question a while back but got no response - is there any way of
|
|
|
|
|
|
| creating a Java stored procedure in a postgres database ? I can see that
|
|
|
|
|
|
| there is a built-in PL/sql type of environment and a python one but it would
|
|
|
|
|
|
| be nice if I could migrate Java stored procedures in an Oracle database into
|
|
|
|
|
|
| postgres.
|
|
|
|
|
|
|
|
|
|
|
|
|
| Any comments?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It would rock ;-) An Hungarian guy just sent a mail indicating that he
|
|
|
|
|
|
had a first prototype version of something with Kaffe up and running.
|
|
|
|
|
|
But I believe there is a lot of issues to be solved, especially
|
|
|
|
|
|
threading issues...
|
|
|
|
|
|
|
|
|
|
|
|
--
|
|
|
|
|
|
Gunnar R<>nning - gunnar@polygnosis.com
|
|
|
|
|
|
Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
|
|
|
|
|
|
|
|
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
|
|
|
|
TIP 5: Have you checked our extensive FAQ?
|
|
|
|
|
|
|
|
|
|
|
|
http://www.postgresql.org/users-lounge/docs/faq.html
|
|
|
|
|
|
|
2001-12-06 07:12:16 +08:00
|
|
|
|
From pgsql-general-owner+M18147=candle.pha.pa.us=pgman@postgresql.org Mon Dec 3 13:53:24 2001
|
|
|
|
|
|
Return-path: <pgsql-general-owner+M18147=candle.pha.pa.us=pgman@postgresql.org>
|
|
|
|
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; Mon, 3 Dec 2001 12:52:02 -0600 (CST)
|
|
|
|
|
|
(envelope-from pgsql-general-owner+M18147=candle.pha.pa.us=pgman@postgresql.org)
|
|
|
|
|
|
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 <pgsql-general@postgresql.org>; Fri, 30 Nov 2001 04:05:46 -0500 (EST)
|
|
|
|
|
|
(envelope-from hornyakl@freemail.hu)
|
|
|
|
|
|
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 <pgsql-general@postgresql.org>; 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: <3C074DE4.9040905@freemail.hu>
|
|
|
|
|
|
Date: Fri, 30 Nov 2001 10:14:12 +0100
|
|
|
|
|
|
From: Laszlo Hornyak <hornyakl@freemail.hu>
|
|
|
|
|
|
Reply-To: hornyakl@users.sourceforge.net
|
|
|
|
|
|
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: pgsql-general@postgresql.org
|
|
|
|
|
|
Subject: [GENERAL] java stored procedures
|
|
|
|
|
|
Content-Type: text/plain; charset=us-ascii; format=flowed
|
|
|
|
|
|
Content-Transfer-Encoding: 7bit
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-general-owner@postgresql.org
|
|
|
|
|
|
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 pgsql-general-owner+M18182=candle.pha.pa.us=pgman@postgresql.org Tue Dec 4 13:14:09 2001
|
|
|
|
|
|
Return-path: <pgsql-general-owner+M18182=candle.pha.pa.us=pgman@postgresql.org>
|
|
|
|
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; Tue, 4 Dec 2001 12:09:17 -0600 (CST)
|
|
|
|
|
|
(envelope-from pgsql-general-owner+M18182=candle.pha.pa.us=pgman@postgresql.org)
|
|
|
|
|
|
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 doug@wireboard.com)
|
|
|
|
|
|
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 doug@wireboard.com using -f
|
|
|
|
|
|
To: Barry Lind <barry@xythos.com>
|
|
|
|
|
|
cc: Laszlo Hornyak <hornyakl@freemail.hu>, pgsql-general@postgresql.org,
|
|
|
|
|
|
pgsql-jdbc@postgresql.org
|
|
|
|
|
|
Subject: Re: [GENERAL] java stored procedures
|
|
|
|
|
|
References: <3C074DE4.9040905@freemail.hu> <3C0BE325.3020809@xythos.com>
|
|
|
|
|
|
<3C0C937E.9000405@freemail.hu> <3C0CFD82.1030600@xythos.com>
|
|
|
|
|
|
From: Doug McNaught <doug@wireboard.com>
|
|
|
|
|
|
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: <m3itbmeujs.fsf@belphigor.mcnaught.org>
|
|
|
|
|
|
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: pgsql-general-owner@postgresql.org
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
Barry Lind <barry@xythos.com> 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 majordomo@postgresql.org
|
|
|
|
|
|
|
2001-12-29 02:33:44 +08:00
|
|
|
|
From pgsql-jdbc-owner+M2545@postgresql.org Tue Dec 4 12:49:03 2001
|
|
|
|
|
|
Return-path: <pgsql-jdbc-owner+M2545@postgresql.org>
|
|
|
|
|
|
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 fB4Hn1r09487
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Tue, 4 Dec 2001 12:49:01 -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 fB4HmxY25870
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Tue, 4 Dec 2001 12:48:59 -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 fB4HiLN75867;
|
|
|
|
|
|
Tue, 4 Dec 2001 11:44:21 -0600 (CST)
|
|
|
|
|
|
(envelope-from pgsql-jdbc-owner+M2545@postgresql.org)
|
|
|
|
|
|
Received: from barry.xythos.com ([64.139.0.223])
|
|
|
|
|
|
by postgresql.org (8.11.3/8.11.4) with ESMTP id fB4H9bm94568;
|
|
|
|
|
|
Tue, 4 Dec 2001 12:09:38 -0500 (EST)
|
|
|
|
|
|
(envelope-from barry@xythos.com)
|
|
|
|
|
|
Received: from xythos.com (localhost.localdomain [127.0.0.1])
|
|
|
|
|
|
by barry.xythos.com (8.11.6/8.11.6) with ESMTP id fB4Gior02314;
|
|
|
|
|
|
Tue, 4 Dec 2001 08:44:50 -0800
|
|
|
|
|
|
Message-ID: <3C0CFD82.1030600@xythos.com>
|
|
|
|
|
|
Date: Tue, 04 Dec 2001 08:44:50 -0800
|
|
|
|
|
|
From: Barry Lind <barry@xythos.com>
|
|
|
|
|
|
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120
|
|
|
|
|
|
X-Accept-Language: en-us
|
|
|
|
|
|
MIME-Version: 1.0
|
|
|
|
|
|
To: Laszlo Hornyak <hornyakl@freemail.hu>
|
|
|
|
|
|
cc: pgsql-general@postgresql.org, pgsql-jdbc@postgresql.org
|
|
|
|
|
|
Subject: Re: [JDBC] [GENERAL] java stored procedures
|
|
|
|
|
|
References: <3C074DE4.9040905@freemail.hu> <3C0BE325.3020809@xythos.com> <3C0C937E.9000405@freemail.hu>
|
|
|
|
|
|
Content-Type: text/plain; charset=us-ascii; format=flowed
|
|
|
|
|
|
Content-Transfer-Encoding: 7bit
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-jdbc-owner@postgresql.org
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
Laszlo,
|
|
|
|
|
|
|
|
|
|
|
|
I think it would help a lot if you could take a little time to write
|
|
|
|
|
|
down what your planned architecture for a pljava would be. It then
|
|
|
|
|
|
becomes much easier for myself and probably others reading these lists
|
|
|
|
|
|
to make suggestions on ways to improve what you are planning (or
|
|
|
|
|
|
possible problems with your strategy). Without knowing what exactly you
|
|
|
|
|
|
are thinking of doing it is difficult to comment.
|
|
|
|
|
|
|
|
|
|
|
|
But let me try throwing out a few thoughts about how I think this should
|
|
|
|
|
|
be done.
|
|
|
|
|
|
|
|
|
|
|
|
First question is how will the jvm be run? Since postgres is a
|
|
|
|
|
|
multiprocess implementation (i.e. each connection has a separate process
|
|
|
|
|
|
on the server) and since java is a multithreaded implementation (i.e.
|
|
|
|
|
|
one process supporting multiple threads), what should the pljava
|
|
|
|
|
|
implementation look like? I think there should be a single jvm process
|
|
|
|
|
|
for the entire db server that each postgresql process connects to
|
|
|
|
|
|
through sockets/rmi. It will be too expensive to create a new jvm
|
|
|
|
|
|
process for each postgresql connection (expensive in both terms of
|
|
|
|
|
|
memory and cpu, since the startup time for the jvm is significant and it
|
|
|
|
|
|
requires a lot of memory).
|
|
|
|
|
|
|
|
|
|
|
|
Having one jvm that all the postgres backend processes communicate with
|
|
|
|
|
|
makes the whole feature much more complicated, but is necessary in my
|
|
|
|
|
|
opinion.
|
|
|
|
|
|
|
|
|
|
|
|
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 am very interested in hearing what your plans are for pl/java. I
|
|
|
|
|
|
think this is a very difficult project, but one that would be very
|
|
|
|
|
|
useful and welcome.
|
|
|
|
|
|
|
|
|
|
|
|
thanks,
|
|
|
|
|
|
--Barry
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Laszlo Hornyak wrote:
|
|
|
|
|
|
|
|
|
|
|
|
> Hi!
|
|
|
|
|
|
>
|
|
|
|
|
|
> I am such a lame in the licensing area. As much as I know, BSD license
|
|
|
|
|
|
> is more free than GPL. I think it is too early to think about licensing,
|
|
|
|
|
|
> but it`s ok, you won :), when it will be ready(or it will seem to get
|
|
|
|
|
|
> closer to a working thing, currently it looks more like a interresting
|
|
|
|
|
|
> test), I will ask you if you want to distribute it with Postgres, and if
|
|
|
|
|
|
> you say yes, the license will be the same as Postgresql`s license.
|
|
|
|
|
|
> Anyway is this neccessary when it is the part of the distribution?
|
|
|
|
|
|
> Is this ok for you?
|
|
|
|
|
|
>
|
|
|
|
|
|
> thanks,
|
|
|
|
|
|
> Laszlo Hornyak
|
|
|
|
|
|
>
|
|
|
|
|
|
> ps: still waiting for your ideas, suggestions, etc :) I am not memeber
|
|
|
|
|
|
> of the mailing list, please write me dirrectly!
|
|
|
|
|
|
>
|
|
|
|
|
|
> Barry Lind wrote:
|
|
|
|
|
|
>
|
|
|
|
|
|
>> Laszlo,
|
|
|
|
|
|
>>
|
|
|
|
|
|
>> In my mind it would be more useful if this code was under the same
|
|
|
|
|
|
>> license as the rest of postgresql. That way it could become part of
|
|
|
|
|
|
>> the product as opposed to always being a separate component. (Just
|
|
|
|
|
|
>> like plpgsql, pltcl and the other procedural languages).
|
|
|
|
|
|
>>
|
|
|
|
|
|
>> thanks,
|
|
|
|
|
|
>> --Barry
|
|
|
|
|
|
>>
|
|
|
|
|
|
>>
|
|
|
|
|
|
>
|
|
|
|
|
|
>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
|
|
|
|
TIP 4: Don't 'kill -9' the postmaster
|
|
|
|
|
|
|
|
|
|
|
|
From pgsql-jdbc-owner+M2555@postgresql.org Thu Dec 6 10:16:31 2001
|
|
|
|
|
|
Return-path: <pgsql-jdbc-owner+M2555@postgresql.org>
|
|
|
|
|
|
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 fB6FGUZ29382
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 10:16:30 -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 fB6FGTE25863
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 10:16:29 -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 fB6F9lN55201;
|
|
|
|
|
|
Thu, 6 Dec 2001 09:09:48 -0600 (CST)
|
|
|
|
|
|
(envelope-from pgsql-jdbc-owner+M2555@postgresql.org)
|
|
|
|
|
|
Received: from tiger.tigrasoft (fw.tigrasoft.hu [195.70.42.161])
|
|
|
|
|
|
by postgresql.org (8.11.3/8.11.4) with ESMTP id fB4JB2m99252;
|
|
|
|
|
|
Tue, 4 Dec 2001 14:11:03 -0500 (EST)
|
|
|
|
|
|
(envelope-from hornyakl@freemail.hu)
|
|
|
|
|
|
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 UAA07040;
|
|
|
|
|
|
Tue, 4 Dec 2001 20:10:17 +0100
|
|
|
|
|
|
X-Authentication-Warning: tiger.tigrasoft: Host [192.168.0.200] claimed to be freemail.hu
|
|
|
|
|
|
Message-ID: <3C0D219C.1090804@freemail.hu>
|
|
|
|
|
|
Date: Tue, 04 Dec 2001 20:18:52 +0100
|
|
|
|
|
|
From: Laszlo Hornyak <hornyakl@freemail.hu>
|
|
|
|
|
|
Reply-To: hornyakl@users.sourceforge.net
|
|
|
|
|
|
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: Barry Lind <barry@xythos.com>
|
|
|
|
|
|
cc: pgsql-general@postgresql.org, pgsql-jdbc@postgresql.org
|
|
|
|
|
|
Subject: Re: [JDBC] [GENERAL] java stored procedures
|
|
|
|
|
|
References: <3C074DE4.9040905@freemail.hu> <3C0BE325.3020809@xythos.com> <3C0C937E.9000405@freemail.hu> <3C0CFD82.1030600@xythos.com>
|
|
|
|
|
|
Content-Type: text/plain; charset=us-ascii; format=flowed
|
|
|
|
|
|
Content-Transfer-Encoding: 7bit
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-jdbc-owner@postgresql.org
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
Hi!
|
|
|
|
|
|
|
|
|
|
|
|
Barry Lind wrote:
|
|
|
|
|
|
|
|
|
|
|
|
> Laszlo,
|
|
|
|
|
|
>
|
|
|
|
|
|
> I think it would help a lot if you could take a little time to write
|
|
|
|
|
|
> down what your planned architecture for a pljava would be. It then
|
|
|
|
|
|
> becomes much easier for myself and probably others reading these lists
|
|
|
|
|
|
> to make suggestions on ways to improve what you are planning (or
|
|
|
|
|
|
> possible problems with your strategy). Without knowing what exactly
|
|
|
|
|
|
> you are thinking of doing it is difficult to comment.
|
|
|
|
|
|
|
|
|
|
|
|
>
|
|
|
|
|
|
>
|
|
|
|
|
|
> But let me try throwing out a few thoughts about how I think this
|
|
|
|
|
|
> should be done.
|
|
|
|
|
|
>
|
|
|
|
|
|
> First question is how will the jvm be run? Since postgres is a
|
|
|
|
|
|
> multiprocess implementation (i.e. each connection has a separate
|
|
|
|
|
|
> process on the server) and since java is a multithreaded
|
|
|
|
|
|
> implementation (i.e. one process supporting multiple threads), what
|
|
|
|
|
|
> should the pljava implementation look like? I think there should be a
|
|
|
|
|
|
> single jvm process for the entire db server that each postgresql
|
|
|
|
|
|
> process connects to through sockets/rmi. It will be too expensive to
|
|
|
|
|
|
> create a new jvm process for each postgresql connection (expensive in
|
|
|
|
|
|
> both terms of memory and cpu, since the startup time for the jvm is
|
|
|
|
|
|
> significant and it requires a lot of memory).
|
|
|
|
|
|
|
|
|
|
|
|
I absolutely agree. OK, it`s done.
|
|
|
|
|
|
|
|
|
|
|
|
So, a late-night-brainstorming here:
|
|
|
|
|
|
What I would like to see in PL/JAVA is the object oriented features,
|
|
|
|
|
|
that makes postgresql nice. Creating a new table creates a new class in
|
|
|
|
|
|
the java side too. Instantiating an object of the newly created class
|
|
|
|
|
|
inserts a row into the table. In postgresql tables can be inherited, and
|
|
|
|
|
|
this could be easyly done by pl/java too. I think this would look nice.
|
|
|
|
|
|
But this is not the main feature. Why I would like to see a nice java
|
|
|
|
|
|
procedural language inside postgres is java`s advanced communication
|
|
|
|
|
|
features (I mean CORBA, jdbc, other protocols). This is the sugar in the
|
|
|
|
|
|
caffe.
|
|
|
|
|
|
|
|
|
|
|
|
I am very far from features like this.
|
|
|
|
|
|
PL/JAVA now:
|
|
|
|
|
|
-there is a separate process running java (kaffe). this process creates
|
|
|
|
|
|
a sys v message queue, that holds requests. almost forgot, a shared
|
|
|
|
|
|
memory segment too. I didn`t find better way to tell postgres the
|
|
|
|
|
|
informations about the java process.
|
|
|
|
|
|
-the java request_handler function on the server side attaches to the
|
|
|
|
|
|
shared memory, reads the key of the message queue., attaches to it,
|
|
|
|
|
|
sends the data of the function, and a signal for the pl/java. after, it
|
|
|
|
|
|
is waiting for a signal from the java thread.
|
|
|
|
|
|
-when java thread receives the signal, it reads the message(s) from the
|
|
|
|
|
|
queue, and starts some actions. When done it tells postgres with a
|
|
|
|
|
|
signal that it is ready, and it can come for its results. This will be
|
|
|
|
|
|
rewritten see below problems.
|
|
|
|
|
|
-And postgres is runing, while java is waiting for postgres to say
|
|
|
|
|
|
something.
|
|
|
|
|
|
|
|
|
|
|
|
Threading on the java process side is not done yet, ok, it is not that
|
|
|
|
|
|
hard, I will write it, if it will be realy neccessary.
|
|
|
|
|
|
|
|
|
|
|
|
The problems, for now:
|
|
|
|
|
|
I had a very simple system, that passed a very limited scale of argument
|
|
|
|
|
|
types, with a very limited quantity of parameters (int, varchar, bool).
|
|
|
|
|
|
Postgres has limits for the argument count too, but not for types. It
|
|
|
|
|
|
had too much limits, so I am working (or to tell the truth now only
|
|
|
|
|
|
thinking) on a new type handling that fits the felxibility of
|
|
|
|
|
|
Postgresql`s type flexibility. For this I will have to learn a lot about
|
|
|
|
|
|
Postgres`s type system. This will be my program this weekend. :)
|
|
|
|
|
|
|
|
|
|
|
|
thanks,
|
|
|
|
|
|
Laszlo Hornyak
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
|
|
|
|
TIP 5: Have you checked our extensive FAQ?
|
|
|
|
|
|
|
|
|
|
|
|
http://www.postgresql.org/users-lounge/docs/faq.html
|
|
|
|
|
|
|
|
|
|
|
|
From pgsql-jdbc-owner+M2549@postgresql.org Tue Dec 4 22:34:48 2001
|
|
|
|
|
|
Return-path: <pgsql-jdbc-owner+M2549@postgresql.org>
|
|
|
|
|
|
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 fB53Ykr17433
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Tue, 4 Dec 2001 22:34:47 -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 fB53YkY26794
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Tue, 4 Dec 2001 22:34:46 -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 fB53UcN93073;
|
|
|
|
|
|
Tue, 4 Dec 2001 21:30:38 -0600 (CST)
|
|
|
|
|
|
(envelope-from pgsql-jdbc-owner+M2549@postgresql.org)
|
|
|
|
|
|
Received: from barry.xythos.com (h-64-105-36-191.SNVACAID.covad.net [64.105.36.191])
|
|
|
|
|
|
by postgresql.org (8.11.3/8.11.4) with ESMTP id fB53Obm35215;
|
|
|
|
|
|
Tue, 4 Dec 2001 22:24:37 -0500 (EST)
|
|
|
|
|
|
(envelope-from barry@xythos.com)
|
|
|
|
|
|
Received: from xythos.com (localhost.localdomain [127.0.0.1])
|
|
|
|
|
|
by barry.xythos.com (8.11.6/8.11.6) with ESMTP id fB51YLJ03883;
|
|
|
|
|
|
Tue, 4 Dec 2001 17:34:21 -0800
|
|
|
|
|
|
Message-ID: <3C0D799D.4010808@xythos.com>
|
|
|
|
|
|
Date: Tue, 04 Dec 2001 17:34:21 -0800
|
|
|
|
|
|
From: Barry Lind <barry@xythos.com>
|
|
|
|
|
|
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120
|
|
|
|
|
|
X-Accept-Language: en-us
|
|
|
|
|
|
MIME-Version: 1.0
|
|
|
|
|
|
To: hornyakl@users.sourceforge.net
|
|
|
|
|
|
cc: pgsql-general@postgresql.org, pgsql-jdbc@postgresql.org
|
|
|
|
|
|
Subject: Re: [JDBC] [GENERAL] java stored procedures
|
|
|
|
|
|
References: <3C074DE4.9040905@freemail.hu> <3C0BE325.3020809@xythos.com> <3C0C937E.9000405@freemail.hu> <3C0CFD82.1030600@xythos.com> <3C0D219C.1090804@freemail.hu>
|
|
|
|
|
|
Content-Type: text/plain; charset=us-ascii; format=flowed
|
|
|
|
|
|
Content-Transfer-Encoding: 7bit
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-jdbc-owner@postgresql.org
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
Laszlo,
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
> I am very far from features like this.
|
|
|
|
|
|
> PL/JAVA now:
|
|
|
|
|
|
> -there is a separate process running java (kaffe). this process creates
|
|
|
|
|
|
> a sys v message queue, that holds requests. almost forgot, a shared
|
|
|
|
|
|
> memory segment too. I didn`t find better way to tell postgres the
|
|
|
|
|
|
> informations about the java process.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Does the mechanism you are planning support running any JVM? In my
|
|
|
|
|
|
opionion Kaffe isn't good enough to be widely useful. I think you
|
|
|
|
|
|
should be able to plugin whatever jvm is best on your platform, which
|
|
|
|
|
|
will likely be either the Sun or IBM JVMs.
|
|
|
|
|
|
|
|
|
|
|
|
Also, can you explain this a little bit more. How does the jvm process
|
|
|
|
|
|
get started? (I would hope that the postgresql server processes would
|
|
|
|
|
|
start it when needed, as opposed to requiring that it be started
|
|
|
|
|
|
separately.) How does the jvm access these shared memory structures?
|
|
|
|
|
|
Since there aren't any methods in the java API to do such things that I
|
|
|
|
|
|
am aware of.
|
|
|
|
|
|
|
|
|
|
|
|
> -the java request_handler function on the server side attaches to the
|
|
|
|
|
|
> shared memory, reads the key of the message queue., attaches to it,
|
|
|
|
|
|
> sends the data of the function, and a signal for the pl/java. after, it
|
|
|
|
|
|
> is waiting for a signal from the java thread.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I don't understand how you do this in java? I must not be understanding
|
|
|
|
|
|
something correctly here.
|
|
|
|
|
|
|
|
|
|
|
|
> -when java thread receives the signal, it reads the message(s) from the
|
|
|
|
|
|
> queue, and starts some actions. When done it tells postgres with a
|
|
|
|
|
|
> signal that it is ready, and it can come for its results. This will be
|
|
|
|
|
|
> rewritten see below problems.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Are signals the best way to accomplish this?
|
|
|
|
|
|
|
|
|
|
|
|
> -And postgres is runing, while java is waiting for postgres to say
|
|
|
|
|
|
> something.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
But in reality if the postgres process is executing a stored function it
|
|
|
|
|
|
needs to wait for the result of that function call before continuing
|
|
|
|
|
|
doesn't it?
|
|
|
|
|
|
|
|
|
|
|
|
>
|
|
|
|
|
|
> Threading on the java process side is not done yet, ok, it is not that
|
|
|
|
|
|
> hard, I will write it, if it will be realy neccessary.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Agreed, this is important.
|
|
|
|
|
|
|
|
|
|
|
|
>
|
|
|
|
|
|
> The problems, for now:
|
|
|
|
|
|
> I had a very simple system, that passed a very limited scale of argument
|
|
|
|
|
|
> types, with a very limited quantity of parameters (int, varchar, bool).
|
|
|
|
|
|
> Postgres has limits for the argument count too, but not for types. It
|
|
|
|
|
|
> had too much limits, so I am working (or to tell the truth now only
|
|
|
|
|
|
> thinking) on a new type handling that fits the felxibility of
|
|
|
|
|
|
> Postgresql`s type flexibility. For this I will have to learn a lot about
|
|
|
|
|
|
> Postgres`s type system. This will be my program this weekend. :)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Shouldn't this code use all or most of the logic found in the FE/BE
|
|
|
|
|
|
protocol? Why invent and code another mechanism to transfer data when
|
|
|
|
|
|
one already exists. (I will admit that the current FE/BE mechanism
|
|
|
|
|
|
isn't the ideal choice, but it seems easier to reuse what exists for now
|
|
|
|
|
|
and improve on it later).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
>
|
|
|
|
|
|
> thanks,
|
|
|
|
|
|
> Laszlo Hornyak
|
|
|
|
|
|
>
|
|
|
|
|
|
|
|
|
|
|
|
You didn't mention how you plan to deal with the transaction symantics.
|
|
|
|
|
|
So what happens when the pl/java function calls through jdbc back to
|
|
|
|
|
|
the server to insert some data? That should happen in the same
|
|
|
|
|
|
transaction as the caller correct?
|
|
|
|
|
|
|
|
|
|
|
|
thanks,
|
|
|
|
|
|
--Barry
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
|
|
|
|
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
|
|
|
|
|
|
|
|
|
|
|
From pgsql-jdbc-owner+M2559@postgresql.org Thu Dec 6 10:18:55 2001
|
|
|
|
|
|
Return-path: <pgsql-jdbc-owner+M2559@postgresql.org>
|
|
|
|
|
|
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 fB6FIrZ29672
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 10:18:54 -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 fB6FIrE26972
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 10:18:53 -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 fB6F9nN55205;
|
|
|
|
|
|
Thu, 6 Dec 2001 09:09:49 -0600 (CST)
|
|
|
|
|
|
(envelope-from pgsql-jdbc-owner+M2559@postgresql.org)
|
|
|
|
|
|
Received: from tiger.tigrasoft (fw.tigrasoft.hu [195.70.42.161])
|
|
|
|
|
|
by postgresql.org (8.11.3/8.11.4) with ESMTP id fB58wVm49422;
|
|
|
|
|
|
Wed, 5 Dec 2001 03:58:31 -0500 (EST)
|
|
|
|
|
|
(envelope-from hornyakl@freemail.hu)
|
|
|
|
|
|
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 JAA12365;
|
|
|
|
|
|
Wed, 5 Dec 2001 09:57:35 +0100
|
|
|
|
|
|
X-Authentication-Warning: tiger.tigrasoft: Host [192.168.0.200] claimed to be freemail.hu
|
|
|
|
|
|
Message-ID: <3C0DE382.1050400@freemail.hu>
|
|
|
|
|
|
Date: Wed, 05 Dec 2001 10:06:10 +0100
|
|
|
|
|
|
From: Laszlo Hornyak <hornyakl@freemail.hu>
|
|
|
|
|
|
Reply-To: hornyakl@users.sourceforge.net
|
|
|
|
|
|
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: Barry Lind <barry@xythos.com>
|
|
|
|
|
|
cc: hornyakl@users.sourceforge.net, pgsql-general@postgresql.org,
|
|
|
|
|
|
pgsql-jdbc@postgresql.org
|
|
|
|
|
|
Subject: Re: [JDBC] [GENERAL] java stored procedures
|
|
|
|
|
|
References: <3C074DE4.9040905@freemail.hu> <3C0BE325.3020809@xythos.com> <3C0C937E.9000405@freemail.hu> <3C0CFD82.1030600@xythos.com> <3C0D219C.1090804@freemail.hu> <3C0D799D.4010808@xythos.com>
|
|
|
|
|
|
Content-Type: text/plain; charset=us-ascii; format=flowed
|
|
|
|
|
|
Content-Transfer-Encoding: 7bit
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-jdbc-owner@postgresql.org
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
Hi!
|
|
|
|
|
|
|
|
|
|
|
|
Barry Lind wrote:
|
|
|
|
|
|
|
|
|
|
|
|
> Does the mechanism you are planning support running any JVM? In my
|
|
|
|
|
|
> opionion Kaffe isn't good enough to be widely useful. I think you
|
|
|
|
|
|
> should be able to plugin whatever jvm is best on your platform, which
|
|
|
|
|
|
> will likely be either the Sun or IBM JVMs.
|
|
|
|
|
|
|
|
|
|
|
|
Ok, I also had problems with caffe, but it may work. I like it becouse
|
|
|
|
|
|
it is small (the source is about 6M). As much as I know Java VM`s has a
|
|
|
|
|
|
somewhat standard native interface called JNI. I use this to start the
|
|
|
|
|
|
VM, and communicate with it. If you think I should change I will do it,
|
|
|
|
|
|
but it may take a long time to get the new VM. For then I have to run kaffe.
|
|
|
|
|
|
|
|
|
|
|
|
> Also, can you explain this a little bit more. How does the jvm
|
|
|
|
|
|
> process get started? (I would hope that the postgresql server
|
|
|
|
|
|
> processes would start it when needed, as opposed to requiring that it
|
|
|
|
|
|
> be started separately.) How does the jvm access these shared memory
|
|
|
|
|
|
> structures? Since there aren't any methods in the java API to do such
|
|
|
|
|
|
> things that I am aware of.
|
|
|
|
|
|
|
|
|
|
|
|
JVM does not. 'the java process' does with simple posix calls. I use
|
|
|
|
|
|
debian potatoe, on any other posix system it should work, on any other
|
|
|
|
|
|
somewhat posix compatible system it may work, I am not sure...
|
|
|
|
|
|
|
|
|
|
|
|
>
|
|
|
|
|
|
> I don't understand how you do this in java? I must not be
|
|
|
|
|
|
> understanding something correctly here.
|
|
|
|
|
|
|
|
|
|
|
|
My failure.
|
|
|
|
|
|
The 'java request_handler' is not a java function, it is the C
|
|
|
|
|
|
call_handler in the Postgres side, that is started when a function of
|
|
|
|
|
|
language 'pljava' is called.
|
|
|
|
|
|
I made some failure in my previous mail. At home I named the pl/java
|
|
|
|
|
|
language pl/pizza (something that is not caffe, but well known enough
|
|
|
|
|
|
:). The application has two running binaries:
|
|
|
|
|
|
-pizza (which was called 'java process' last time) This is a small C
|
|
|
|
|
|
program that uses JNI to start VM and call java methods.
|
|
|
|
|
|
-plpizza.so the shared object that contains the call_handler function.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
>
|
|
|
|
|
|
>
|
|
|
|
|
|
>> -when java thread receives the signal, it reads the message(s) from
|
|
|
|
|
|
>> the queue, and starts some actions. When done it tells postgres with
|
|
|
|
|
|
>> a signal that it is ready, and it can come for its results. This will
|
|
|
|
|
|
>> be rewritten see below problems.
|
|
|
|
|
|
>
|
|
|
|
|
|
>
|
|
|
|
|
|
>
|
|
|
|
|
|
> Are signals the best way to accomplish this?
|
|
|
|
|
|
|
|
|
|
|
|
I don`t know if it is the best, it is the only way I know :)
|
|
|
|
|
|
Do you know any other ways?
|
|
|
|
|
|
|
|
|
|
|
|
>
|
|
|
|
|
|
>
|
|
|
|
|
|
>> -And postgres is runing, while java is waiting for postgres to say
|
|
|
|
|
|
>> something.
|
|
|
|
|
|
>
|
|
|
|
|
|
> But in reality if the postgres process is executing a stored function
|
|
|
|
|
|
> it needs to wait for the result of that function call before
|
|
|
|
|
|
> continuing doesn't it?
|
|
|
|
|
|
|
|
|
|
|
|
Surely, this is done. How could Postgres tell the result anyway ? :)
|
|
|
|
|
|
|
|
|
|
|
|
>
|
|
|
|
|
|
>>
|
|
|
|
|
|
>> Threading on the java process side is not done yet, ok, it is not
|
|
|
|
|
|
>> that hard, I will write it, if it will be realy neccessary.
|
|
|
|
|
|
>
|
|
|
|
|
|
> Agreed, this is important.
|
|
|
|
|
|
>
|
|
|
|
|
|
> Shouldn't this code use all or most of the logic found in the FE/BE
|
|
|
|
|
|
> protocol? Why invent and code another mechanism to transfer data when
|
|
|
|
|
|
> one already exists. (I will admit that the current FE/BE mechanism
|
|
|
|
|
|
> isn't the ideal choice, but it seems easier to reuse what exists for
|
|
|
|
|
|
> now and improve on it later).
|
|
|
|
|
|
|
|
|
|
|
|
Well, I am relatively new to Postgres, and I don`t know these protocols.
|
|
|
|
|
|
In the weekend I will start to learn it, and in Sunday or Monday I maybe
|
|
|
|
|
|
I will understand it, if not, next weekend..
|
|
|
|
|
|
|
|
|
|
|
|
>
|
|
|
|
|
|
> You didn't mention how you plan to deal with the transaction
|
|
|
|
|
|
> symantics. So what happens when the pl/java function calls through
|
|
|
|
|
|
> jdbc back to the server to insert some data? That should happen in
|
|
|
|
|
|
> the same transaction as the caller correct?
|
|
|
|
|
|
|
|
|
|
|
|
I don`t think this will be a problem, I have ideas for this. Idea mean:
|
|
|
|
|
|
I know how I will start it, it may be good, or it may be fataly stupid
|
|
|
|
|
|
idea, it will turn out when I tried it. Simply: The same way plpizza
|
|
|
|
|
|
tells pizza the request, pizza can talk back to plpizza. This is planed
|
|
|
|
|
|
to work with similar mechanism I described last time (shm+signals).
|
|
|
|
|
|
|
|
|
|
|
|
Monday I will try to send a little pieces of code to make thing clear, ok?
|
|
|
|
|
|
|
|
|
|
|
|
thanks,
|
|
|
|
|
|
Laszlo Hornyak
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
|
|
|
|
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
|
|
|
|
|
|
|
|
|
|
|
From pgsql-jdbc-owner+M2567@postgresql.org Thu Dec 6 12:05:50 2001
|
|
|
|
|
|
Return-path: <pgsql-jdbc-owner+M2567@postgresql.org>
|
|
|
|
|
|
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 fB6H5nZ07357
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 12:05:49 -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 fB6H5ma17427
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 12:05:48 -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 fB6H1DN59312;
|
|
|
|
|
|
Thu, 6 Dec 2001 11:01:13 -0600 (CST)
|
|
|
|
|
|
(envelope-from pgsql-jdbc-owner+M2567@postgresql.org)
|
|
|
|
|
|
Received: from barry.xythos.com (h-64-105-36-191.SNVACAID.covad.net [64.105.36.191])
|
|
|
|
|
|
by postgresql.org (8.11.3/8.11.4) with ESMTP id fB6Gtsm73872;
|
|
|
|
|
|
Thu, 6 Dec 2001 11:55:55 -0500 (EST)
|
|
|
|
|
|
(envelope-from barry@xythos.com)
|
|
|
|
|
|
Received: from xythos.com (localhost.localdomain [127.0.0.1])
|
|
|
|
|
|
by barry.xythos.com (8.11.6/8.11.6) with ESMTP id fB5HWJ902835;
|
|
|
|
|
|
Wed, 5 Dec 2001 09:32:19 -0800
|
|
|
|
|
|
Message-ID: <3C0E5A23.7060701@xythos.com>
|
|
|
|
|
|
Date: Wed, 05 Dec 2001 09:32:19 -0800
|
|
|
|
|
|
From: Barry Lind <barry@xythos.com>
|
|
|
|
|
|
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120
|
|
|
|
|
|
X-Accept-Language: en-us
|
|
|
|
|
|
MIME-Version: 1.0
|
|
|
|
|
|
To: hornyakl@users.sourceforge.net
|
|
|
|
|
|
cc: pgsql-hackers@postgresql.org, pgsql-jdbc@postgresql.org
|
|
|
|
|
|
Subject: Re: [JDBC] [GENERAL] java stored procedures
|
|
|
|
|
|
References: <3C074DE4.9040905@freemail.hu> <3C0BE325.3020809@xythos.com> <3C0C937E.9000405@freemail.hu> <3C0CFD82.1030600@xythos.com> <3C0D219C.1090804@freemail.hu> <3C0D799D.4010808@xythos.com> <3C0DE382.1050400@freemail.hu>
|
|
|
|
|
|
Content-Type: text/plain; charset=us-ascii; format=flowed
|
|
|
|
|
|
Content-Transfer-Encoding: 7bit
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-jdbc-owner@postgresql.org
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
Laszlo,
|
|
|
|
|
|
|
|
|
|
|
|
I have cc'ed the hackers mail list since that group of developers is
|
|
|
|
|
|
probably better able than I to make suggestions on the best interprocess
|
|
|
|
|
|
communication mechanism to use for this. See
|
|
|
|
|
|
http://archives2.us.postgresql.org/pgsql-general/2001-12/msg00092.php
|
|
|
|
|
|
for background on this thread.
|
|
|
|
|
|
|
|
|
|
|
|
I also stopped cc'ing the general list, since this is getting too
|
|
|
|
|
|
detailed for most of the members on that list.
|
|
|
|
|
|
|
|
|
|
|
|
Now to your mail:
|
|
|
|
|
|
|
|
|
|
|
|
Laszlo Hornyak wrote:
|
|
|
|
|
|
|
|
|
|
|
|
> Hi!
|
|
|
|
|
|
>
|
|
|
|
|
|
> Barry Lind wrote:
|
|
|
|
|
|
>
|
|
|
|
|
|
>> Does the mechanism you are planning support running any JVM? In my
|
|
|
|
|
|
>> opionion Kaffe isn't good enough to be widely useful. I think you
|
|
|
|
|
|
>> should be able to plugin whatever jvm is best on your platform, which
|
|
|
|
|
|
>> will likely be either the Sun or IBM JVMs.
|
|
|
|
|
|
>
|
|
|
|
|
|
>
|
|
|
|
|
|
> Ok, I also had problems with caffe, but it may work. I like it becouse
|
|
|
|
|
|
> it is small (the source is about 6M). As much as I know Java VM`s has a
|
|
|
|
|
|
> somewhat standard native interface called JNI. I use this to start the
|
|
|
|
|
|
> VM, and communicate with it. If you think I should change I will do it,
|
|
|
|
|
|
> but it may take a long time to get the new VM. For then I have to run
|
|
|
|
|
|
> kaffe.
|
|
|
|
|
|
>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This seems like a reasonable approach and should work across different
|
|
|
|
|
|
JVMs. It would probably be a good experiment to try this with the Sun
|
|
|
|
|
|
or IBM jvm at some point to verify. What I was afraid of was that you
|
|
|
|
|
|
were hacking the Kaffe code to perform the integration which would limit
|
|
|
|
|
|
this solution to only using Kaffe.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
>> Also, can you explain this a little bit more. How does the jvm
|
|
|
|
|
|
>> process get started? (I would hope that the postgresql server
|
|
|
|
|
|
>> processes would start it when needed, as opposed to requiring that it
|
|
|
|
|
|
>> be started separately.) How does the jvm access these shared memory
|
|
|
|
|
|
>> structures? Since there aren't any methods in the java API to do such
|
|
|
|
|
|
>> things that I am aware of.
|
|
|
|
|
|
>
|
|
|
|
|
|
>
|
|
|
|
|
|
> JVM does not. 'the java process' does with simple posix calls. I use
|
|
|
|
|
|
> debian potatoe, on any other posix system it should work, on any other
|
|
|
|
|
|
> somewhat posix compatible system it may work, I am not sure...
|
|
|
|
|
|
>
|
|
|
|
|
|
>>
|
|
|
|
|
|
>> I don't understand how you do this in java? I must not be
|
|
|
|
|
|
>> understanding something correctly here.
|
|
|
|
|
|
>
|
|
|
|
|
|
>
|
|
|
|
|
|
> My failure.
|
|
|
|
|
|
> The 'java request_handler' is not a java function, it is the C
|
|
|
|
|
|
> call_handler in the Postgres side, that is started when a function of
|
|
|
|
|
|
> language 'pljava' is called.
|
|
|
|
|
|
> I made some failure in my previous mail. At home I named the pl/java
|
|
|
|
|
|
> language pl/pizza (something that is not caffe, but well known enough
|
|
|
|
|
|
> :). The application has two running binaries:
|
|
|
|
|
|
> -pizza (which was called 'java process' last time) This is a small C
|
|
|
|
|
|
> program that uses JNI to start VM and call java methods.
|
|
|
|
|
|
> -plpizza.so the shared object that contains the call_handler function.
|
|
|
|
|
|
>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Just a suggestion: PL/J might be a good name, since as you probably
|
|
|
|
|
|
know it can't be called pl/java because of the trademark restrictions on
|
|
|
|
|
|
the word 'java'.
|
|
|
|
|
|
|
|
|
|
|
|
I am a little concerned about the stability and complexity of having
|
|
|
|
|
|
this '-pizza' program be responsible for handling the calls on the java
|
|
|
|
|
|
side. My concern is that this will need to be a multithreaded program
|
|
|
|
|
|
since multiple backends will concurrently be needing to interact with
|
|
|
|
|
|
multiple java threads through this one program. It might be simpler if
|
|
|
|
|
|
each postgres process directly communicated to a java thread via a tcpip
|
|
|
|
|
|
socket. Then the "-pizza" program would only need to be responsible for
|
|
|
|
|
|
starting up the jvm and creating java threads and sockets for a postgres
|
|
|
|
|
|
process (it would perform a similar role to postmaster for postgres
|
|
|
|
|
|
client connections).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
>
|
|
|
|
|
|
>>
|
|
|
|
|
|
>>
|
|
|
|
|
|
>>> -when java thread receives the signal, it reads the message(s) from
|
|
|
|
|
|
>>> the queue, and starts some actions. When done it tells postgres with
|
|
|
|
|
|
>>> a signal that it is ready, and it can come for its results. This will
|
|
|
|
|
|
>>> be rewritten see below problems.
|
|
|
|
|
|
>>
|
|
|
|
|
|
>>
|
|
|
|
|
|
>>
|
|
|
|
|
|
>>
|
|
|
|
|
|
>> Are signals the best way to accomplish this?
|
|
|
|
|
|
>
|
|
|
|
|
|
>
|
|
|
|
|
|
> I don`t know if it is the best, it is the only way I know :)
|
|
|
|
|
|
> Do you know any other ways?
|
|
|
|
|
|
>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I don't know, but hopefully someone on the hackers list will chip in
|
|
|
|
|
|
here with a comment.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
>>
|
|
|
|
|
|
>>>
|
|
|
|
|
|
>>> Threading on the java process side is not done yet, ok, it is not
|
|
|
|
|
|
>>> that hard, I will write it, if it will be realy neccessary.
|
|
|
|
|
|
>>
|
|
|
|
|
|
>>
|
|
|
|
|
|
>> Agreed, this is important.
|
|
|
|
|
|
>>
|
|
|
|
|
|
>> Shouldn't this code use all or most of the logic found in the FE/BE
|
|
|
|
|
|
>> protocol? Why invent and code another mechanism to transfer data when
|
|
|
|
|
|
>> one already exists. (I will admit that the current FE/BE mechanism
|
|
|
|
|
|
>> isn't the ideal choice, but it seems easier to reuse what exists for
|
|
|
|
|
|
>> now and improve on it later).
|
|
|
|
|
|
>
|
|
|
|
|
|
>
|
|
|
|
|
|
> Well, I am relatively new to Postgres, and I don`t know these protocols.
|
|
|
|
|
|
> In the weekend I will start to learn it, and in Sunday or Monday I maybe
|
|
|
|
|
|
> I will understand it, if not, next weekend..
|
|
|
|
|
|
>
|
|
|
|
|
|
>>
|
|
|
|
|
|
>> You didn't mention how you plan to deal with the transaction
|
|
|
|
|
|
>> symantics. So what happens when the pl/java function calls through
|
|
|
|
|
|
>> jdbc back to the server to insert some data? That should happen in
|
|
|
|
|
|
>> the same transaction as the caller correct?
|
|
|
|
|
|
>
|
|
|
|
|
|
>
|
|
|
|
|
|
> I don`t think this will be a problem, I have ideas for this. Idea mean:
|
|
|
|
|
|
> I know how I will start it, it may be good, or it may be fataly stupid
|
|
|
|
|
|
> idea, it will turn out when I tried it. Simply: The same way plpizza
|
|
|
|
|
|
> tells pizza the request, pizza can talk back to plpizza. This is planed
|
|
|
|
|
|
> to work with similar mechanism I described last time (shm+signals).
|
|
|
|
|
|
>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OK, so the same backend process that called the function gets messaged
|
|
|
|
|
|
to process the sql. This should work. However it means you will need a
|
|
|
|
|
|
special version of the jdbc driver that uses this shm+signals
|
|
|
|
|
|
communication mechanism instead of what the current jdbc driver does.
|
|
|
|
|
|
This is something I would be happy to help you with.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
|
|
|
|
TIP 5: Have you checked our extensive FAQ?
|
|
|
|
|
|
|
|
|
|
|
|
http://www.postgresql.org/users-lounge/docs/faq.html
|
|
|
|
|
|
|
2001-12-30 01:06:22 +08:00
|
|
|
|
From pgsql-hackers-owner+M16317=candle.pha.pa.us=pgman@postgresql.org Thu Dec 6 10:11:27 2001
|
|
|
|
|
|
Return-path: <pgsql-hackers-owner+M16317=candle.pha.pa.us=pgman@postgresql.org>
|
|
|
|
|
|
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 fB6FBQZ28795
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 10:11:26 -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 fB6FBPE23613
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 10:11:25 -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 fB6F5MR55091
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 09:08:01 -0600 (CST)
|
|
|
|
|
|
(envelope-from pgsql-hackers-owner+M16317=candle.pha.pa.us=pgman@postgresql.org)
|
|
|
|
|
|
Received: from tiger.tigrasoft (fw.tigrasoft.hu [195.70.42.161])
|
|
|
|
|
|
by postgresql.org (8.11.3/8.11.4) with ESMTP id fB5JWMm92521;
|
|
|
|
|
|
Wed, 5 Dec 2001 14:32:26 -0500 (EST)
|
|
|
|
|
|
(envelope-from hornyakl@freemail.hu)
|
|
|
|
|
|
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 UAA20333;
|
|
|
|
|
|
Wed, 5 Dec 2001 20:30:51 +0100
|
|
|
|
|
|
X-Authentication-Warning: tiger.tigrasoft: Host [192.168.0.200] claimed to be freemail.hu
|
|
|
|
|
|
Message-ID: <3C0E77F0.5030904@freemail.hu>
|
|
|
|
|
|
Date: Wed, 05 Dec 2001 20:39:28 +0100
|
|
|
|
|
|
From: Laszlo Hornyak <hornyakl@freemail.hu>
|
|
|
|
|
|
Reply-To: hornyakl@users.sourceforge.net
|
|
|
|
|
|
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: Barry Lind <barry@xythos.com>, pgsql-hackers@postgresql.org,
|
|
|
|
|
|
pgsql-jdbc@postgresql.org
|
|
|
|
|
|
Subject: Re: [HACKERS] [GENERAL] java stored procedures
|
|
|
|
|
|
References: <3C074DE4.9040905@freemail.hu> <3C0BE325.3020809@xythos.com> <3C0C937E.9000405@freemail.hu> <3C0CFD82.1030600@xythos.com> <3C0D219C.1090804@freemail.hu> <3C0D799D.4010808@xythos.com> <3C0DE382.1050400@freemail.hu> <3C0E5A23.7060701@xythos.com>
|
|
|
|
|
|
Content-Type: text/plain; charset=us-ascii; format=flowed
|
|
|
|
|
|
Content-Transfer-Encoding: 7bit
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
Barry Lind wrote:
|
|
|
|
|
|
|
|
|
|
|
|
>
|
|
|
|
|
|
> I also stopped cc'ing the general list, since this is getting too
|
|
|
|
|
|
> detailed for most of the members on that list.
|
|
|
|
|
|
|
|
|
|
|
|
Ok.
|
|
|
|
|
|
|
|
|
|
|
|
> Now to your mail:
|
|
|
|
|
|
>
|
|
|
|
|
|
> This seems like a reasonable approach and should work across different
|
|
|
|
|
|
> JVMs. It would probably be a good experiment to try this with the Sun
|
|
|
|
|
|
> or IBM jvm at some point to verify. What I was afraid of was that you
|
|
|
|
|
|
> were hacking the Kaffe code to perform the integration which would
|
|
|
|
|
|
> limit this solution to only using Kaffe.
|
|
|
|
|
|
|
|
|
|
|
|
I am sure they wont work the same way. I think I have a sun jdk 1.3.0-2,
|
|
|
|
|
|
so I will try to port it soon. The IBM implementation must wait I think
|
|
|
|
|
|
until january.
|
|
|
|
|
|
|
|
|
|
|
|
>
|
|
|
|
|
|
> Just a suggestion: PL/J might be a good name, since as you probably
|
|
|
|
|
|
> know it can't be called pl/java because of the trademark restrictions
|
|
|
|
|
|
> on the word 'java'.
|
|
|
|
|
|
|
|
|
|
|
|
Ok, you won, I do not read the licenses. From now it`s name is pl/j.
|
|
|
|
|
|
Isn`t 'j' too short for the name of the process that runns java? :)
|
|
|
|
|
|
|
|
|
|
|
|
>
|
|
|
|
|
|
> I am a little concerned about the stability and complexity of having
|
|
|
|
|
|
> this '-pizza' program be responsible for handling the calls on the
|
|
|
|
|
|
> java side. My concern is that this will need to be a multithreaded
|
|
|
|
|
|
> program since multiple backends will concurrently be needing to
|
|
|
|
|
|
> interact with multiple java threads through this one program. It
|
|
|
|
|
|
> might be simpler if each postgres process directly communicated to a
|
|
|
|
|
|
> java thread via a tcpip socket. Then the "-pizza" program would only
|
|
|
|
|
|
> need to be responsible for starting up the jvm and creating java
|
|
|
|
|
|
> threads and sockets for a postgres process (it would perform a similar
|
|
|
|
|
|
> role to postmaster for postgres client connections).
|
|
|
|
|
|
|
|
|
|
|
|
With good design we can solve stability problems. As much as I know, if
|
|
|
|
|
|
postmaster dies, the postgres server becomes unavailable, this looks the
|
|
|
|
|
|
same problem. I do not know if we realy need sockets. Anyway, if 'j'
|
|
|
|
|
|
dies, we can create a new one, and restart calculations. Some watchdog
|
|
|
|
|
|
functionality...
|
|
|
|
|
|
Doing thing with sockets need a lot of rework. It is the best time for
|
|
|
|
|
|
this, while there is not too much thing done.
|
|
|
|
|
|
|
|
|
|
|
|
>>>
|
|
|
|
|
|
>>>> -when java thread receives the signal, it reads the message(s) from
|
|
|
|
|
|
>>>> the queue, and starts some actions. When done it tells postgres
|
|
|
|
|
|
>>>> with a signal that it is ready, and it can come for its results.
|
|
|
|
|
|
>>>> This will be rewritten see below problems.
|
|
|
|
|
|
>>>
|
|
|
|
|
|
>>> Are signals the best way to accomplish this?
|
|
|
|
|
|
>>
|
|
|
|
|
|
>> I don`t know if it is the best, it is the only way I know :)
|
|
|
|
|
|
>> Do you know any other ways?
|
|
|
|
|
|
>>
|
|
|
|
|
|
> I don't know, but hopefully someone on the hackers list will chip in
|
|
|
|
|
|
> here with a comment.
|
|
|
|
|
|
|
|
|
|
|
|
After a first developement cycle (if my brain doesn`t burn down), the
|
|
|
|
|
|
signals can be replaced to a plugable communication interface I think.
|
|
|
|
|
|
So maybe we can use CORBA, or sockets, or something else. This will take
|
|
|
|
|
|
a lot of time.
|
|
|
|
|
|
|
|
|
|
|
|
> OK, so the same backend process that called the function gets messaged
|
|
|
|
|
|
> to process the sql. This should work. However it means you will need
|
|
|
|
|
|
> a special version of the jdbc driver that uses this shm+signals
|
|
|
|
|
|
> communication mechanism instead of what the current jdbc driver does.
|
|
|
|
|
|
> This is something I would be happy to help you with.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is kind of you. :)
|
|
|
|
|
|
For this, I will have to finish the protocol of communication. I have to
|
|
|
|
|
|
learn Postgres enough, so I am not sure this will be done this weekend.
|
|
|
|
|
|
I have ideas, only time is needed to implement them or to recognize the
|
|
|
|
|
|
failures.
|
|
|
|
|
|
|
|
|
|
|
|
Thanks,
|
|
|
|
|
|
Laszlo Hornyak
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
|
|
|
|
TIP 4: Don't 'kill -9' the postmaster
|
|
|
|
|
|
|
|
|
|
|
|
From pgsql-hackers-owner+M16313=candle.pha.pa.us=pgman@postgresql.org Thu Dec 6 10:01:29 2001
|
|
|
|
|
|
Return-path: <pgsql-hackers-owner+M16313=candle.pha.pa.us=pgman@postgresql.org>
|
|
|
|
|
|
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 fB6F1RZ28000
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 10:01:27 -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 fB6F1OE19111
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 10:01:25 -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 fB6EvtR54729
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 08:59:16 -0600 (CST)
|
|
|
|
|
|
(envelope-from pgsql-hackers-owner+M16313=candle.pha.pa.us=pgman@postgresql.org)
|
|
|
|
|
|
Received: from tiger.tigrasoft (fw.tigrasoft.hu [195.70.42.161])
|
|
|
|
|
|
by postgresql.org (8.11.3/8.11.4) with ESMTP id fB6EFfm64066;
|
|
|
|
|
|
Thu, 6 Dec 2001 09:15:41 -0500 (EST)
|
|
|
|
|
|
(envelope-from hornyakl@freemail.hu)
|
|
|
|
|
|
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 PAA29094;
|
|
|
|
|
|
Thu, 6 Dec 2001 15:15:01 +0100
|
|
|
|
|
|
X-Authentication-Warning: tiger.tigrasoft: Host [192.168.0.200] claimed to be freemail.hu
|
|
|
|
|
|
Message-ID: <3C0F7F6B.2060605@freemail.hu>
|
|
|
|
|
|
Date: Thu, 06 Dec 2001 15:23:39 +0100
|
|
|
|
|
|
From: Laszlo Hornyak <hornyakl@freemail.hu>
|
|
|
|
|
|
Reply-To: hornyakl@users.sourceforge.net
|
|
|
|
|
|
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: Gunnar =?ISO-8859-1?Q?R=F8nning?= <gunnar@polygnosis.com>
|
|
|
|
|
|
cc: Barry Lind <barry@xythos.com>, pgsql-hackers@postgresql.org,
|
|
|
|
|
|
pgsql-jdbc@postgresql.org
|
|
|
|
|
|
Subject: Re: [HACKERS] [GENERAL] java stored procedures
|
|
|
|
|
|
References: <3C074DE4.9040905@freemail.hu> <3C0BE325.3020809@xythos.com> <3C0C937E.9000405@freemail.hu> <3C0CFD82.1030600@xythos.com> <m2zo4wttp1.fsf@smaug.polygnosis.com>
|
|
|
|
|
|
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
|
|
|
|
|
|
Content-Transfer-Encoding: 8bit
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
Hi!
|
|
|
|
|
|
|
|
|
|
|
|
Sorry, I have time only for short ansvers, it is company time :((.
|
|
|
|
|
|
|
|
|
|
|
|
Gunnar R<>nning wrote:
|
|
|
|
|
|
|
|
|
|
|
|
>* Barry Lind <barry@xythos.com> wrote:
|
|
|
|
|
|
>|
|
|
|
|
|
|
>| possible problems with your strategy). Without knowing what exactly
|
|
|
|
|
|
>| you are thinking of doing it is difficult to comment.
|
|
|
|
|
|
>
|
|
|
|
|
|
>Agreed.
|
|
|
|
|
|
>
|
|
|
|
|
|
Ok, I will try to bring the code here before Monday, or at least some
|
|
|
|
|
|
pieces. It is full of hardcoded constants from my developement
|
|
|
|
|
|
environment. :(
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
>
|
|
|
|
|
|
>| I am very interested in hearing what your plans are for pl/java. I
|
|
|
|
|
|
>| think this is a very difficult project, but one that would be very
|
|
|
|
|
|
>| useful and welcome.
|
|
|
|
|
|
>
|
|
|
|
|
|
>I would very much like to hear about the plans myself.
|
|
|
|
|
|
>
|
|
|
|
|
|
I do not see so big difficulities yet, am I so lame? It won`t be easy,
|
|
|
|
|
|
realy, we should keep it simple, at least becouse of me.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
thanks,
|
|
|
|
|
|
Laszlo Hornyak
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
|
|
|
|
TIP 3: if posting/reading through Usenet, please send an appropriate
|
|
|
|
|
|
subscribe-nomail command to majordomo@postgresql.org so that your
|
|
|
|
|
|
message can get through to the mailing list cleanly
|
|
|
|
|
|
|
|
|
|
|
|
From pgsql-hackers-owner+M16334=candle.pha.pa.us=pgman@postgresql.org Thu Dec 6 16:11:23 2001
|
|
|
|
|
|
Return-path: <pgsql-hackers-owner+M16334=candle.pha.pa.us=pgman@postgresql.org>
|
|
|
|
|
|
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 fB6LBLZ25078
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 16:11:22 -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 fB6LBMa12305
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 16:11:22 -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 fB6L6wR66812
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Thu, 6 Dec 2001 15:08:01 -0600 (CST)
|
|
|
|
|
|
(envelope-from pgsql-hackers-owner+M16334=candle.pha.pa.us=pgman@postgresql.org)
|
|
|
|
|
|
Received: from rh72.home.ee (adsl895.estpak.ee [213.168.23.133])
|
|
|
|
|
|
by postgresql.org (8.11.3/8.11.4) with ESMTP id fB6Kxtm98840;
|
|
|
|
|
|
Thu, 6 Dec 2001 15:59:55 -0500 (EST)
|
|
|
|
|
|
(envelope-from hannu@tm.ee)
|
|
|
|
|
|
Received: from tm.ee (localhost.localdomain [127.0.0.1])
|
|
|
|
|
|
by rh72.home.ee (8.11.6/8.11.6) with ESMTP id fB6I2pn02024;
|
|
|
|
|
|
Thu, 6 Dec 2001 23:02:52 +0500
|
|
|
|
|
|
Message-ID: <3C0FB2CB.90901@tm.ee>
|
|
|
|
|
|
Date: Thu, 06 Dec 2001 23:02:51 +0500
|
|
|
|
|
|
From: Hannu Krosing <hannu@tm.ee>
|
|
|
|
|
|
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
|
|
|
|
|
|
X-Accept-Language: et, en-us
|
|
|
|
|
|
MIME-Version: 1.0
|
|
|
|
|
|
To: hornyakl@users.sourceforge.net
|
|
|
|
|
|
cc: Gunnar =?ISO-8859-1?Q?R=F8nning?= <gunnar@polygnosis.com>,
|
|
|
|
|
|
Barry Lind
|
|
|
|
|
|
<barry@xythos.com>, pgsql-hackers@postgresql.org,
|
|
|
|
|
|
pgsql-jdbc@postgresql.org
|
|
|
|
|
|
Subject: Re: [HACKERS] [GENERAL] java stored procedures
|
|
|
|
|
|
References: <3C074DE4.9040905@freemail.hu> <3C0BE325.3020809@xythos.com> <3C0C937E.9000405@freemail.hu> <3C0CFD82.1030600@xythos.com> <m2zo4wttp1.fsf@smaug.polygnosis.com> <3C0F7F6B.2060605@freemail.hu>
|
|
|
|
|
|
Content-Type: text/plain; charset=us-ascii; format=flowed
|
|
|
|
|
|
Content-Transfer-Encoding: 7bit
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
Laszlo Hornyak wrote:
|
|
|
|
|
|
|
|
|
|
|
|
>>
|
|
|
|
|
|
>> | I am very interested in hearing what your plans are for pl/java. I
|
|
|
|
|
|
>> | think this is a very difficult project, but one that would be very
|
|
|
|
|
|
>> | useful and welcome.
|
|
|
|
|
|
>>
|
|
|
|
|
|
>> I would very much like to hear about the plans myself.
|
|
|
|
|
|
>
|
|
|
|
|
|
> I do not see so big difficulities yet, am I so lame? It won`t be easy,
|
|
|
|
|
|
> realy, we should keep it simple, at least becouse of me.
|
|
|
|
|
|
|
|
|
|
|
|
Let me propose a very different approach to PL/J - use gcc-java and
|
|
|
|
|
|
figure out the problems
|
|
|
|
|
|
with (dynamic) compiling and dynamic linking.
|
|
|
|
|
|
|
|
|
|
|
|
This is an approach somewhat similar to .NET/C# that you first compile
|
|
|
|
|
|
things and then run instead
|
|
|
|
|
|
of trying to do both at the same time ;)
|
|
|
|
|
|
|
|
|
|
|
|
Oracle /may/ be doing something similar with their java stored
|
|
|
|
|
|
procedures, as they claim these to be "compiled".
|
|
|
|
|
|
|
|
|
|
|
|
-----------------
|
|
|
|
|
|
Hannu
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
|
|
|
|
TIP 3: if posting/reading through Usenet, please send an appropriate
|
|
|
|
|
|
subscribe-nomail command to majordomo@postgresql.org so that your
|
|
|
|
|
|
message can get through to the mailing list cleanly
|
|
|
|
|
|
|
2002-01-04 01:18:19 +08:00
|
|
|
|
From pgsql-hackers-owner+M17140@postgresql.org Thu Jan 3 09:13:32 2002
|
|
|
|
|
|
Return-path: <pgsql-hackers-owner+M17140@postgresql.org>
|
|
|
|
|
|
Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
|
|
|
|
|
|
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g03EDVc00444
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Thu, 3 Jan 2002 09:13:31 -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 g03E41N54463;
|
|
|
|
|
|
Thu, 3 Jan 2002 08:04:01 -0600 (CST)
|
|
|
|
|
|
(envelope-from pgsql-hackers-owner+M17140@postgresql.org)
|
|
|
|
|
|
Received: from tiger.tigrasoft (fw.tigrasoft.hu [195.70.42.161])
|
|
|
|
|
|
by postgresql.org (8.11.3/8.11.4) with ESMTP id g01Csdm40742
|
|
|
|
|
|
for <pgsql-hackers@postgresql.org>; Tue, 1 Jan 2002 07:54:39 -0500 (EST)
|
|
|
|
|
|
(envelope-from hornyakl@freemail.hu)
|
|
|
|
|
|
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 NAA14425;
|
|
|
|
|
|
Tue, 1 Jan 2002 13:54:35 +0100
|
|
|
|
|
|
X-Authentication-Warning: tiger.tigrasoft: Host [192.168.0.200] claimed to be freemail.hu
|
|
|
|
|
|
Message-ID: <3C31B3B7.6030703@freemail.hu>
|
|
|
|
|
|
Date: Tue, 01 Jan 2002 14:03:51 +0100
|
|
|
|
|
|
From: Laszlo Hornyak <hornyakl@freemail.hu>
|
|
|
|
|
|
Reply-To: hornyakl@users.sourceforge.net
|
|
|
|
|
|
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: pgsql-hackers@postgresql.org, ssutjiono@wc-group.com
|
|
|
|
|
|
Subject: [HACKERS] PL/(pg)J
|
|
|
|
|
|
Content-Type: text/plain; charset=us-ascii; format=flowed
|
|
|
|
|
|
Content-Transfer-Encoding: 7bit
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
Happy new year for all!
|
|
|
|
|
|
|
|
|
|
|
|
I would like to tell you about the results of my work on pl/j.
|
|
|
|
|
|
memo: Java and postgres must run in a separate address space. First I
|
|
|
|
|
|
wanted to use the sys v ipc, which was a bad idea becouse of some
|
|
|
|
|
|
problems with java VM-s. Many hackers told me about its bad sides, and
|
|
|
|
|
|
the good sides of the sockets, so I droped the whole code and started a
|
|
|
|
|
|
new one.
|
|
|
|
|
|
|
|
|
|
|
|
I started to write the java side first, which is maybe almost 10% ready :))
|
|
|
|
|
|
-we have is a communication protocol between the two process. I know
|
|
|
|
|
|
noone will like it, so there is an API for protocols, so it is plugable.
|
|
|
|
|
|
The current implementation is receiveing calls,sends exceptions, but
|
|
|
|
|
|
sending the results is not implemented yet.
|
|
|
|
|
|
|
|
|
|
|
|
-the Postgres side is not yet done. It sends function calls without
|
|
|
|
|
|
arguments, it doesn`t receive sql queries, exceptions or results at all,
|
|
|
|
|
|
and there is no API for it, it is an uggly hardcoded thing.
|
|
|
|
|
|
|
|
|
|
|
|
-there is no JDBC implementation, and I have never written JDBC driver,
|
|
|
|
|
|
so it may take for a while...
|
|
|
|
|
|
|
|
|
|
|
|
But it says "hello world" :))
|
|
|
|
|
|
|
|
|
|
|
|
Todo for me:
|
|
|
|
|
|
|
|
|
|
|
|
-learn more about postgres, jdbc drivers, etc, etc
|
|
|
|
|
|
-develop api for the postgres side of the communication.
|
|
|
|
|
|
|
|
|
|
|
|
This will take for a good while becouse of other todos but I hope next
|
|
|
|
|
|
time I can tell you good news.
|
|
|
|
|
|
|
|
|
|
|
|
thx,
|
|
|
|
|
|
Laszlo Hornyak
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
|
|
|
|
TIP 5: Have you checked our extensive FAQ?
|
|
|
|
|
|
|
|
|
|
|
|
http://www.postgresql.org/users-lounge/docs/faq.html
|
|
|
|
|
|
|
2002-01-25 10:30:49 +08:00
|
|
|
|
From pgsql-general-owner+M19758=candle.pha.pa.us=pgman@postgresql.org Wed Jan 23 11:33:11 2002
|
|
|
|
|
|
Return-path: <pgsql-general-owner+M19758=candle.pha.pa.us=pgman@postgresql.org>
|
|
|
|
|
|
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
|
|
|
|
|
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g0NGXAU13298
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Wed, 23 Jan 2002 11:33:10 -0500 (EST)
|
|
|
|
|
|
Received: (qmail 89931 invoked by alias); 23 Jan 2002 16:32:58 -0000
|
|
|
|
|
|
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
|
|
|
|
|
by www.postgresql.org with SMTP; 23 Jan 2002 16:32:58 -0000
|
|
|
|
|
|
Received: from barry.xythos.com (h-64-105-36-191.SNVACAID.covad.net [64.105.36.191])
|
|
|
|
|
|
by postgresql.org (8.11.3/8.11.4) with ESMTP id g0NG9Tl75462
|
|
|
|
|
|
for <pgsql-general@postgresql.org>; Wed, 23 Jan 2002 11:09:29 -0500 (EST)
|
|
|
|
|
|
(envelope-from barry@xythos.com)
|
|
|
|
|
|
Received: from xythos.com (localhost.localdomain [127.0.0.1])
|
|
|
|
|
|
by barry.xythos.com (8.11.6/8.11.6) with ESMTP id g0N1sGn24841;
|
|
|
|
|
|
Tue, 22 Jan 2002 17:54:16 -0800
|
|
|
|
|
|
Message-ID: <3C4E17C8.8040909@xythos.com>
|
|
|
|
|
|
Date: Tue, 22 Jan 2002 17:54:16 -0800
|
|
|
|
|
|
From: Barry Lind <barry@xythos.com>
|
|
|
|
|
|
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221
|
|
|
|
|
|
X-Accept-Language: en-us
|
|
|
|
|
|
MIME-Version: 1.0
|
|
|
|
|
|
To: Nic Ferrier <nferrier@tapsellferrier.co.uk>
|
|
|
|
|
|
cc: Doug McNaught <doug@wireboard.com>, pgsql-general@postgresql.org
|
|
|
|
|
|
Subject: Re: [GENERAL] implemention of calls to stored procs.
|
|
|
|
|
|
References: <87sn8yx6xu.fsf@tf1.tapsellferrier.co.uk> <m3r8oh6i1a.fsf@varsoon.denali.to> <87n0z5yjer.fsf@tf1.tapsellferrier.co.uk>
|
|
|
|
|
|
Content-Type: text/plain; charset=us-ascii; format=flowed
|
|
|
|
|
|
Content-Transfer-Encoding: 7bit
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-general-owner@postgresql.org
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
Nic,
|
|
|
|
|
|
|
|
|
|
|
|
Check out http://www.rootshell.be/~hornyakl/download
|
|
|
|
|
|
This has the latest code for pl/pgj. The Java procedure language support
|
|
|
|
|
|
that Laszlo Hornyak (hornyakl@users.sourceforge.net) has been working on
|
|
|
|
|
|
for the last month or so.
|
|
|
|
|
|
|
|
|
|
|
|
thanks,
|
|
|
|
|
|
--Barry
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Nic Ferrier wrote:
|
|
|
|
|
|
|
|
|
|
|
|
> Firstly, thanks for your responses... good to know I was thinking the
|
|
|
|
|
|
> right thing (and, yes, I was taking the process thing into account,
|
|
|
|
|
|
> tho' I didn't realise threads weren't used at all).
|
|
|
|
|
|
>
|
|
|
|
|
|
>
|
|
|
|
|
|
> Doug McNaught <doug@wireboard.com> writes:
|
|
|
|
|
|
>
|
|
|
|
|
|
>
|
|
|
|
|
|
>>Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
|
|
|
|
|
|
>>
|
|
|
|
|
|
>>
|
|
|
|
|
|
>>>I've been looking at the implementation of the procedural language
|
|
|
|
|
|
>>>support code with a view to writing a java plugin (ie: something to
|
|
|
|
|
|
>>>allow java classes to be used as stored procs).
|
|
|
|
|
|
>>>
|
|
|
|
|
|
>>
|
|
|
|
|
|
>>Someone else has been talking about this--check the archives from the
|
|
|
|
|
|
>>last six months.
|
|
|
|
|
|
>>
|
|
|
|
|
|
>
|
|
|
|
|
|
> I couldn't find any reference but the archive searcher is broken right
|
|
|
|
|
|
> now and a manual search is not very reliable.
|
|
|
|
|
|
>
|
|
|
|
|
|
> It's not terribly difficult to crack this actually... I was going to
|
|
|
|
|
|
> use GCJ as a platform for a base java class that could be used like a
|
|
|
|
|
|
> quick C stored proc.
|
|
|
|
|
|
>
|
|
|
|
|
|
> I envisage having a natively implemented JDBC Connection passed to an
|
|
|
|
|
|
> init method in such a class.
|
|
|
|
|
|
>
|
|
|
|
|
|
>
|
|
|
|
|
|
> GCJ is perfect for this task because it has a native call interface,
|
|
|
|
|
|
> CNI, which is a seamless part of the class heirarchy.
|
|
|
|
|
|
>
|
|
|
|
|
|
> Once I've got something working I'll drop a line here.
|
|
|
|
|
|
>
|
|
|
|
|
|
>
|
|
|
|
|
|
>
|
|
|
|
|
|
> Nic
|
|
|
|
|
|
>
|
|
|
|
|
|
> ---------------------------(end of broadcast)---------------------------
|
|
|
|
|
|
> TIP 5: Have you checked our extensive FAQ?
|
|
|
|
|
|
>
|
|
|
|
|
|
> http://www.postgresql.org/users-lounge/docs/faq.html
|
|
|
|
|
|
>
|
|
|
|
|
|
>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
|
|
|
|
TIP 3: if posting/reading through Usenet, please send an appropriate
|
|
|
|
|
|
subscribe-nomail command to majordomo@postgresql.org so that your
|
|
|
|
|
|
message can get through to the mailing list cleanly
|
|
|
|
|
|
|
2002-11-02 10:27:49 +08:00
|
|
|
|
From pgsql-hackers-owner+M31158@postgresql.org Wed Oct 30 14:31:27 2002
|
|
|
|
|
|
Return-path: <pgsql-hackers-owner+M31158@postgresql.org>
|
|
|
|
|
|
Received: from postgresql.org (postgresql.org [64.49.215.8])
|
|
|
|
|
|
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g9UJVQU07194
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Wed, 30 Oct 2002 14:31:26 -0500 (EST)
|
|
|
|
|
|
Received: from localhost (postgresql.org [64.49.215.8])
|
|
|
|
|
|
by postgresql.org (Postfix) with ESMTP
|
|
|
|
|
|
id 353C9476C3C; Wed, 30 Oct 2002 14:30:18 -0500 (EST)
|
|
|
|
|
|
Received: from postgresql.org (postgresql.org [64.49.215.8])
|
|
|
|
|
|
by postgresql.org (Postfix) with SMTP
|
|
|
|
|
|
id D8787476C72; Wed, 30 Oct 2002 14:30:06 -0500 (EST)
|
|
|
|
|
|
Received: from localhost (postgresql.org [64.49.215.8])
|
|
|
|
|
|
by postgresql.org (Postfix) with ESMTP id A8D81476C42
|
|
|
|
|
|
for <pgsql-hackers@postgreSQL.org>; Wed, 30 Oct 2002 14:29:57 -0500 (EST)
|
|
|
|
|
|
Received: from sss.pgh.pa.us (unknown [192.204.191.242])
|
|
|
|
|
|
by postgresql.org (Postfix) with ESMTP id 04987476C71
|
|
|
|
|
|
for <pgsql-hackers@postgreSQL.org>; Wed, 30 Oct 2002 14:29:57 -0500 (EST)
|
|
|
|
|
|
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
|
|
|
|
|
by sss.pgh.pa.us (8.12.5/8.12.5) with ESMTP id g9UJTvhR000820
|
|
|
|
|
|
for <pgsql-hackers@postgreSQL.org>; Wed, 30 Oct 2002 14:29:57 -0500 (EST)
|
|
|
|
|
|
To: pgsql-hackers@postgresql.org
|
|
|
|
|
|
Subject: [HACKERS] PG functions in Java: maybe use gcj?
|
|
|
|
|
|
Date: Wed, 30 Oct 2002 14:29:57 -0500
|
|
|
|
|
|
Message-ID: <819.1036006197@sss.pgh.pa.us>
|
|
|
|
|
|
From: Tom Lane <tgl@sss.pgh.pa.us>
|
|
|
|
|
|
X-Virus-Scanned: by AMaViS new-20020517
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
|
|
|
|
X-Virus-Scanned: by AMaViS new-20020517
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
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)
|
|
|
|
|
|
|
|
|
|
|
|
From pgsql-hackers-owner+M31173@postgresql.org Wed Oct 30 22:51:48 2002
|
|
|
|
|
|
Return-path: <pgsql-hackers-owner+M31173@postgresql.org>
|
|
|
|
|
|
Received: from postgresql.org (postgresql.org [64.49.215.8])
|
|
|
|
|
|
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g9V3pkU27163
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Wed, 30 Oct 2002 22:51:46 -0500 (EST)
|
|
|
|
|
|
Received: from localhost (postgresql.org [64.49.215.8])
|
|
|
|
|
|
by postgresql.org (Postfix) with ESMTP
|
|
|
|
|
|
id CC02B476CE9; Wed, 30 Oct 2002 22:51:42 -0500 (EST)
|
|
|
|
|
|
Received: from postgresql.org (postgresql.org [64.49.215.8])
|
|
|
|
|
|
by postgresql.org (Postfix) with SMTP
|
|
|
|
|
|
id 30D78476087; Wed, 30 Oct 2002 22:51:25 -0500 (EST)
|
|
|
|
|
|
Received: from localhost (postgresql.org [64.49.215.8])
|
|
|
|
|
|
by postgresql.org (Postfix) with ESMTP id 49189475A1E
|
|
|
|
|
|
for <pgsql-hackers@postgresql.org>; Wed, 30 Oct 2002 22:51:18 -0500 (EST)
|
|
|
|
|
|
Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
|
|
|
|
|
|
by postgresql.org (Postfix) with ESMTP id B9C5B474E5C
|
|
|
|
|
|
for <pgsql-hackers@postgresql.org>; Wed, 30 Oct 2002 22:51:17 -0500 (EST)
|
|
|
|
|
|
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
|
|
|
|
|
|
id 1876OD-0006U9-00; Thu, 31 Oct 2002 03:53:01 +0000
|
|
|
|
|
|
Received: from h-66-166-17-184.snvacaid.covad.net ([66.166.17.184] helo=xythos.com)
|
|
|
|
|
|
by mail.xythos.com with asmtp (Exim 3.36 #3)
|
|
|
|
|
|
id 1876OC-0006Ty-00; Thu, 31 Oct 2002 03:53:00 +0000
|
|
|
|
|
|
Message-ID: <3DC0AA42.4000205@xythos.com>
|
|
|
|
|
|
Date: Wed, 30 Oct 2002 19:57:54 -0800
|
|
|
|
|
|
From: Barry Lind <blind@xythos.com>
|
|
|
|
|
|
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
|
|
|
|
|
|
X-Accept-Language: en-us, en
|
|
|
|
|
|
MIME-Version: 1.0
|
|
|
|
|
|
To: Tom Lane <tgl@sss.pgh.pa.us>
|
|
|
|
|
|
cc: pgsql-hackers@postgresql.org
|
|
|
|
|
|
Subject: Re: [HACKERS] PG functions in Java: maybe use gcj?
|
|
|
|
|
|
References: <819.1036006197@sss.pgh.pa.us>
|
|
|
|
|
|
Content-Type: text/plain; charset=us-ascii; format=flowed
|
|
|
|
|
|
Content-Transfer-Encoding: 7bit
|
|
|
|
|
|
X-Envelope-To: tgl@sss.pgh.pa.us,
|
|
|
|
|
|
pgsql-hackers@postgreSQL.org
|
|
|
|
|
|
X-Virus-Scanned: by AMaViS new-20020517
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
|
|
|
|
X-Virus-Scanned: by AMaViS new-20020517
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
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/BE protocol 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)
|
|
|
|
|
|
>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
|
|
|
|
TIP 5: Have you checked our extensive FAQ?
|
|
|
|
|
|
|
|
|
|
|
|
http://www.postgresql.org/users-lounge/docs/faq.html
|
|
|
|
|
|
|
|
|
|
|
|
From pgsql-hackers-owner+M31175@postgresql.org Wed Oct 30 23:10:42 2002
|
|
|
|
|
|
Return-path: <pgsql-hackers-owner+M31175@postgresql.org>
|
|
|
|
|
|
Received: from postgresql.org (postgresql.org [64.49.215.8])
|
|
|
|
|
|
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g9V4AeU28809
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Wed, 30 Oct 2002 23:10:41 -0500 (EST)
|
|
|
|
|
|
Received: from localhost (postgresql.org [64.49.215.8])
|
|
|
|
|
|
by postgresql.org (Postfix) with ESMTP
|
|
|
|
|
|
id 8C73B476AD5; Wed, 30 Oct 2002 23:10:33 -0500 (EST)
|
|
|
|
|
|
Received: from postgresql.org (postgresql.org [64.49.215.8])
|
|
|
|
|
|
by postgresql.org (Postfix) with SMTP
|
|
|
|
|
|
id 2E9DC4761DF; Wed, 30 Oct 2002 23:10:31 -0500 (EST)
|
|
|
|
|
|
Received: from localhost (postgresql.org [64.49.215.8])
|
|
|
|
|
|
by postgresql.org (Postfix) with ESMTP id 1A441475A1E
|
|
|
|
|
|
for <pgsql-hackers@postgreSQL.org>; Wed, 30 Oct 2002 23:10:25 -0500 (EST)
|
|
|
|
|
|
Received: from sss.pgh.pa.us (unknown [192.204.191.242])
|
|
|
|
|
|
by postgresql.org (Postfix) with ESMTP id 7D378474E5C
|
|
|
|
|
|
for <pgsql-hackers@postgreSQL.org>; Wed, 30 Oct 2002 23:10:24 -0500 (EST)
|
|
|
|
|
|
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
|
|
|
|
|
by sss.pgh.pa.us (8.12.5/8.12.5) with ESMTP id g9V4AThR003716;
|
|
|
|
|
|
Wed, 30 Oct 2002 23:10:29 -0500 (EST)
|
|
|
|
|
|
To: Barry Lind <blind@xythos.com>
|
|
|
|
|
|
cc: pgsql-hackers@postgresql.org
|
|
|
|
|
|
Subject: Re: [HACKERS] PG functions in Java: maybe use gcj?
|
|
|
|
|
|
In-Reply-To: <3DC0AA42.4000205@xythos.com>
|
|
|
|
|
|
References: <819.1036006197@sss.pgh.pa.us> <3DC0AA42.4000205@xythos.com>
|
|
|
|
|
|
Comments: In-reply-to Barry Lind <blind@xythos.com>
|
|
|
|
|
|
message dated "Wed, 30 Oct 2002 19:57:54 -0800"
|
|
|
|
|
|
Date: Wed, 30 Oct 2002 23:10:28 -0500
|
|
|
|
|
|
Message-ID: <3715.1036037428@sss.pgh.pa.us>
|
|
|
|
|
|
From: Tom Lane <tgl@sss.pgh.pa.us>
|
|
|
|
|
|
X-Virus-Scanned: by AMaViS new-20020517
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
|
|
|
|
X-Virus-Scanned: by AMaViS new-20020517
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
Barry Lind <blind@xythos.com> writes:
|
|
|
|
|
|
> 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.
|
|
|
|
|
|
|
|
|
|
|
|
The impression I had (after not looking very closely) was that you could
|
|
|
|
|
|
expect to compile to bytecodes on the fly and then run the gcj
|
|
|
|
|
|
interpreter. But the .so alternative might be a good fallback if that
|
|
|
|
|
|
doesn't work.
|
|
|
|
|
|
|
|
|
|
|
|
> 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.
|
|
|
|
|
|
|
|
|
|
|
|
Good point, but unless you want to build a BSD-license Java
|
|
|
|
|
|
implementation, there will never be a pljava that doesn't have different
|
|
|
|
|
|
licensing restrictions than PG itself does. gcj is at least more free
|
|
|
|
|
|
than either Sun's or IBM's JVM ...
|
|
|
|
|
|
|
|
|
|
|
|
> Another challenge here it that the java code is going to want to use the
|
|
|
|
|
|
> jdbc api when communicating with the database.
|
|
|
|
|
|
|
|
|
|
|
|
Yes. I think we'd need a new implementation of jdbc that sits atop SPI
|
|
|
|
|
|
(invoked via jni I guess) rather than a FE/BE connection. How well
|
|
|
|
|
|
layered is our jdbc code --- would this mean a large rewrite, or just
|
|
|
|
|
|
rolling in a new bottom layer?
|
|
|
|
|
|
|
|
|
|
|
|
regards, tom lane
|
|
|
|
|
|
|
|
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
|
|
|
|
TIP 3: if posting/reading through Usenet, please send an appropriate
|
|
|
|
|
|
subscribe-nomail command to majordomo@postgresql.org so that your
|
|
|
|
|
|
message can get through to the mailing list cleanly
|
|
|
|
|
|
|
|
|
|
|
|
From pgsql-hackers-owner+M31202@postgresql.org Thu Oct 31 21:18:38 2002
|
|
|
|
|
|
Return-path: <pgsql-hackers-owner+M31202@postgresql.org>
|
|
|
|
|
|
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 gA12ILU00147
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Thu, 31 Oct 2002 21:18:37 -0500 (EST)
|
|
|
|
|
|
Received: from postgresql.org (postgresql.org [64.49.215.8])
|
|
|
|
|
|
by west.navpoint.com (8.11.6/8.10.1) with ESMTP id g9VHv8h08054
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Thu, 31 Oct 2002 12:57:08 -0500 (EST)
|
|
|
|
|
|
Received: from localhost (postgresql.org [64.49.215.8])
|
|
|
|
|
|
by postgresql.org (Postfix) with ESMTP
|
|
|
|
|
|
id 5CA844768F1; Thu, 31 Oct 2002 12:54:18 -0500 (EST)
|
|
|
|
|
|
Received: from postgresql.org (postgresql.org [64.49.215.8])
|
|
|
|
|
|
by postgresql.org (Postfix) with SMTP
|
|
|
|
|
|
id 973E1476060; Thu, 31 Oct 2002 12:54:11 -0500 (EST)
|
|
|
|
|
|
Received: from localhost (postgresql.org [64.49.215.8])
|
|
|
|
|
|
by postgresql.org (Postfix) with ESMTP id 9A45F47668B
|
|
|
|
|
|
for <pgsql-hackers@postgresql.org>; Thu, 31 Oct 2002 12:54:05 -0500 (EST)
|
|
|
|
|
|
Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
|
|
|
|
|
|
by postgresql.org (Postfix) with ESMTP id 0D7F5476684
|
|
|
|
|
|
for <pgsql-hackers@postgresql.org>; Thu, 31 Oct 2002 12:54:05 -0500 (EST)
|
|
|
|
|
|
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
|
|
|
|
|
|
id 187JXx-0006Pc-00; Thu, 31 Oct 2002 17:55:57 +0000
|
|
|
|
|
|
Received: from sdsl-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com)
|
|
|
|
|
|
by mail.xythos.com with asmtp (Exim 3.36 #3)
|
|
|
|
|
|
id 187JXx-0006PR-00; Thu, 31 Oct 2002 17:55:57 +0000
|
|
|
|
|
|
Message-ID: <3DC175F7.90901@xythos.com>
|
|
|
|
|
|
Date: Thu, 31 Oct 2002 10:27:03 -0800
|
|
|
|
|
|
From: Barry Lind <blind@xythos.com>
|
|
|
|
|
|
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
|
|
|
|
|
|
X-Accept-Language: en-us, en
|
|
|
|
|
|
MIME-Version: 1.0
|
|
|
|
|
|
To: Tom Lane <tgl@sss.pgh.pa.us>
|
|
|
|
|
|
cc: pgsql-hackers@postgresql.org
|
|
|
|
|
|
Subject: Re: [HACKERS] PG functions in Java: maybe use gcj?
|
|
|
|
|
|
References: <819.1036006197@sss.pgh.pa.us> <3DC0AA42.4000205@xythos.com> <3715.1036037428@sss.pgh.pa.us>
|
|
|
|
|
|
Content-Type: text/plain; charset=us-ascii; format=flowed
|
|
|
|
|
|
Content-Transfer-Encoding: 7bit
|
|
|
|
|
|
X-Envelope-To: tgl@sss.pgh.pa.us,
|
|
|
|
|
|
pgsql-hackers@postgreSQL.org
|
|
|
|
|
|
X-Virus-Scanned: by AMaViS new-20020517
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
|
|
|
|
X-Virus-Scanned: by AMaViS new-20020517
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Tom Lane wrote:
|
|
|
|
|
|
> Barry Lind <blind@xythos.com> writes:
|
|
|
|
|
|
>
|
|
|
|
|
|
>>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.
|
|
|
|
|
|
>
|
|
|
|
|
|
>
|
|
|
|
|
|
> Good point, but unless you want to build a BSD-license Java
|
|
|
|
|
|
> implementation, there will never be a pljava that doesn't have different
|
|
|
|
|
|
> licensing restrictions than PG itself does. gcj is at least more free
|
|
|
|
|
|
> than either Sun's or IBM's JVM ...
|
|
|
|
|
|
>
|
|
|
|
|
|
|
|
|
|
|
|
It depends on what you mean by more free. An architecture that
|
|
|
|
|
|
interacts with an external jvm would let you use any jvm (free ones as
|
|
|
|
|
|
well as others). From a licensing standpoint it is generally easy to
|
|
|
|
|
|
redistribute a jvm or expect the user to have one installed (most java
|
|
|
|
|
|
based products out there today do this).
|
|
|
|
|
|
|
|
|
|
|
|
However in the proposal here we are talking about requiring a specific
|
|
|
|
|
|
jvm (gcj) and actually linking parts of it into postgres. To the extent
|
|
|
|
|
|
that GPL code is linked in the GPL extends to the entire code base. As
|
|
|
|
|
|
I said previously there are ways to work around this, but it becomes
|
|
|
|
|
|
tricky. Especially when a commercial product wants to bundle postgres
|
|
|
|
|
|
and pljava. That resulting bundle is probably entirely under the GPL
|
|
|
|
|
|
and then any changes to it are also GPL. So it could be the case that
|
|
|
|
|
|
this company would be prevented from submitting improvements they made
|
|
|
|
|
|
back to the core product because their improvements are GPLed as a
|
|
|
|
|
|
result of pljava.
|
|
|
|
|
|
|
|
|
|
|
|
Now having said all that, I have been monitoring the progres of gcj for
|
|
|
|
|
|
some time because I think there are very interesting possibilities. And
|
|
|
|
|
|
I am all for anyone who wants to look into it further and investigate
|
|
|
|
|
|
the possiblities. I just want to raise the licensing issue because it
|
|
|
|
|
|
can cause problems and it is better to think about them up front than
|
|
|
|
|
|
after the fact.
|
|
|
|
|
|
|
|
|
|
|
|
>
|
|
|
|
|
|
>>Another challenge here it that the java code is going to want to use the
|
|
|
|
|
|
>>jdbc api when communicating with the database.
|
|
|
|
|
|
>
|
|
|
|
|
|
>
|
|
|
|
|
|
> Yes. I think we'd need a new implementation of jdbc that sits atop SPI
|
|
|
|
|
|
> (invoked via jni I guess) rather than a FE/BE connection. How well
|
|
|
|
|
|
> layered is our jdbc code --- would this mean a large rewrite, or just
|
|
|
|
|
|
> rolling in a new bottom layer?
|
|
|
|
|
|
>
|
|
|
|
|
|
|
|
|
|
|
|
It isn't as well layered as it could be, but it isn't too bad. Overall
|
|
|
|
|
|
it shouldn't be too much work, but not a little project either. One
|
|
|
|
|
|
area that isn't well layered is the assumption that the raw data from
|
|
|
|
|
|
the server is in text format, since that is what the FE/BE protocol
|
|
|
|
|
|
provides. So all the conversion functions that convert to/from java
|
|
|
|
|
|
datatypes do so in this format. This assumption runs deep into the
|
|
|
|
|
|
code. As a first pass it would be easiest to get raw data from SPI
|
|
|
|
|
|
convert to text and then convert to java datatypes instead of going
|
|
|
|
|
|
directly from the internal SPI format directly to java datatypes. This
|
|
|
|
|
|
could be improved upon later.
|
|
|
|
|
|
|
|
|
|
|
|
> regards, tom lane
|
|
|
|
|
|
>
|
|
|
|
|
|
|
|
|
|
|
|
thanks,
|
|
|
|
|
|
--Barry
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
|
|
|
|
TIP 2: you can get off all lists at once with the unregister command
|
|
|
|
|
|
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
|
|
|
|
|
|
|
|
|
|
|
|
From pgsql-hackers-owner+M31223@postgresql.org Fri Nov 1 07:34:24 2002
|
|
|
|
|
|
Return-path: <pgsql-hackers-owner+M31223@postgresql.org>
|
|
|
|
|
|
Received: from postgresql.org (postgresql.org [64.49.215.8])
|
|
|
|
|
|
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id gA1CYKU23527
|
|
|
|
|
|
for <pgman@candle.pha.pa.us>; Fri, 1 Nov 2002 07:34:21 -0500 (EST)
|
|
|
|
|
|
Received: from localhost (postgresql.org [64.49.215.8])
|
|
|
|
|
|
by postgresql.org (Postfix) with ESMTP
|
|
|
|
|
|
id C48C44762EE; Fri, 1 Nov 2002 07:34:13 -0500 (EST)
|
|
|
|
|
|
Received: from postgresql.org (postgresql.org [64.49.215.8])
|
|
|
|
|
|
by postgresql.org (Postfix) with SMTP
|
|
|
|
|
|
id 1F69C475F34; Fri, 1 Nov 2002 07:34:11 -0500 (EST)
|
|
|
|
|
|
Received: from localhost (postgresql.org [64.49.215.8])
|
|
|
|
|
|
by postgresql.org (Postfix) with ESMTP id 06581474E53
|
|
|
|
|
|
for <pgsql-hackers@postgresql.org>; Fri, 1 Nov 2002 07:34:07 -0500 (EST)
|
|
|
|
|
|
Received: from anchor-post-39.mail.demon.net (anchor-post-39.mail.demon.net [194.217.242.80])
|
|
|
|
|
|
by postgresql.org (Postfix) with ESMTP id 7D34D474E44
|
|
|
|
|
|
for <pgsql-hackers@postgresql.org>; Fri, 1 Nov 2002 07:34:06 -0500 (EST)
|
|
|
|
|
|
Received: from lfix.demon.co.uk ([158.152.59.127] helo=linda.lfix.co.uk)
|
|
|
|
|
|
by anchor-post-39.mail.demon.net with esmtp (Exim 3.36 #2)
|
|
|
|
|
|
id 187b04-0002Pj-0U
|
|
|
|
|
|
for pgsql-hackers@postgresql.org; Fri, 01 Nov 2002 12:34:08 +0000
|
|
|
|
|
|
Received: from localhost
|
|
|
|
|
|
([127.0.0.1] helo=localhost.localdomain ident=olly)
|
|
|
|
|
|
by linda.lfix.co.uk with esmtp (Exim 3.36 #1 (Debian))
|
|
|
|
|
|
id 187b04-0007zb-00
|
|
|
|
|
|
for <pgsql-hackers@postgresql.org>; Fri, 01 Nov 2002 12:34:08 +0000
|
|
|
|
|
|
Subject: Re: [HACKERS] PG functions in Java: maybe use gcj?
|
|
|
|
|
|
From: Oliver Elphick <olly@lfix.co.uk>
|
|
|
|
|
|
To: pgsql-hackers@postgresql.org
|
|
|
|
|
|
In-Reply-To: <3DC175F7.90901@xythos.com>
|
|
|
|
|
|
References: <819.1036006197@sss.pgh.pa.us> <3DC0AA42.4000205@xythos.com>
|
|
|
|
|
|
<3715.1036037428@sss.pgh.pa.us> <3DC175F7.90901@xythos.com>
|
|
|
|
|
|
Content-Type: text/plain
|
|
|
|
|
|
Content-Transfer-Encoding: 7bit
|
|
|
|
|
|
X-Mailer: Ximian Evolution 1.0.8
|
|
|
|
|
|
Date: 01 Nov 2002 12:34:08 +0000
|
|
|
|
|
|
Message-ID: <1036154048.7925.73.camel@linda>
|
|
|
|
|
|
MIME-Version: 1.0
|
|
|
|
|
|
X-Virus-Scanned: by AMaViS new-20020517
|
|
|
|
|
|
Precedence: bulk
|
|
|
|
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
|
|
|
|
X-Virus-Scanned: by AMaViS new-20020517
|
|
|
|
|
|
Status: OR
|
|
|
|
|
|
|
|
|
|
|
|
On Thu, 2002-10-31 at 18:27, Barry Lind wrote:
|
|
|
|
|
|
|
|
|
|
|
|
> However in the proposal here we are talking about requiring a specific
|
|
|
|
|
|
> jvm (gcj) and actually linking parts of it into postgres. To the extent
|
|
|
|
|
|
> that GPL code is linked in the GPL extends to the entire code base. As
|
|
|
|
|
|
> I said previously there are ways to work around this, but it becomes
|
|
|
|
|
|
> tricky. Especially when a commercial product wants to bundle postgres
|
|
|
|
|
|
> and pljava. That resulting bundle is probably entirely under the GPL
|
|
|
|
|
|
> and then any changes to it are also GPL. So it could be the case that
|
|
|
|
|
|
> this company would be prevented from submitting improvements they made
|
|
|
|
|
|
> back to the core product because their improvements are GPLed as a
|
|
|
|
|
|
> result of pljava.
|
|
|
|
|
|
|
|
|
|
|
|
Nothing that company does can affect the licensing of PostgreSQL itself
|
|
|
|
|
|
- it doesn't belong to them, so they cannot change its licence.
|
|
|
|
|
|
|
|
|
|
|
|
Nothing in the GPL forces them to put GPL copyright on their own
|
|
|
|
|
|
alterations.
|
|
|
|
|
|
|
|
|
|
|
|
What they cannot do is to _distribute_ binary code that links to GPL
|
|
|
|
|
|
code while giving fewer rights to their distributees than they
|
|
|
|
|
|
themselves received with the GPL code, whether in respect of their own
|
|
|
|
|
|
code or the GPL code. Therefore they would be required to make their
|
|
|
|
|
|
source changes available to anyone to whom they gave a binary, and they
|
|
|
|
|
|
would not be able to restrict the further distribution of those
|
|
|
|
|
|
changes. They can contribute those changes to the project under
|
|
|
|
|
|
whatever licence they wish that is acceptable to the project.
|
|
|
|
|
|
|
|
|
|
|
|
Furthermore, gcj is part of the GNU compiler collection, like gcc, and
|
|
|
|
|
|
using it does not in itself cause code compiled under it to be subject
|
|
|
|
|
|
to the GPL. Linking to its runtime library would normally cause that,
|
|
|
|
|
|
but the gcj-3.0 copyright contains the following text:
|
|
|
|
|
|
|
|
|
|
|
|
========================================================================
|
|
|
|
|
|
The libgcj library is licensed under the terms of the GNU General
|
|
|
|
|
|
Public License, with this special exception:
|
|
|
|
|
|
|
|
|
|
|
|
As a special exception, if you link this library with other files
|
|
|
|
|
|
to produce an executable, this library does not by itself cause
|
|
|
|
|
|
the resulting executable to be covered by the GNU General Public
|
|
|
|
|
|
License. This exception does not however invalidate any other
|
|
|
|
|
|
reasons why the executable file might be covered by the GNU
|
|
|
|
|
|
General Public License.
|
|
|
|
|
|
========================================================================
|
|
|
|
|
|
|
|
|
|
|
|
--
|
|
|
|
|
|
Oliver Elphick Oliver.Elphick@lfix.co.uk
|
|
|
|
|
|
Isle of Wight, UK
|
|
|
|
|
|
http://www.lfix.co.uk/oliver
|
|
|
|
|
|
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
|
|
|
|
|
|
========================================
|
|
|
|
|
|
"But they that wait upon the LORD shall renew their
|
|
|
|
|
|
strength; they shall mount up with wings as eagles;
|
|
|
|
|
|
they shall run, and not be weary; and they shall walk,
|
|
|
|
|
|
and not faint." Isaiah 40:31
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---------------------------(end of broadcast)---------------------------
|
|
|
|
|
|
TIP 2: you can get off all lists at once with the unregister command
|
|
|
|
|
|
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
|
|
|
|
|
|
|
