postgresql/doc/TODO.detail/java
2001-09-04 15:40:18 +00:00

910 lines
39 KiB
Plaintext

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
>
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
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
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
---------------------------(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 |
---------------------------(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