Date calc bug
Happy new year to you all!!
I've run into this problem 3 days ago:
Script started on Sun Jan 2 14:59:03 2000
~ 14:59:04: psql
Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL
[PostgreSQL 6.5.3 on i586-pc-unixware7.0.1, compiled by cc ]
type \? for help on slash commands
type \q to quit
type \g or terminate with semicolon to execute query
You are currently connected to the database: ohp
ohp=> select '01-12-1999'::datetime + '@ 1 month - 1 sec' as bug;
bug
----------------------------
Thu 30 Dec 23:59:59 1999 MET
(1 row)
^^
Should be 31!!
ohp=> select '01-01-2000'::datetime + '@ 1 month - 1 sec' as good;
good
----------------------------
Mon 31 Jan 23:59:59 2000 MET
(1 row)
Seems OK after Jan 1rst!!
Any idea?
Regards
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)
From bouncefilter Sun Jan 2 13:03:27 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA96090
for <pgsql-hackers@postgreSQL.org>; Sun, 2 Jan 2000 13:03:08 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id NAA21520;
Sun, 2 Jan 2000 13:02:00 -0500 (EST)
To: ohp@pyrenet.fr
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
pgsql-hackers@postgreSQL.org
Subject: Re: [BUGS] Date calc bug
In-reply-to: <Pine.UW2.4.21.0001021513050.11391-100000@server.pyrenet.fr>
References: <Pine.UW2.4.21.0001021513050.11391-100000@server.pyrenet.fr>
Comments: In-reply-to Olivier PRENANT <ohp@pyrenet.fr>
message dated "Sun, 02 Jan 2000 15:15:47 +0100"
Date: Sun, 02 Jan 2000 13:02:00 -0500
Message-ID: <21517.946836120@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
[ Forwarded to hackers list from bugs list ]
Olivier PRENANT <ohp@pyrenet.fr> writes:
ohp=> select '01-12-1999'::datetime + '@ 1 month - 1 sec' as bug;
Thu 30 Dec 23:59:59 1999 MET
I see it here too, in a different timezone:
select '12-01-1999'::datetime + '@ 1 month - 1 sec' ;
Thu Dec 30 23:59:59 1999 EST
It's not a Y2K issue, because of this similar failure:
select '3-01-1999'::datetime + '@ 1month - 1 sec'::timespan;
Sun Mar 28 23:59:59 1999 EST
See the pattern? I suspect what is going on is that the low-order
(seconds) part of the timespan is being added in before the high-order
(months) part. If you did the calculation in two steps like this:
select '12-01-1999'::datetime + '@ - 1 sec'::timespan;
Tue Nov 30 23:59:59 1999 EST
select 'Tue Nov 30 23:59:59 1999 EST'::datetime + '@ 1 month'::timespan;
Thu Dec 30 23:59:59 1999 EST
then you'd think the result is reasonable.
The question for discussion is whether adding the months part and then
the seconds part would give more reasonable answers overall. Are there
other cases where doing it that way would yield nonintuitive results,
but the current code works?
Thomas, do you know why the datetime+timespan addition code works like
this? For that matter, is the internal representation of a timespan
going to continue to be months + seconds, or is that changing anyway?
regards, tom lane
From bouncefilter Sun Jan 2 18:55:30 2000
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA56254
for <pgsql-hackers@postgresql.org>; Sun, 2 Jan 2000 18:55:28 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <ZW4G6XD1>; Mon, 3 Jan 2000 01:52:26 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C3B8@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgresql.org>
Subject: CVS problems
Date: Mon, 3 Jan 2000 01:48:12 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Hi, all
Why do I get an authorisation failure when I try to update? If I cvs login,
and then enter the password, that goes off fine. Then when I try to cvs
update, it fails with a no such user error. Any ideas?
RH Linux 6.0 (ix86)
cvs 1.10.5
MikeA
From bouncefilter Sun Jan 2 19:37:32 2000
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA68096
for <pgsql-hackers@postgreSQL.org>; Sun, 2 Jan 2000 19:37:14 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <ZW4G6XDG>; Mon, 3 Jan 2000 02:34:15 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C3B9@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "''pgsql-hackers@postgresql.org' '" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] CVS problems
Date: Mon, 3 Jan 2000 02:17:42 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"
OK, seems cvs needed upgrading. Got to 1.10.7 and everything seemed to work
fine. Sorry to trouble everybody...
-----Original Message-----
From: Ansley, Michael
To: 'pgsql-hackers@postgresql.org'
Sent: 1/3/00 1:48 AM
Subject: [HACKERS] CVS problems
Hi, all
Why do I get an authorisation failure when I try to update? If I cvs
login,
and then enter the password, that goes off fine. Then when I try to cvs
update, it fails with a no such user error. Any ideas?
RH Linux 6.0 (ix86)
cvs 1.10.5
MikeA
************
From bouncefilter Sun Jan 2 19:37:31 2000
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA68095
for <pgsql-hackers@postgresql.org>; Sun, 2 Jan 2000 19:37:11 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <ZW4G6XDH>; Mon, 3 Jan 2000 02:34:15 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C3BA@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgresql.org>
Subject: Docs
Date: Mon, 3 Jan 2000 02:20:43 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Another question... how do people normally edit the docs? Is there an sgml
editor that I can use, or should I do it in some other format, and have it
converted, or what?
MikeA
From bouncefilter Sun Jan 2 19:52:31 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id TAA69565
for <pgsql-hackers@postgreSQL.org>; Sun, 2 Jan 2000 19:51:45 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 4369 invoked by uid 1001); 3 Jan 2000 00:51:48 -0000
Message-ID: <XFMail.000102195148.vev@michvhf.com>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <1BF7C7482189D211B03F00805F8527F748C3BA@S-NATH-EXCH2>
Date: Sun, 02 Jan 2000 19:51:48 -0500 (EST)
X-Face: *<Qp5V!eyV,gni`N^N%1YX'$I&uuX]ay;
oq#ZL5Hn8EQsu'.oK0j9$#JM0V?!=Q^[i.81u9
@~=ZjeI}gHY`?2_1,xy/,Gde>0^4Iw)<k8}vg!%l;
&]@PF0LjU)N*m*2"R^UO+PAQ<w}/y)5UVE==w
H$q0*b`HN{+Ekeo?5V(0$MH&NZA3~vOThJxhY(7M:"`CrqO9[VC!^W&&eih!MTq4qk=Vg'd&`{dpgp
3-nck}7do'o/|<RI,
igc#cg8t|PZUEh{Rrx4<~tm`/G8E*wE{G:x}bva@[+YVT`g(u]*^!`1iO*
Sender: vev@paprika.michvhf.com
From: Vince Vielhaber <vev@michvhf.com>
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>
Subject: RE: [HACKERS] Docs
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgreSQL.org>
On 03-Jan-00 Ansley, Michael wrote:
Another question... how do people normally edit the docs? Is there an sgml
editor that I can use, or should I do it in some other format, and have it
converted, or what?
I use xemacs.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
From bouncefilter Sun Jan 2 19:55:31 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA69893
for <pgsql-hackers@postgreSQL.org>; Sun, 2 Jan 2000 19:55:27 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA10181;
Sun, 2 Jan 2000 19:52:22 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001030052.TAA10181@candle.pha.pa.us>
Subject: Re: [HACKERS] Docs
In-Reply-To: <1BF7C7482189D211B03F00805F8527F748C3BA@S-NATH-EXCH2> from
"Ansley, Michael" at "Jan 3, 2000 02:20:43 am"
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>
Date: Sun, 2 Jan 2000 19:52:22 -0500 (EST)
CC: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Another question... how do people normally edit the docs? Is there an sgml
editor that I can use, or should I do it in some other format, and have it
converted, or what?
They just use a standard text editor.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 3 01:28:36 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA33120
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 01:28:16 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA07137
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 01:28:12 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: Hmm, almost-a-Y2K-bug in abstime regression test
Date: Mon, 03 Jan 2000 01:28:11 -0500
Message-ID: <7134.946880891@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
It's not exactly a Y2K bug, because it started to fail at Dec 30 1999
23:00:00, your local time. Nonetheless, the abstime regression test
is now showing a "failure". It's not a code bug --- it's that the test
includes a query whose results depend on whether current time is before
or after 12-30-1999. Boo hiss.
Probably the best answer is to leave the test script alone and change
the expected output. Thomas, do you have a different opinion?
regards, tom lane
From bouncefilter Mon Jan 3 02:06:35 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA42390
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 02:05:39 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id CAA07202;
Mon, 3 Jan 2000 02:05:21 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Source code format vote
In-reply-to: <38704AF9.2B378D37@alumni.caltech.edu>
References: <199912301709.MAA13119@candle.pha.pa.us>
<38704AF9.2B378D37@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Mon, 03 Jan 2000 07:08:41 +0000"
Date: Mon, 03 Jan 2000 02:05:20 -0500
Message-ID: <7199.946883120@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
Was "spaces instead of tabs" one of the voted-on options? That would
make the tab issue moot, and would result in consistant appearance not
matter what tab setting one is using.
Quite a good thought, actually. It'd be worth checking to see if there
is any material expansion in the source's disk footprint and/or the
size of a compressed tarball after getting rid of tabs entirely.
I'd be willing to vote for this if the space penalty is not large...
regards, tom lane
From bouncefilter Mon Jan 3 02:00:35 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA39228
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 02:00:25 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id HAA28863;
Mon, 3 Jan 2000 07:08:41 GMT
Sender: lockhart@hub.org
Message-ID: <38704AF9.2B378D37@alumni.caltech.edu>
Date: Mon, 03 Jan 2000 07:08:41 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Source code format vote
References: <199912301709.MAA13119@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
OK, change tab to 8 spaces, keep indent at 4 spaces, and keep open
bracked on a separate line. Got it.
Just a couple of comments:
istm that an 8-5 vote should not be interpreted as a "consensus", at
least not until you get those 5 to agree that the proposed change is
acceptable.
Was "spaces instead of tabs" one of the voted-on options? That would
make the tab issue moot, and would result in consistant appearance not
matter what tab setting one is using.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Jan 3 02:17:36 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA43687;
Mon, 3 Jan 2000 02:17:33 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id HAA28896;
Mon, 3 Jan 2000 07:26:13 GMT
Sender: lockhart@hub.org
Message-ID: <38704F15.5C24FC0C@alumni.caltech.edu>
Date: Mon, 03 Jan 2000 07:26:13 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Lamar Owen <lamar.owen@wgcr.org>
CC: pgsql-ports@postgresql.org, pgsql-hackers@postgresql.org
Subject: Re: [PORTS] RPMS on PostgreSQL.org updated.
References: <386BC9B4.38C0B5C3@wgcr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Latest release: postgresql-6.5.3-3 and 6.5.3-3nl.
Please read /pub/bindist/RPM/README and README.rpm for more
information.
So should I blow away all of the other RPM directories on the FTP
site??
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Jan 3 02:33:37 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA48503
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 02:33:11 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id HAA28930;
Mon, 3 Jan 2000 07:41:49 GMT
Sender: lockhart@hub.org
Message-ID: <387052BD.C9B673D5@alumni.caltech.edu>
Date: Mon, 03 Jan 2000 07:41:49 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: Is DATEDEBUG useful
References: <200001020153.UAA05000@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I have removed the DATEDEBUG code. I can easily re-add it. Is there
any use to keeping the code? The code looks clearer without it.
?? Only useful when debugging date/time code ;)
Leave it out; the code seems to be pretty stable and shouldn't break
much when doing the "date/time reunification" sometime soon.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Jan 3 02:38:36 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA48987
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 02:37:58 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id HAA28939;
Mon, 3 Jan 2000 07:46:29 GMT
Sender: lockhart@hub.org
Message-ID: <387053D5.C95014F8@alumni.caltech.edu>
Date: Mon, 03 Jan 2000 07:46:29 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>
CC: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Docs
References: <1BF7C7482189D211B03F00805F8527F748C3BA@S-NATH-EXCH2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Another question... how do people normally edit the docs? Is there an sgml
editor that I can use, or should I do it in some other format, and have it
converted, or what?
As Vince mentioned, xemacs is the first choice. Though I think I used
vi for a bunch of the original editing...
Check the appendix on "Documentation" for some hints on editing.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Jan 3 02:57:36 2000
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA50968
for <pgsql-hackers@postgresql.org>; Mon, 3 Jan 2000 02:56:38 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.56]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Mon, 3 Jan 2000 01:47:36 -0600
Sender: ed
Message-ID: <38705679.2118A73D@austin.rr.com>
Date: Mon, 03 Jan 2000 01:57:45 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: "Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Docs
References: <1BF7C7482189D211B03F00805F8527F748C3BA@S-NATH-EXCH2>
<387053D5.C95014F8@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas Lockhart wrote:
Another question... how do people normally edit the docs? Is there an sgml
editor that I can use, or should I do it in some other format, and have it
converted, or what?As Vince mentioned, xemacs is the first choice.
Now, don't go startin' no feud here... if you need a space shuttle, xemacs is
it. But if you need the One True Editor, well, of course...it's vi/vim. :)
From bouncefilter Mon Jan 3 03:12:37 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA59170
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 03:11:55 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id IAA29074;
Mon, 3 Jan 2000 08:20:29 GMT
Sender: lockhart@hub.org
Message-ID: <38705BCB.7B0B9BDD@alumni.caltech.edu>
Date: Mon, 03 Jan 2000 08:20:27 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Ed Loehr <eloehr@austin.rr.com>
CC: "Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Docs
References: <1BF7C7482189D211B03F00805F8527F748C3BA@S-NATH-EXCH2>
<387053D5.C95014F8@alumni.caltech.edu>
<38705679.2118A73D@austin.rr.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Another question... how do people normally edit the docs? Is there an sgml
editor that I can use, or should I do it in some other format, and have it
converted, or what?As Vince mentioned, xemacs is the first choice.
Now, don't go startin' no feud here... if you need a space shuttle, xemacs is
it. But if you need the One True Editor, well, of course...it's vi/vim. :)
Michael wasn't asking for a space shuttle, but he *was* asking for "an
sgml editor", which implied to me an editor with some knowledge of
sgml notation. afaik The AntiEditor is the only freeware tool to do
this...
btw, xemacs is preferred over emacs since the xemacs "version 6"
implementation of DTD parsing can handle the DocBook DTD, whereas the
newer emacs "version 7" implementation barfs with some internal array
error when reading our docs after parsing the DTD. These are recent
results from my Mandrake/RedHat-6.1 Linux distro.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Jan 3 03:33:36 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA63888
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 03:32:56 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id IAA00187;
Mon, 3 Jan 2000 08:38:18 GMT
Sender: lockhart@hub.org
Message-ID: <38705FF9.A3C25187@alumni.caltech.edu>
Date: Mon, 03 Jan 2000 08:38:17 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Hmm, almost-a-Y2K-bug in abstime regression test
References: <7134.946880891@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
It's not exactly a Y2K bug, because it started to fail at Dec 30 1999
23:00:00, your local time. Nonetheless, the abstime regression test
is now showing a "failure". It's not a code bug --- it's that the test
includes a query whose results depend on whether current time is before
or after 12-30-1999. Boo hiss.
Ah, those short-sighted coders back in 1986 didn't even think about
Y2K coming along.
Probably the best answer is to leave the test script alone and change
the expected output. Thomas, do you have a different opinion?
Hmm. That's probably the right thing to do, but it just propagates the
poor form of expecting the system clock on a test machine to always be
set to something after the time the regression test was written. I
might reformulate the queries to reduce the dependency on current
time, assuming that we don't lose some of the testing space while
doing it...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Jan 3 07:23:39 2000
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id HAA03750
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 07:23:02 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <ZW4G6X1T>; Mon, 3 Jan 2000 14:20:06 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C3BB@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Docs
Date: Mon, 3 Jan 2000 14:14:52 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Thanks, everybody, I think I have enough info now to start documenting the
changes that I've made so far.
MikeA
-----Original Message-----
From: Thomas Lockhart [mailto:lockhart@alumni.caltech.edu]
Sent: Monday, January 03, 2000 10:20 AM
To: Ed Loehr
Cc: Ansley, Michael; 'pgsql-hackers@postgresql.org'
Subject: Re: [HACKERS] DocsAnother question... how do people normally edit the
docs? Is there an sgml
editor that I can use, or should I do it in some other
format, and have it
converted, or what?
As Vince mentioned, xemacs is the first choice.
Now, don't go startin' no feud here... if you need a space
shuttle, xemacs is
it. But if you need the One True Editor, well, of
course...it's vi/vim. :)
Michael wasn't asking for a space shuttle, but he *was*
asking for "an
sgml editor", which implied to me an editor with some knowledge of
sgml notation. afaik The AntiEditor is the only freeware tool to do
this...btw, xemacs is preferred over emacs since the xemacs "version 6"
implementation of DTD parsing can handle the DocBook DTD, whereas the
newer emacs "version 7" implementation barfs with some internal array
error when reading our docs after parsing the DTD. These are recent
results from my Mandrake/RedHat-6.1 Linux distro.- Thomas
--
Thomas Lockhart
lockhart@alumni.caltech.edu
South Pasadena, California************
From bouncefilter Mon Jan 3 08:17:40 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA14143
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 08:17:07 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
IAA07153;
Mon, 3 Jan 2000 08:16:51 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001031316.IAA07153@candle.pha.pa.us>
Subject: date/time type changes
To: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Date: Mon, 3 Jan 2000 08:16:51 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Thomas, are you planning on unifying the date/time types for 7.0?
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 3 10:22:41 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA38705
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 10:21:49 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA08203;
Mon, 3 Jan 2000 10:21:46 -0500 (EST)
To: wieck@debis.com (Jan Wieck)
cc: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
Subject: Re: [HACKERS] scanner/parser for FOREIGN KEY
In-reply-to: <m1257Sv-0003kGC@orion.SAPserv.Hamburg.dsh.de>
References: <m1257Sv-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Comments: In-reply-to wieck@debis.com (Jan Wieck)
message dated "Mon, 03 Jan 0100 14:24:05 +0100"
Date: Mon, 03 Jan 2000 10:21:46 -0500
Message-ID: <8200.946912906@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
wieck@debis.com (Jan Wieck) writes:
we still need the enhancement of the scanner/parser combo to
enable FOREIGN KEY specification as column constraint (the
due to shift/reduce disabled NOT DEFERRABLE part).
IMHO this must be done before going into BETA. As discussed,
a little token lookup/queueing between lex and yacc can do
the trick. I'd like to add a slightly generic method for it,
so the lookahead function can be reused if we sometimes get
trapped again with a similar problem.
Do we have a consensus to implement it that way now?
AFAIR that was the only concrete solution offered. I think Thomas
wanted to look into whether he could tweak the grammar to avoid the
problem without lookahead, but he hasn't produced any results ---
and I misdoubt that a fix done that way will be any cleaner than
inserting a lexer lookahead interface.
In short, it's fine by me but I dunno if Thomas has signed on yet.
regards, tom lane
From bouncefilter Mon Jan 3 10:43:41 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA45451
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 10:42:50 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
KAA12077;
Mon, 3 Jan 2000 10:42:09 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001031542.KAA12077@candle.pha.pa.us>
Subject: Re: date/time type changes
In-Reply-To: <3870C416.916A326F@alumni.caltech.edu> from Thomas Lockhart at
"Jan 3, 2000 03:45:26 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Mon, 3 Jan 2000 10:42:09 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Thomas, are you planning on unifying the date/time types for 7.0?
Yes I would like to. But I'll leave it to others to suggest whether it
is essential for a major rev bump or could wait until 7.1. afaik it
should only take a few days, even at my recent snail's pace of
Postgres development :(
It is up to you. It would be best to get it in 7.0, but 7.1 is OK too.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 3 10:37:41 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA44470
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 10:36:49 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA01203;
Mon, 3 Jan 2000 15:45:26 GMT
Sender: lockhart@hub.org
Message-ID: <3870C416.916A326F@alumni.caltech.edu>
Date: Mon, 03 Jan 2000 15:45:26 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: date/time type changes
References: <200001031316.IAA07153@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas, are you planning on unifying the date/time types for 7.0?
Yes I would like to. But I'll leave it to others to suggest whether it
is essential for a major rev bump or could wait until 7.1. afaik it
should only take a few days, even at my recent snail's pace of
Postgres development :(
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Jan 3 10:42:42 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA45385
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 10:42:36 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA01233;
Mon, 3 Jan 2000 15:51:12 GMT
Sender: lockhart@hub.org
Message-ID: <3870C570.8FBB134D@alumni.caltech.edu>
Date: Mon, 03 Jan 2000 15:51:12 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Jan Wieck <wieck@debis.com>,
PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] scanner/parser for FOREIGN KEY
References: <m1257Sv-0003kGC@orion.SAPserv.Hamburg.dsh.de>
<8200.946912906@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
AFAIR that was the only concrete solution offered. I think Thomas
wanted to look into whether he could tweak the grammar to avoid the
problem without lookahead, but he hasn't produced any results ---
and I misdoubt that a fix done that way will be any cleaner than
inserting a lexer lookahead interface.
In short, it's fine by me but I dunno if Thomas has signed on yet.
I glanced at it, but have not had a chance to dive in. There had been
so many changes to the parser code while I was off playing with outer
join syntax that I decided to start over (lots of what I had done
needed to be cleaned up anyway).
I hope to get back to development within a few days, but in the
meantime my parser is re-broken and I haven't yet fixed Jan's parts. I
hate to be holding up Jan, but otoh I hate to see us having to use a
new techique for parsing if the usual ones can be made to work...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Jan 3 11:07:41 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA52055
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 11:07:16 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA13365;
Mon, 3 Jan 2000 11:04:28 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001031604.LAA13365@candle.pha.pa.us>
Subject: Re: [HACKERS] scanner/parser for FOREIGN KEY
In-Reply-To: <3870C570.8FBB134D@alumni.caltech.edu> from Thomas Lockhart at
"Jan 3, 2000 03:51:12 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Mon, 3 Jan 2000 11:04:28 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, Jan Wieck <wieck@debis.com>,
PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
AFAIR that was the only concrete solution offered. I think Thomas
wanted to look into whether he could tweak the grammar to avoid the
problem without lookahead, but he hasn't produced any results ---
and I misdoubt that a fix done that way will be any cleaner than
inserting a lexer lookahead interface.
In short, it's fine by me but I dunno if Thomas has signed on yet.I glanced at it, but have not had a chance to dive in. There had been
so many changes to the parser code while I was off playing with outer
join syntax that I decided to start over (lots of what I had done
needed to be cleaned up anyway).I hope to get back to development within a few days, but in the
meantime my parser is re-broken and I haven't yet fixed Jan's parts. I
hate to be holding up Jan, but otoh I hate to see us having to use a
new techique for parsing if the usual ones can be made to work...
Agreed. Maybe Thomas and I can get on the phone and hammer out a fix.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 3 11:52:44 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA61425;
Mon, 3 Jan 2000 11:51:52 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id LAA03034;
Mon, 3 Jan 2000 11:51:45 -0500
Message-ID: <3870D39A.5EA24B6A@wgcr.org>
Date: Mon, 03 Jan 2000 11:51:39 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: pgsql-ports@postgresql.org, pgsql-hackers@postgresql.org
Subject: Re: [PORTS] RPMS on PostgreSQL.org updated.
References: <386BC9B4.38C0B5C3@wgcr.org>
<38704F15.5C24FC0C@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas Lockhart wrote:
Latest release: postgresql-6.5.3-3 and 6.5.3-3nl.
Please read /pub/bindist/RPM/README and README.rpm for more
information.So should I blow away all of the other RPM directories on the FTP
site??
You can, if you wish. Jeff gave me the bindist/RPM directory, and
symlinked the RPMS and SRPMS tree of yours into the bindist/RPM/RPMS and
bindist/RPM/SRPMS directories, respectively. The links on the download
and news pages will have to be changed when you do so -- which is why I
suggested to Jeff that he symlink, so that links wouldn't be broken.
Future download links for the RPMs should point to bindist/RPM, IMO.
I have already found some other annoyances with the RPMs -- on upgrading
the server subpackage, a chkconfig --del is performed -- but a
corresponding chkconfig --add is not performed, thus removing postgresql
from being autostarted. I think a change in the behavior to leave well
enough alone if upgrading, and do the chkconfig --del only if this is an
uninstall would be appropriate. I got bit with this on my production
server -- not fun.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Mon Jan 3 13:19:43 2000
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA85802
for <pgsql-hackers@postgresql.org>; Mon, 3 Jan 2000 13:19:18 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.56]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Mon, 3 Jan 2000 12:10:06 -0600
Sender: ed
Message-ID: <3870E85E.685D1E0C@austin.rr.com>
Date: Mon, 03 Jan 2000 12:20:14 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: "Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Docs
References: <1BF7C7482189D211B03F00805F8527F748C3BA@S-NATH-EXCH2>
<387053D5.C95014F8@alumni.caltech.edu>
<38705679.2118A73D@austin.rr.com>
<38705BCB.7B0B9BDD@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas Lockhart wrote:
Another question... how do people normally edit the docs? Is there an sgml
editor that I can use, or should I do it in some other format, and have it
converted, or what?As Vince mentioned, xemacs is the first choice.
Now, don't go startin' no feud here... if you need a space shuttle, xemacs is
it. But if you need the One True Editor, well, of course...it's vi/vim. :)Michael wasn't asking for a space shuttle, but he *was* asking for "an
sgml editor", which implied to me an editor with some knowledge of
sgml notation. afaik The AntiEditor is the only freeware tool to do
this...
Vim understands sgml notation to the extent of syntax highlighting.
http://relay.nuxi.com/vim/lang.html
I don't know what xemacs does for sgml.
It appears my attempt at a little late night humor was lost. Please pardon any
offense; it was unintended.
Cheers,
Ed Loehr
From bouncefilter Mon Jan 3 13:35:43 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id NAA90560
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 13:35:31 -0500 (EST)
(envelope-from wieck@debis.com)
Received: from debis.com by orion.SAPserv.Hamburg.dsh.de with smtp
for <pgsql-hackers@postgreSQL.org>
id m125CAE-0003kGC; Mon, 3 Jan 100 19:25 MET
Sender: wieck
Message-ID: <3870E982.B123DF8A@debis.com>
Date: Mon, 03 Jan 2000 19:25:06 +0100
From: Jan Wieck <wieck@debis.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.9 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Index toasting (was: Re: [HACKERS] Error "vacuum pg_proc")
References: <199912270336.WAA28667@candle.pha.pa.us>
<25243.946268065@sss.pgh.pa.us> <25283.946268363@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
I wrote:
And that'll still crash and burn for multicolumn indexes.
Not to mention functional indexes, which typically store values that
don't appear in the referenced tuple at all.Basically, indexes have to have their own toasters. There's no other
way.
You're right.
I think it's best to delay index toasting until we have some
experience with normal, main tuple attribute toasting. It'd be
nice if the solution had covered huge values to be indexed
automatically (what it doesn't any more). But I think most
people can live with a database, that cannot index huge
values, but is capable to store and retrieve them for now.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Mon Jan 3 14:38:48 2000
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA02975
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 14:38:05 -0500 (EST)
(envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA19297;
Mon, 3 Jan 2000 20:23:35 +0100
Date: Mon, 3 Jan 2000 20:23:35 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: P.Marchesso@videotron.ca
cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: replicator
Message-ID: <Pine.LNX.3.96.1000103194931.19115A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi,
I look at your (Philippe's) replicator, but I don't good understand
your replication concept.
node1: SQL --IPC--> node-broker
|
TCP/IP
|
master-node --IPC--> replikator
| | |
libpq
| | |
node2 node..n
(Is it right picture?)
If I good understand, all nodes make connection to master node and data
replicate "replicator" on this master node. But it (master node) is very
critical space in this concept - If master node not work replication for
*all* nodes is lost. Hmm.. but I want use replication for high available
applications...
IMHO is problem with node registration / authentification on master node.
Why concept is not more upright? As:
SQL --IPC--> node-replicator
| | |
via libpq send data to all nodes with
current client/backend auth.
(not exist any master node, all nodes have connection to all nodes)
Use replicator as external proces and copy data from SQL to this replicator
via IPC is (your) very good idea.
Karel
----------------------------------------------------------------------
Karel Zak <zakkr@zf.jcu.cz> http://home.zf.jcu.cz/~zakkr/
Docs: http://docs.linux.cz (big docs archive)
Kim Project: http://home.zf.jcu.cz/~zakkr/kim/ (process manager)
FTP: ftp://ftp2.zf.jcu.cz/users/zakkr/ (C/ncurses/PgSQL)
-----------------------------------------------------------------------
From bouncefilter Mon Jan 3 14:34:44 2000
Received: from onestone.elsinore.klever.net (root@onestone.elsinore.klever.net
[207.175.129.2]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA02580
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 14:34:09 -0500 (EST)
(envelope-from sbirch@ironmountainsystems.com)
Received: from ironmountainsystems.com (ppp88.kross.klever.net
[209.203.65.88]) by onestone.elsinore.klever.net (8.8.7/8.8.0)
with ESMTP id MAA16906; Mon, 3 Jan 2000 12:30:32 -0800
Sender: sbirch@onestone.elsinore.klever.net
Message-ID: <3870F94D.94708599@ironmountainsystems.com>
Date: Mon, 03 Jan 2000 11:32:29 -0800
From: Stephen Birch <sbirch@ironmountainsystems.com>
Organization: Iron Mountain Systems, Inc.
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: date/time type changes
References: <200001031316.IAA07153@candle.pha.pa.us>
<3870C416.916A326F@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Could you outline the proposed changes? I am currently using datetime
and want to make sure my code doesn't break.
Steve
Thomas Lockhart wrote:
Thomas, are you planning on unifying the date/time types for 7.0?
Yes I would like to. But I'll leave it to others to suggest whether it
is essential for a major rev bump or could wait until 7.1. afaik it
should only take a few days, even at my recent snail's pace of
Postgres development :(- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California************
From bouncefilter Mon Jan 3 16:01:45 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA21653
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 16:01:32 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id QAA28725
for pgsql-hackers@postgreSQL.org; Mon, 3 Jan 2000 16:01:24 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001032101.QAA28725@candle.pha.pa.us>
Subject: Inprise/Borland releasing Interbase as Open source
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Mon, 3 Jan 2000 16:01:24 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
FYI:
SCOTTS VALLEY, Calif., Jan. 3 /PRNewswire/ -- Inprise Corporation
(Nasdaq: INPR) today announced that it is jumping to the forefront of
the Linux database market by open-sourcing the beta version of
InterBase 6, the new version of its SQL database. InterBase will be
released in open-source form for multiple platforms, including Linux,
Windows NT, and Solaris.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 3 16:16:45 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA23624
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 16:16:31 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id QAA03555;
Mon, 3 Jan 2000 16:14:34 -0500
Message-ID: <3871112E.42BA38D@wgcr.org>
Date: Mon, 03 Jan 2000 16:14:22 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
References: <200001032101.QAA28725@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
InterBase 6, the new version of its SQL database. InterBase will be
released in open-source form for multiple platforms, including Linux,
I wonder just how 'open' it will be, license-wise.....
Nice thing about PostgreSQL -- it doesn't get any more open than the BSD
license.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Mon Jan 3 17:37:46 2000
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA56208
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 17:37:06 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <ZW4G6XG9>; Tue, 4 Jan 2000 00:34:09 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C3BE@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Bruce Momjian '" <pgman@candle.pha.pa.us>, "'PostgreSQL-development '"
<pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Inprise/Borland releasing Interbase as Open source
Date: Tue, 4 Jan 2000 00:26:26 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"
Great. Rumour has it there is some HOT transaction code in there, among
other things.
MikeA
-----Original Message-----
From: Bruce Momjian
To: PostgreSQL-development
Sent: 00/01/03 11:01
Subject: [HACKERS] Inprise/Borland releasing Interbase as Open source
FYI:
SCOTTS VALLEY, Calif., Jan. 3 /PRNewswire/ -- Inprise Corporation
(Nasdaq: INPR) today announced that it is jumping to the forefront of
the Linux database market by open-sourcing the beta version of
InterBase 6, the new version of its SQL database. InterBase will be
released in open-source form for multiple platforms, including Linux,
Windows NT, and Solaris.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania
19026************
From bouncefilter Mon Jan 3 17:52:46 2000
Received: from hu.tm.ee (isdn-54.uninet.ee [194.204.0.118])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA57628
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 17:52:28 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id BF8F0B71E; Tue, 4 Jan 2000 00:56:46 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <3871292E.D96CA6E5@tm.ee>
Date: Tue, 04 Jan 2000 00:56:46 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
References: <200001032101.QAA28725@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
FYI:
SCOTTS VALLEY, Calif., Jan. 3 /PRNewswire/ -- Inprise Corporation
(Nasdaq: INPR) today announced that it is jumping to the forefront of
the Linux database market by open-sourcing the beta version of
InterBase 6, the new version of its SQL database. InterBase will be
released in open-source form for multiple platforms, including Linux,
Windows NT, and Solaris.
Seems we are starting to get some serious competition ;)
AFAIK, they cover more or less the same features (except domains which
we don't have)
BTW, it also says:
The source code for InterBase 6 is scheduled to be published during
the first part of the year 2000.
Chould this "part" be 1/2, 1/3, 1/4, 1/12 (or 1/1) ?
------------
Hannu
From bouncefilter Mon Jan 3 17:56:46 2000
Received: from hu.tm.ee (isdn-54.uninet.ee [194.204.0.118])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA57983
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 17:56:31 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id EC8B6B71F; Tue, 4 Jan 2000 01:00:50 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38712A22.6C9F711B@tm.ee>
Date: Tue, 04 Jan 2000 01:00:50 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Source code format vote
References: <199912301709.MAA13119@candle.pha.pa.us>
<38704AF9.2B378D37@alumni.caltech.edu>
<7199.946883120@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
Was "spaces instead of tabs" one of the voted-on options? That would
make the tab issue moot, and would result in consistant appearance not
matter what tab setting one is using.Quite a good thought, actually. It'd be worth checking to see if there
is any material expansion in the source's disk footprint and/or the
size of a compressed tarball after getting rid of tabs entirely.
I'd be willing to vote for this if the space penalty is not large...
Me too!
And, there already is an utility to entab/detab in tools section, so people
can use it if they absolutely must have tabs in their source.
AFAIK most decent editors also can [en/de]tab the source they are editing.
So my vote would be 4-space indents, no tabs
--------------
Hannu
From bouncefilter Mon Jan 3 18:21:47 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id SAA63674
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 18:21:36 -0500 (EST)
(envelope-from wieck@debis.com)
Received: from debis.com by orion.SAPserv.Hamburg.dsh.de with smtp
for <pgsql-hackers@postgreSQL.org>
id m125Gd1-0003kGC; Tue, 4 Jan 100 00:11 MET
Sender: wieck
Message-ID: <38712E5E.54087D87@debis.com>
Date: Tue, 04 Jan 2000 00:18:54 +0100
From: Jan Wieck <wieck@debis.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Hannu Krosing <hannu@tm.ee>
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Source code format vote
References: <199912301709.MAA13119@candle.pha.pa.us>
<38704AF9.2B378D37@alumni.caltech.edu>
<7199.946883120@sss.pgh.pa.us> <38712A22.6C9F711B@tm.ee>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hannu Krosing wrote:
Tom Lane wrote:
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
Was "spaces instead of tabs" one of the voted-on options? That would
make the tab issue moot, and would result in consistant appearance not
matter what tab setting one is using.I'd be willing to vote for this if the space penalty is not large...
Me too!
Count me in.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Mon Jan 3 19:00:47 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA86168
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 18:59:49 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
SAA05813;
Mon, 3 Jan 2000 18:59:02 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001032359.SAA05813@candle.pha.pa.us>
Subject: Re: [HACKERS] Source code format vote
In-Reply-To: <38712E5E.54087D87@debis.com> from Jan Wieck at "Jan 4,
2000 00:18:54 am"
To: Jan Wieck <wieck@debis.com>
Date: Mon, 3 Jan 2000 18:59:02 -0500 (EST)
CC: Hannu Krosing <hannu@tm.ee>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hannu Krosing wrote:
Tom Lane wrote:
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
Was "spaces instead of tabs" one of the voted-on options? That would
make the tab issue moot, and would result in consistant appearance not
matter what tab setting one is using.I'd be willing to vote for this if the space penalty is not large...
Me too!
Count me in.
Do I need to tabluate a vote on this too?
I have to get all new votes from everyone on:
8-space tabs
no tabs
Indentaion is still 4-spaces.
I prefer the 8-space tabs to no tabs. Seems like 8-space tabs won over
4-space tabs, so we need a vote on 8-space tabs vs. no tabs.
I will need new votes because I have not kept any of the old messages.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 3 19:15:48 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id TAA91059
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 19:15:14 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 7203 invoked by uid 1001); 4 Jan 2000 00:15:18 -0000
Message-ID: <XFMail.000103191518.vev@michvhf.com>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <200001032359.SAA05813@candle.pha.pa.us>
Date: Mon, 03 Jan 2000 19:15:18 -0500 (EST)
X-Face: *<Qp5V!eyV,gni`N^N%1YX'$I&uuX]ay;
oq#ZL5Hn8EQsu'.oK0j9$#JM0V?!=Q^[i.81u9
@~=ZjeI}gHY`?2_1,xy/,Gde>0^4Iw)<k8}vg!%l;
&]@PF0LjU)N*m*2"R^UO+PAQ<w}/y)5UVE==w
H$q0*b`HN{+Ekeo?5V(0$MH&NZA3~vOThJxhY(7M:"`CrqO9[VC!^W&&eih!MTq4qk=Vg'd&`{dpgp
3-nck}7do'o/|<RI,
igc#cg8t|PZUEh{Rrx4<~tm`/G8E*wE{G:x}bva@[+YVT`g(u]*^!`1iO*
Sender: vev@paprika.michvhf.com
From: Vince Vielhaber <vev@michvhf.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Subject: Re: [HACKERS] Source code format vote
Cc: Hannu Krosing <hannu@tm.ee>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
Jan Wieck <wieck@debis.com>
On 03-Jan-00 Bruce Momjian wrote:
Hannu Krosing wrote:
Tom Lane wrote:
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
Was "spaces instead of tabs" one of the voted-on options? That would
make the tab issue moot, and would result in consistant appearance not
matter what tab setting one is using.I'd be willing to vote for this if the space penalty is not large...
Me too!
Count me in.
Do I need to tabluate a vote on this too?
I have to get all new votes from everyone on:
8-space tabs
no tabsIndentaion is still 4-spaces.
I prefer the 8-space tabs to no tabs. Seems like 8-space tabs won over
4-space tabs, so we need a vote on 8-space tabs vs. no tabs.I will need new votes because I have not kept any of the old messages.
Ok, this is probably a really dumb question and probably even been answered
before but I missed it. Why not make a tab be a tab and however it appears
in the end programmer's editor can be up to the programmer? Or is pgindent
changing tabs to spaces?
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
From bouncefilter Mon Jan 3 19:22:47 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA91688
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 19:22:08 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id UAA64474;
Mon, 3 Jan 2000 20:21:01 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 3 Jan 2000 20:21:01 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Jan Wieck <wieck@debis.com>, Hannu Krosing <hannu@tm.ee>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Source code format vote
In-Reply-To: <200001032359.SAA05813@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001032020490.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I'm for no-tabs personally ...
On Mon, 3 Jan 2000, Bruce Momjian wrote:
Hannu Krosing wrote:
Tom Lane wrote:
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
Was "spaces instead of tabs" one of the voted-on options? That would
make the tab issue moot, and would result in consistant appearance not
matter what tab setting one is using.I'd be willing to vote for this if the space penalty is not large...
Me too!
Count me in.
Do I need to tabluate a vote on this too?
I have to get all new votes from everyone on:
8-space tabs
no tabsIndentaion is still 4-spaces.
I prefer the 8-space tabs to no tabs. Seems like 8-space tabs won over
4-space tabs, so we need a vote on 8-space tabs vs. no tabs.I will need new votes because I have not kept any of the old messages.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026************
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Jan 3 16:59:45 2000
Received: from mx01.gis.net ([208.218.130.25])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA45635
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 16:59:24 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from laptop.pacifier.com (nas-45-236.boston.navinet.net
[216.67.45.236]) by mx01.gis.net (8.8.8/8.8.8+pyrd) with SMTP
id QAA07618; Mon, 3 Jan 2000 16:58:21 -0500 (EST)
Message-Id: <3.0.1.32.20000103165142.00edd988@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 03 Jan 2000 16:51:42 -0800
To: Jan Wieck <wieck@debis.com>, Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: Index toasting (was: Re: [HACKERS] Error "vacuum pg_proc")
Cc: Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
In-Reply-To: <3870E982.B123DF8A@debis.com>
References: <199912270336.WAA28667@candle.pha.pa.us>
<25243.946268065@sss.pgh.pa.us> <25283.946268363@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 07:25 PM 1/3/00 +0100, Jan Wieck wrote:
I think it's best to delay index toasting until we have some
experience with normal, main tuple attribute toasting. It'd be
nice if the solution had covered huge values to be indexed
automatically (what it doesn't any more). But I think most
people can live with a database, that cannot index huge
values, but is capable to store and retrieve them for now.
From my personal POV, I would certainly agree with this. The stuff
I'm working on is probably pretty typical, using an integer key to
identify rows which contain large chunks of text, photographs, etc.
I'm perfectly happy not being able to index the big chunks, and
suspect a large percentage of users would feel the same.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Mon Jan 3 20:20:48 2000
Received: from falla.videotron.net (falla.videotron.net [205.151.222.106])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA03199
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 20:20:27 -0500 (EST)
(envelope-from P.Marchesso@Videotron.ca)
Received: from Videotron.ca ([207.253.206.49])
by falla.videotron.net (Sun Internet Mail Server
sims.3.5.1999.12.14.10.29.p8)
with ESMTP id <0FNS00A6AEDZGJ@falla.videotron.net> for
pgsql-hackers@postgreSQL.org; Mon, 3 Jan 2000 20:20:25 -0500 (EST)
Date: Mon, 03 Jan 2000 20:22:55 -0500
From: Philippe Marchesseault <P.Marchesso@Videotron.ca>
Subject: Re: [HACKERS] replicator
To: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
Cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Message-id: <38714B6F.2DECAEC0@Videotron.ca>
MIME-version: 1.0
X-Mailer: Mozilla 4.61 [en] (Win95; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <Pine.LNX.3.96.1000103194931.19115A-100000@ara.zf.jcu.cz>
Hi Karel!
Karel Wrote:
node1: SQL --IPC--> node-broker
|
TCP/IP
|
master-node --IPC--> replikator
| | |
libpq
| | |
node2 node..n(Is it right picture?)
Yes, you got the concept right. I admit it's a bit complicated. Your comments
made me go back to the drawing board and I found several flaws with the design.
The first one is that this design does not allow us to use Transaction Blocks.
An example might go a long way:
Node 1, Client1 (1,1) Issues a begin statement ---> Node 2 Client 1 (2,1) (the
replicator process) sends this command.
(1, 1) Sends a INSERT statement. ---> (2,1) Sends the INSERT to the backend.
Node 2 Client 2 (2,2) Checks (SELECT) the data and the INSERT of 1,1 is not
there. That's normal, it was not commited.
Node 1, Client 2 (1,2) Issues a BEGIN statement. ---> (2,1) Receives a warning,
about the state not being in progress.
(1,2) Does some stuff...
(1, 2) issues a Rollback Statement ---> (2,1) Sends the rollback. Node 2 rolls
back all the transactions made since 1,1 sent the BEGIN.
(1, 1) Sends the final Commit , It fails on the remote nodes because it was
rolled back.
So the problem is that we have more than two connections on a single link. It
could be fixed by sending the statements in a block only when we do a COMMIT.
But then we might have some performance problems with big blocks of inserts.
Also I am worried about UPDATES that could be done between separate COMMITs
thus putting the database out of sync. :-(
IMHO is problem with node registration / authentification on master node.
Why concept is not more upright? As:SQL --IPC--> node-replicator
| | |
via libpq send data to all nodes with
current client/backend auth.
Yes, the concept can be more simple but The above would create some performance
problems. If you had many nodes, it would take a long time to send the last
statement. You would have to wait until the statement was completly processed
by all the nodes. A better solution IMHO would be to have a bit more padding
between the node-replicator and the backend.
So it could become:
SQL --IPC--> node-replicator
| | |
via TCP send statements to each node
replicator (on local node)
|
via libpq send data to
current (local) backend.
(not exist any master node, all nodes have connection to all nodes)
Exactly, if the replicator dies only the node dies, everything else keeps
working.
Looking foward to hearing from you,
Philippe Marchesseault
PS: Please excuse me for the DIFF, it's the first time I'm contributing to an
OSS project.
From bouncefilter Mon Jan 3 20:27:48 2000
Received: from onestone.elsinore.klever.net (root@onestone.elsinore.klever.net
[207.175.129.2]) by hub.org (8.9.3/8.9.3) with ESMTP id UAA03796
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 20:26:48 -0500 (EST)
(envelope-from sbirch@ironmountainsystems.com)
Received: from ironmountainsystems.com (ppp22.kross.klever.net
[209.203.65.22]) by onestone.elsinore.klever.net (8.8.7/8.8.0)
with ESMTP id SAA16237; Mon, 3 Jan 2000 18:23:26 -0800
Sender: sbirch@onestone.elsinore.klever.net
Message-ID: <38714C01.81E26277@ironmountainsystems.com>
Date: Mon, 03 Jan 2000 17:25:21 -0800
From: Stephen Birch <sbirch@ironmountainsystems.com>
Organization: Iron Mountain Systems, Inc.
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
References: <200001032101.QAA28725@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I wish this announcement had been made a few months ago!! We have several
developers porting our server software to PostgreSQL. Although we like
PostgreSQL, we have run into a number of memory leaks and bugs - something
we never encountered with Interbase.
Now Interbase is going open source, we will discontinue the PostgreSQL
development effort. Interbase is such a well written DBMS, it doesn't make
sense to continue.
You guys have done a great job - but, frankly, IB is better.
Steve
Bruce Momjian wrote:
FYI:
SCOTTS VALLEY, Calif., Jan. 3 /PRNewswire/ -- Inprise Corporation
(Nasdaq: INPR) today announced that it is jumping to the forefront of
the Linux database market by open-sourcing the beta version of
InterBase 6, the new version of its SQL database. InterBase will be
released in open-source form for multiple platforms, including Linux,
Windows NT, and Solaris.-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026************
From bouncefilter Mon Jan 3 21:21:49 2000
Received: from druid.net (druid.net [216.126.72.98])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA15157
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 21:21:18 -0500 (EST)
(envelope-from darcy@druid.net)
Received: from localhost (1830 bytes) by druid.net
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
(sender: <darcy>) (ident <darcy> using unix)
id <m125JYd-000AUUC@druid.net>
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 21:18:47 -0500 (EST)
(Smail-3.2.0.109 1999-Oct-27 #1 built 1999-Dec-25)
Message-Id: <m125JYd-000AUUC@druid.net>
From: darcy@druid.net (D'Arcy J.M. Cain)
Subject: Re: [HACKERS] Source code format vote
In-Reply-To: <200001032359.SAA05813@candle.pha.pa.us> from Bruce Momjian at
"Jan 3, 2000 06:59:02 pm"
To: pgman@candle.pha.pa.us (Bruce Momjian)
Date: Mon, 3 Jan 2000 21:18:47 -0500 (EST)
Cc: wieck@debis.com (Jan Wieck), hannu@tm.ee (Hannu Krosing),
lockhart@alumni.caltech.edu (Thomas Lockhart),
pgsql-hackers@postgreSQL.org (PostgreSQL-development)
Reply-To: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Thus spake Bruce Momjian
I have to get all new votes from everyone on:
8-space tabs
no tabsIndentaion is still 4-spaces.
I prefer the 8-space tabs to no tabs. Seems like 8-space tabs won over
4-space tabs, so we need a vote on 8-space tabs vs. no tabs.
Seems like multiple votes. First vote is whether to use spaces or tabs
for indenting. Then, how many characters should we indent if we use
tabs and if we don't. Note that people may have different opinions
on how much to indent for each of these. I suspect a number of people
choose 8 space tabs because it is standard and consistent on different
methods of output, not because they particularly like that much
indentation. I know that I have lately been considering going to 3
space, no tab indenting in my own code so that it looks right whether
I use the editor, cat to the screen or print it.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.From bouncefilter Mon Jan 3 21:24:49 2000
Received: from druid.net (druid.net [216.126.72.98])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA15388
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 21:24:06 -0500 (EST)
(envelope-from darcy@druid.net)
Received: from localhost (1672 bytes) by druid.net
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
(sender: <darcy>) (ident <darcy> using unix)
id <m125JcS-000AUUC@druid.net>
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 21:22:44 -0500 (EST)
(Smail-3.2.0.109 1999-Oct-27 #1 built 1999-Dec-25)
Message-Id: <m125JcS-000AUUC@druid.net>
From: darcy@druid.net (D'Arcy J.M. Cain)
Subject: Re: [HACKERS] Source code format vote
In-Reply-To: <XFMail.000103191518.vev@michvhf.com> from Vince Vielhaber at
"Jan 3, 2000 07:15:18 pm"
To: vev@michvhf.com (Vince Vielhaber)
Date: Mon, 3 Jan 2000 21:22:44 -0500 (EST)
Cc: pgman@candle.pha.pa.us (Bruce Momjian), hannu@tm.ee (Hannu Krosing),
lockhart@alumni.caltech.edu (Thomas Lockhart),
pgsql-hackers@postgreSQL.org (PostgreSQL-development),
wieck@debis.com (Jan Wieck)
Reply-To: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Thus spake Vince Vielhaber
Ok, this is probably a really dumb question and probably even been answered
before but I missed it. Why not make a tab be a tab and however it appears
in the end programmer's editor can be up to the programmer? Or is pgindent
changing tabs to spaces?
Not a dumb question at all. However, think about comments. Look at
this example.
i++; /* This variable is being incremented. I am commenting *
* this because it is such a stupid variable name
*/
Under my editor that comment lines up nicely but it will look cockeyed
for many people reading this because I used tabs instead of spaces and
my tabs are 4, not the usual 8.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.From bouncefilter Mon Jan 3 21:35:48 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA20011
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 21:35:31 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id WAA65226;
Mon, 3 Jan 2000 22:35:49 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 3 Jan 2000 22:35:49 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, Jan Wieck <wieck@debis.com>,
Hannu Krosing <hannu@tm.ee>, Thomas Lockhart <lockhart@alumni.caltech.edu>
Subject: Re: [HACKERS] Source code format vote
In-Reply-To: <m125JYd-000AUUC@druid.net>
Message-ID: <Pine.BSF.4.21.0001032235290.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 3 Jan 2000, D'Arcy J.M. Cain wrote:
Thus spake Bruce Momjian
I have to get all new votes from everyone on:
8-space tabs
no tabsIndentaion is still 4-spaces.
I prefer the 8-space tabs to no tabs. Seems like 8-space tabs won over
4-space tabs, so we need a vote on 8-space tabs vs. no tabs.Seems like multiple votes. First vote is whether to use spaces or tabs
for indenting. Then, how many characters should we indent if we use
tabs and if we don't. Note that people may have different opinions
on how much to indent for each of these. I suspect a number of people
choose 8 space tabs because it is standard and consistent on different
methods of output, not because they particularly like that much
indentation. I know that I have lately been considering going to 3
space, no tab indenting in my own code so that it looks right whether
I use the editor, cat to the screen or print it.
I tend to prefer 2 spaces to using tabs myself ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Jan 3 21:40:49 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA20536
for <pgsql-hackers@postgreSQL.org>; Mon, 3 Jan 2000 21:40:01 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id WAA65256;
Mon, 3 Jan 2000 22:39:42 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 3 Jan 2000 22:39:41 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Stephen Birch <sbirch@ironmountainsystems.com>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
In-Reply-To: <38714C01.81E26277@ironmountainsystems.com>
Message-ID: <Pine.BSF.4.21.0001032236140.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 3 Jan 2000, Stephen Birch wrote:
I wish this announcement had been made a few months ago!! We have
several developers porting our server software to PostgreSQL.
Although we like PostgreSQL, we have run into a number of memory leaks
and bugs - something we never encountered with Interbase.
What version of PostgreSQL? Did the problem reports you sent in not
improve the situation?
Now Interbase is going open source, we will discontinue the PostgreSQL
development effort. Interbase is such a well written DBMS, it doesn't
make sense to continue.
Two points...when will Interbase go open source? Right now they've
announced the intention to do so, and even given a very brood time
frame...but, when is it going to happen. two...what says Interbase will
continue to be "as good" when becomes open source and they are no longer
making any money on it?
You guys have done a great job - but, frankly, IB is better.
In what ways?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Tue Jan 4 00:11:50 2000
Received: from druid.net (druid.net [216.126.72.98])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA51449
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 00:11:21 -0500 (EST)
(envelope-from darcy@druid.net)
Received: from localhost (940 bytes) by druid.net
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
(sender: <darcy>) (ident <darcy> using unix)
id <m125MEp-000AUUC@druid.net>
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 00:10:31 -0500 (EST)
(Smail-3.2.0.109 1999-Oct-27 #1 built 1999-Dec-25)
Message-Id: <m125MEp-000AUUC@druid.net>
From: darcy@druid.net (D'Arcy J.M. Cain)
Subject: Re: [HACKERS] Source code format vote
In-Reply-To: <Pine.BSF.4.21.0001032235290.18498-100000@thelab.hub.org> from
The Hermit Hacker at "Jan 3, 2000 10:35:49 pm"
To: scrappy@hub.org (The Hermit Hacker)
Date: Tue, 4 Jan 2000 00:10:30 -0500 (EST)
Cc: pgsql-hackers@postgreSQL.org
Reply-To: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Thus spake The Hermit Hacker
I tend to prefer 2 spaces to using tabs myself ...
Two seems a little too small to me although I have been considering
three for some time.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.From bouncefilter Tue Jan 4 00:30:50 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA56599
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 00:30:47 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA28201;
Tue, 4 Jan 2000 00:23:48 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001040523.AAA28201@candle.pha.pa.us>
Subject: Re: [HACKERS] Source code format vote
In-Reply-To: <m125MEp-000AUUC@druid.net> from "D'Arcy J.M. Cain" at "Jan 4,
2000 00:10:30 am"
To: pgsql-hackers@postgreSQL.org
Date: Tue, 4 Jan 2000 00:23:48 -0500 (EST)
CC: The Hermit Hacker <scrappy@hub.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Thus spake The Hermit Hacker
I tend to prefer 2 spaces to using tabs myself ...
Two seems a little too small to me although I have been considering
three for some time.
Four is a nice 1/2 multiple of 8, the standard tab size.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 4 02:15:53 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA74881
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 02:15:40 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id HAA02616;
Tue, 4 Jan 2000 07:24:15 GMT
Sender: lockhart@hub.org
Message-ID: <3871A01E.F7B047E7@alumni.caltech.edu>
Date: Tue, 04 Jan 2000 07:24:15 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Birch <sbirch@ironmountainsystems.com>
CC: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: date/time type changes
References: <200001031316.IAA07153@candle.pha.pa.us>
<3870C416.916A326F@alumni.caltech.edu>
<3870F94D.94708599@ironmountainsystems.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Could you outline the proposed changes? I am currently using datetime
and want to make sure my code doesn't break.Thomas, are you planning on unifying the date/time types for 7.0?
The datetime type will become "timestamp" and the timespan type will
become "interval". Both "datetime" and "timespan" will become aliases
for timestamp and interval, respectively, and code *should* work
without having to be changed.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Tue Jan 4 02:19:52 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA75165
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 02:18:52 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id HAA02624;
Tue, 4 Jan 2000 07:27:25 GMT
Sender: lockhart@hub.org
Message-ID: <3871A0DD.9C27797D@alumni.caltech.edu>
Date: Tue, 04 Jan 2000 07:27:25 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Ed Loehr <eloehr@austin.rr.com>
CC: "Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Docs
References: <1BF7C7482189D211B03F00805F8527F748C3BA@S-NATH-EXCH2>
<387053D5.C95014F8@alumni.caltech.edu>
<38705679.2118A73D@austin.rr.com>
<38705BCB.7B0B9BDD@alumni.caltech.edu>
<3870E85E.685D1E0C@austin.rr.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Vim understands sgml notation to the extent of syntax highlighting.
http://relay.nuxi.com/vim/lang.html
It appears my attempt at a little late night humor was lost. Please
pardon any offense; it was unintended.
Ah, we once again have proven to be a humorless lot ;)
Thanks for the tip regarding vim...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Tue Jan 4 09:45:57 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA79380
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 09:45:37 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id IAA02838;
Tue, 4 Jan 2000 08:11:33 GMT
Sender: lockhart@hub.org
Message-ID: <3871AB34.5ACE74C7@alumni.caltech.edu>
Date: Tue, 04 Jan 2000 08:11:32 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>, ohp@pyrenet.fr,
Tulassay Zsolt <zsolt@tek.bke.hu>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [BUGS] Date calc bug
References: <Pine.UW2.4.21.0001021513050.11391-100000@server.pyrenet.fr>
<21517.946836120@sss.pgh.pa.us>
Content-Type: multipart/mixed; boundary="------------0D67EBB5BB25DC2D84AE64E5"
This is a multi-part message in MIME format.
--------------0D67EBB5BB25DC2D84AE64E5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
forum=> select datetime(now())+'74565 days'::timespan as ido;
Thu Jan 19 14:07:30 2068
and
select '12-01-1999'::datetime + '@ 1 month - 1 sec' ;
Thu Dec 30 23:59:59 1999 EST
I've repaired both problems in both the development and release trees.
Thanks for the reports and analysis. Patch enclosed...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
--------------0D67EBB5BB25DC2D84AE64E5
Content-Type: text/plain; charset=us-ascii;
name="dt.c.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="dt.c.patch"
*** ../src/backend/utils/adt/dt.c.orig Mon Jan 3 08:27:24 2000
--- ../src/backend/utils/adt/dt.c Mon Jan 3 16:41:08 2000
***************
*** 787,792 ****
--- 787,793 ----
* To add a month, increment the month, and use the same day of month.
* Then, if the next month has fewer days, set the day of month
* to the last day of month.
+ * Lastly, add in the "quantitative time".
*/
DateTime *
datetime_pl_span(DateTime *datetime, TimeSpan *span)
***************
*** 815,826 ****
{
dt = (DATETIME_IS_RELATIVE(*datetime) ? SetDateTime(*datetime) : *datetime);- #ifdef ROUND_ALL
- dt = JROUND(dt + span->time);
- #else
- dt += span->time;
- #endif
-
if (span->month != 0)
{
struct tm tt,
--- 816,821 ----
***************
*** 853,858 ****
--- 848,859 ----
DATETIME_INVALID(dt);
}+ #ifdef ROUND_ALL
+ dt = JROUND(dt + span->time);
+ #else
+ dt += span->time;
+ #endif
+
*result = dt;
}***************
*** 2441,2447 ****
tm2timespan(struct tm * tm, double fsec, TimeSpan *span)
{
span->month = ((tm->tm_year * 12) + tm->tm_mon);
! span->time = ((((((tm->tm_mday * 24) + tm->tm_hour) * 60) + tm->tm_min) * 60) + tm->tm_sec);
span->time = JROUND(span->time + fsec);
return 0;
--- 2442,2451 ----
tm2timespan(struct tm * tm, double fsec, TimeSpan *span)
{
span->month = ((tm->tm_year * 12) + tm->tm_mon);
! span->time = ((((((tm->tm_mday * 24.0)
! + tm->tm_hour) * 60.0)
! + tm->tm_min) * 60.0)
! + tm->tm_sec);
span->time = JROUND(span->time + fsec);return 0;
--------------0D67EBB5BB25DC2D84AE64E5--
From bouncefilter Tue Jan 4 03:30:52 2000
Received: from paladincorp.com.au (paladincorp.com.au [203.101.1.142])
by hub.org (8.9.3/8.9.3) with SMTP id DAA91836
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 03:30:07 -0500 (EST)
(envelope-from winspace@paladincorp.com.au)
Received: (qmail 8484 invoked from network); 4 Jan 2000 08:30:00 -0000
Received: from wagner.paladincorp.com.au (192.168.0.6)
by beethoven.paladincorp.com.au with SMTP; 4 Jan 2000 08:30:00 -0000
Date: Tue, 4 Jan 2000 19:29:57 +1100 (EST)
From: Norman Widders <winspace@paladincorp.com.au>
To: Stephen Birch <sbirch@ironmountainsystems.com>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
In-Reply-To: <38714C01.81E26277@ironmountainsystems.com>
Message-ID:
<Pine.BSF.4.21.0001041924390.9658-100000@wagner.paladincorp.com.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 3 Jan 2000, Stephen Birch wrote:
You guys have done a great job - but, frankly, IB is better.
Steve
wtf ? what sort of lame remark/incentive is that ? gimme a break being
amongst the multitudes who use pg dayin/dayout i hate tirekickers that say
rubbish like 'such and such is better' or 'if you do such and such' having
been down this path many times over the years myself, the last thing the
engineers working on pg need is to hear those sort of negative comments.
just my $0.02c knowing how hard everyone works on pg and it is superb!
/Torqumada
Norman Widders - Paladin Corporation Pty Ltd. ACN: 081-191-611
The lyf so short, the craft so long to lerne - Chaucer
NIC: NW83-AU OpenBSD, FreeBSD, Solaris, SCO, Debian
Software Engineering: c/c++/perl/sql/eiffel/pascal/haskell
Ph: +612 9835-4782 Fax: +612 9864-0487 Mobile: 0416-207-857
Powered by Symetric Multiple Processors running on FreeBSD 3.4/SMP
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (FreeBSD)
Comment: Made with pgp4pine
iEYEARECAAYFAjhxr4oACgkQfpbFlIYNi7dHxwCcCYDevE7ev1VE5XS0cAz5L266
VtwAoIfdLqeqEw2JEVZXW4tyPnp3rsLn
=BzpQ
-----END PGP SIGNATURE-----
From bouncefilter Tue Jan 4 03:37:52 2000
Received: from hu.tm.ee (isdn-54.uninet.ee [194.204.0.118])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA95540
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 03:37:29 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 93282B786; Tue, 4 Jan 2000 10:41:49 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <3871B24D.301711E5@tm.ee>
Date: Tue, 04 Jan 2000 10:41:49 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Birch <sbirch@ironmountainsystems.com>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
References: <200001032101.QAA28725@candle.pha.pa.us>
<38714C01.81E26277@ironmountainsystems.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Stephen Birch wrote:
I wish this announcement had been made a few months ago!! We have several
developers porting our server software to PostgreSQL. Although we like
PostgreSQL, we have run into a number of memory leaks and bugs - something
we never encountered with Interbase.Now Interbase is going open source, we will discontinue the PostgreSQL
development effort. Interbase is such a well written DBMS, it doesn't make
sense to continue.
The announcement said that IB version 6 _beta_ is going to be open source,
without specifying what kind of license it will have.
It could very well be something like SCL (i.e. you can have the source, but
what you can do with it is quite limited). If you just need a
beer-kind-of-free
database, you may be better off with using Sybase or IB v.4
I suspect that the move to open-source it is at least partly an effort to
fix "a number of memory leaks and bugs" ;)
------------
Hannu
From bouncefilter Tue Jan 4 04:11:53 2000
Received: from kzsu.stanford.edu (KZSU.Stanford.EDU [36.118.0.90])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA01815
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 04:11:39 -0500 (EST)
(envelope-from doom@kzsu.stanford.edu)
Received: from kzsu.stanford.edu (localhost [127.0.0.1])
by kzsu.stanford.edu (8.9.3/8.9.3) with ESMTP id BAA04113
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 01:11:09 -0800 (PST)
(envelope-from doom@kzsu.stanford.edu)
Message-Id: <200001040911.BAA04113@kzsu.stanford.edu>
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
In-Reply-To: Your message of "Mon, 03 Jan 2000 17:25:21 PST."
<38714C01.81E26277@ironmountainsystems.com>
Date: Tue, 04 Jan 2000 01:11:09 -0800
From: Joe Brenner <doom@kzsu.stanford.edu>
Stephen Birch <sbirch@ironmountainsystems.com> wrote:
Now Interbase is going open source, we will discontinue the PostgreSQL
development effort. Interbase is such a well written DBMS, it doesn't make
sense to continue.
You might want to wait to see what they mean by "open
source". They might mean GPL, BSD, MPL or they could be
rolling their own vanity license that'll take months to
debug. They also might go the bogus "open source" route,
ala Sun's "Community Source License".
Open source projects are a tricky business... if they don't
do it right, they won't attract the critical mass of
developers they need to keep the project going (yes, old
code never dies, but it does bitrot away...).
From bouncefilter Tue Jan 4 04:12:53 2000
Received: from flame.flame.co.za (flame.flame.co.za [160.124.170.1])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA01905
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 04:12:04 -0500 (EST)
(envelope-from theo@flame.co.za)
Received: from flame.co.za (flame.flame.co.za [160.124.170.1])
by flame.flame.co.za (8.8.7/8.8.7) with ESMTP id LAA14636
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 11:11:13 +0200
Sender: theo@flame.flame.co.za
Message-ID: <3871B931.242111C8@flame.co.za>
Date: Tue, 04 Jan 2000 11:11:13 +0200
From: Theo Kramer <theo@flame.co.za>
Organization: Flame Computing Enterprises
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.35 i686)
X-Accept-Language: en
MIME-Version: 1.0
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
References: <200001032101.QAA28725@candle.pha.pa.us>
<38714C01.81E26277@ironmountainsystems.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Stephen Birch wrote:
I wish this announcement had been made a few months ago!! We have several
developers porting our server software to PostgreSQL. Although we like
PostgreSQL, we have run into a number of memory leaks and bugs - something
we never encountered with Interbase.Now Interbase is going open source, we will discontinue the PostgreSQL
development effort. Interbase is such a well written DBMS, it doesn't make
sense to continue.You guys have done a great job - but, frankly, IB is better.
Just been porting our app to Oracle. It took me 3 days to install, and an
extreme amount of frustration ie. jre1.1.6 is hardwired in so you have to
have it to install, oci apps core when dynamically linked, column size
(linesize) set to greater than 125 causes a core when describing an
object in sqlplus,...
Will look at IB when it comes around, but right now give me Postgres anyday!
--------
Regards
Theo
From bouncefilter Tue Jan 4 05:25:54 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id FAA18804
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 05:25:39 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 8496 invoked by uid 1001); 4 Jan 2000 10:25:39 -0000
Date: Tue, 4 Jan 2000 05:25:39 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, Hannu Krosing <hannu@tm.ee>,
Thomas Lockhart <lockhart@alumni.caltech.edu>, Jan Wieck <wieck@debis.com>
Subject: Re: [HACKERS] Source code format vote
In-Reply-To: <m125JcS-000AUUC@druid.net>
Message-ID: <Pine.BSF.4.05.10001040525080.8491-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 3 Jan 2000, D'Arcy J.M. Cain wrote:
Thus spake Vince Vielhaber
Ok, this is probably a really dumb question and probably even been answered
before but I missed it. Why not make a tab be a tab and however it appears
in the end programmer's editor can be up to the programmer? Or is pgindent
changing tabs to spaces?Not a dumb question at all. However, think about comments. Look at
this example.i++; /* This variable is being incremented. I am commenting *
* this because it is such a stupid variable name
*/Under my editor that comment lines up nicely but it will look cockeyed
for many people reading this because I used tabs instead of spaces and
my tabs are 4, not the usual 8.
Good point. I'm looking at it in pine right now and it's not too well
lined up.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
From bouncefilter Tue Jan 4 07:28:55 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id HAA47406
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 07:28:31 -0500 (EST)
(envelope-from jwieck@debis.com)
Received: from debis.com by orion.SAPserv.Hamburg.dsh.de with smtp
for <pgsql-hackers@postgreSQL.org>
id m125Suc-0003kGC; Tue, 4 Jan 100 13:18 MET
Sender: wieck
Message-ID: <3871E6CD.2339E583@debis.com>
Date: Tue, 04 Jan 2000 13:25:49 +0100
From: Jan Wieck <jwieck@debis.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
CC: Stephen Birch <sbirch@ironmountainsystems.com>,
Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
References: <Pine.BSF.4.21.0001032236140.18498-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The Hermit Hacker wrote:
On Mon, 3 Jan 2000, Stephen Birch wrote:
I wish this announcement had been made a few months ago!! We have
several developers porting our server software to PostgreSQL.
Although we like PostgreSQL, we have run into a number of memory leaks
and bugs - something we never encountered with Interbase.What version of PostgreSQL? Did the problem reports you sent in not
improve the situation?
I haven't seen that many. And what kind of a project leader must it be,
that a simple announcement causes the work of several programmers over
months (sounds at least like a man-year) to be thrown away? IMHO the
kind of PL, companies like M$ are targeting with their huge amount of
announcements.
Now Interbase is going open source, we will discontinue the PostgreSQL
development effort. Interbase is such a well written DBMS, it doesn't
make sense to continue.Two points...when will Interbase go open source? Right now they've
announced the intention to do so, and even given a very brood time
frame...but, when is it going to happen. two...what says Interbase will
continue to be "as good" when becomes open source and they are no longer
making any money on it?
Since it's the toplevel story on www.borland.com, I think it'll really
happen soon. And I also think they intend to continue making money on
it, just not by selling DB-licenses any more. They have a rich set of
development tools etc. they can sell anyway. And in many projects I've
seen that it's never a bad choice not to mixup too many
hardware/software vendors (they'll all point to each other as soon as
problems arise). So it's a big PRO for their applications and tools, if
you'll get the DB they use for free. And it's your decision to spend
money when going into production to buy commercial support (what I
expect they'll offer).
Another point is this. As long as I know Postgres, a couple of features
had been added just because some user needed it. And they are supported
and kept alive. Do they have some proposal on that? How will they deal
with some feature-patch sent in?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Tue Jan 4 08:20:56 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA61332
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 08:19:59 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id JAA69259;
Tue, 4 Jan 2000 09:18:49 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 4 Jan 2000 09:18:49 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Jan Wieck <jwieck@debis.com>
cc: Stephen Birch <sbirch@ironmountainsystems.com>,
Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
In-Reply-To: <3871E6CD.2339E583@debis.com>
Message-ID: <Pine.BSF.4.21.0001040915250.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I've since gotten an email from Stephen in response to his comments, and I
think that when he wrote his original, he needed his morning cup of coffee
(or equivalent), since it came over alot heavier then what he email'd
me...
A quick summary:
They didn't report the memory leaks...they fixed them and uploaded
patches, which have been accepted and commit'd
A few problems couldn't be reproduced, and, therefore, left
unreported. I wish ppl would report anyway, as someone else might be
coming across this, finding it also non-reproducable and might have some
data to add :(
The only one that is left outstanding right now has to do with:
"However, the biggest problem was reported recently, see "HEAP_MOVED_IN during
vacuum" posted on Saturday, no replies" ...
Anyone have any comments on that last one?
On Tue, 4 Jan 2000, Jan Wieck wrote:
The Hermit Hacker wrote:
On Mon, 3 Jan 2000, Stephen Birch wrote:
I wish this announcement had been made a few months ago!! We have
several developers porting our server software to PostgreSQL.
Although we like PostgreSQL, we have run into a number of memory leaks
and bugs - something we never encountered with Interbase.What version of PostgreSQL? Did the problem reports you sent in not
improve the situation?I haven't seen that many. And what kind of a project leader must it be,
that a simple announcement causes the work of several programmers over
months (sounds at least like a man-year) to be thrown away? IMHO the
kind of PL, companies like M$ are targeting with their huge amount of
announcements.Now Interbase is going open source, we will discontinue the PostgreSQL
development effort. Interbase is such a well written DBMS, it doesn't
make sense to continue.Two points...when will Interbase go open source? Right now they've
announced the intention to do so, and even given a very brood time
frame...but, when is it going to happen. two...what says Interbase will
continue to be "as good" when becomes open source and they are no longer
making any money on it?Since it's the toplevel story on www.borland.com, I think it'll really
happen soon. And I also think they intend to continue making money on
it, just not by selling DB-licenses any more. They have a rich set of
development tools etc. they can sell anyway. And in many projects I've
seen that it's never a bad choice not to mixup too many
hardware/software vendors (they'll all point to each other as soon as
problems arise). So it's a big PRO for their applications and tools, if
you'll get the DB they use for free. And it's your decision to spend
money when going into production to buy commercial support (what I
expect they'll offer).Another point is this. As long as I know Postgres, a couple of features
had been added just because some user needed it. And they are supported
and kept alive. Do they have some proposal on that? How will they deal
with some feature-patch sent in?Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Tue Jan 4 09:25:56 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA74182
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 09:25:55 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id KAA69582;
Tue, 4 Jan 2000 10:25:09 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 4 Jan 2000 10:25:09 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Don Baccus <dhogaza@pacifier.com>
cc: Stephen Birch <sbirch@ironmountainsystems.com>,
Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
In-Reply-To: <3.0.1.32.20000104091903.00ed5ddc@mail.pacifier.com>
Message-ID: <Pine.BSF.4.21.0001041024401.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 4 Jan 2000, Don Baccus wrote:
At 10:39 PM 1/3/00 -0400, The Hermit Hacker wrote:
On Mon, 3 Jan 2000, Stephen Birch wrote:
(HH):
Two points...when will Interbase go open source? Right now they've
announced the intention to do so, and even given a very brood time
frame...but, when is it going to happen. two...what says Interbase will
continue to be "as good" when becomes open source and they are no longer
making any money on it?They say they'll continue to sell it via their traditional channels
and sell support, too. So it's not really clear what open-source
means in this context. Open-source doesn't have to mean the disappearance
of license fees...You guys have done a great job - but, frankly, IB is better.
In what ways?
Outer joins, for one.
currently being worked on by Thomas, schedualed for, I believe, v7.1 this
summer ...
Next? :)
From bouncefilter Tue Jan 4 10:29:57 2000
Received: from bologna.nettuno.it (bologna.nettuno.it [193.43.2.1])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA89852
for <pgsql-hackers@postgresql.org>; Tue, 4 Jan 2000 10:29:31 -0500 (EST)
(envelope-from jose@sferacarta.com)
Received: from proxy.sferacarta.com (sfcabop1.nettuno.it [193.207.10.213])
by bologna.nettuno.it (8.9.3/8.9.3/NETTuno 4.1) with ESMTP id QAA01504;
Tue, 4 Jan 2000 16:27:08 +0100 (MET)
Received: from rosso.sferacarta.com (sferacarta.com) [10.20.30.5]
by proxy.sferacarta.com with esmtp (Exim 2.05 #1 (Debian))
id 125WmL-0007Ss-00; Tue, 4 Jan 2000 16:25:50 +0000
Message-ID: <387211C5.B7BA949B@sferacarta.com>
Date: Tue, 04 Jan 2000 16:29:09 +0100
From: Jose Soares <jose@sferacarta.com>
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
CC: The Hermit Hacker <scrappy@hub.org>,
Stephen Birch <sbirch@ironmountainsystems.com>,
Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Opensource
References: <38714C01.81E26277@ironmountainsystems.com>
<3.0.1.32.20000104091903.00ed5ddc@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Don Baccus wrote:
At 10:39 PM 1/3/00 -0400, The Hermit Hacker wrote:
On Mon, 3 Jan 2000, Stephen Birch wrote:
(HH):
Two points...when will Interbase go open source? Right now they've
announced the intention to do so, and even given a very brood time
frame...but, when is it going to happen. two...what says Interbase will
continue to be "as good" when becomes open source and they are no longer
making any money on it?They say they'll continue to sell it via their traditional channels
and sell support, too.
They say:
"The source code for InterBase 6 is scheduled to be published during the first
part of the year 2000.
The company also announced it plans to continue to sell and support InterBase
5.6 through normal distribution channels..."
If I understand seems they refer to previous version i.e. InterBase ver. 5.6
but version 6 will be open source, maybe...
So it's not really clear what open-source
means in this context. Open-source doesn't have to mean the disappearance
of license fees...You guys have done a great job - but, frankly, IB is better.
In what ways?
Outer joins, for one.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.************
From bouncefilter Tue Jan 4 10:59:01 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA04174
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 10:58:37 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA13283;
Tue, 4 Jan 2000 10:58:33 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: Stephen Birch <sbirch@ironmountainsystems.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
In-reply-to: <Pine.BSF.4.21.0001040915250.18498-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0001040915250.18498-100000@thelab.hub.org>
Comments: In-reply-to The Hermit Hacker <scrappy@hub.org>
message dated "Tue, 04 Jan 2000 09:18:49 -0400"
Date: Tue, 04 Jan 2000 10:58:33 -0500
Message-ID: <13280.947001513@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
"However, the biggest problem was reported recently, see "HEAP_MOVED_IN
during vacuum" posted on Saturday, no replies" ...
Anyone have any comments on that last one?
I replied to it --- not with any useful ideas I'm afraid, just asking
for more info. But if Stephen is claiming he was ignored, then he's
not reading his email...
regards, tom lane
From bouncefilter Tue Jan 4 11:17:16 2000
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA09763
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 11:16:43 -0500 (EST)
(envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA31673;
Tue, 4 Jan 2000 17:02:06 +0100
Date: Tue, 4 Jan 2000 17:02:06 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Philippe Marchesseault <P.Marchesso@Videotron.ca>
cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] replicator
In-Reply-To: <38714B6F.2DECAEC0@Videotron.ca>
Message-ID: <Pine.LNX.3.96.1000104162226.27234D-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 3 Jan 2000, Philippe Marchesseault wrote:
So it could become:
SQL --IPC--> node-replicator
| | |
via TCP send statements to each node
replicator (on local node)
|
via libpq send data to
current (local) backend.(not exist any master node, all nodes have connection to all nodes)
Exactly, if the replicator dies only the node dies, everything else keeps
working.
Hi,
I a little explore replication conception on Oracle and Sybase (in manuals).
(Know anyone some interesting links or publication about it?)
Firstly, I sure, untimely is write replication to PgSQL now, if we
haven't exactly conception for it. It need more suggestion from more
developers. We need firstly answers for next qestion:
1/ How replication concept choose for PG?
2/ How manage transaction for nodes? (and we need define any
replication protocol for this)
3/ How involve replication in current PG transaction code?
My idea (dream:-) is replication that allow you use full read-write on all
nodes and replication which use current transaction method in PG - not is
difference between more backends on one host or more backend on more hosts
- it makes "global transaction consistency".
Now is transaction manage via ICP (one host), my dream is alike manage
this transaction, but between more host via TCP. (And make optimalization
for this - transfer commited data/commands only.)
Any suggestion?
-------------------
Note:
(transaction oriented replication)
Sybase - I. model (only one node is read-write)
primary SQL data (READ-WRITE)
|
replication agent (transaction log monitoring)
|
primary distribution server (one or more repl. servers)
| / | \
| nodes (READ-ONLY)
|
secondary dist. server
/ | \
nodes (READ-ONLY)
If primary SQL is read-write and the other nodes *read-only*
=> system good work if connection is disable (data are save to
replication-log and if connection is available log is write
to node).
Sybase - II. model (all nodes read-write)
SQL data 1 --->--+ NODE I.
| |
^ |
| replication agent 1 (transaction log monitoring)
V |
| V
| |
replication server 1
|
^
V
|
replication server 2 NODE II.
| |
^ +-<-->--- SQL data 2
| |
replcation agent 2 -<--
Sorry, I not sure if I re-draw previous picture total good..
Karel
From bouncefilter Tue Jan 4 11:24:59 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA11092
for <hackers@postgresql.org>; Tue, 4 Jan 2000 11:24:53 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA06307
for <hackers@postgresql.org>; Tue, 4 Jan 2000 16:33:32 GMT
Sender: lockhart@hub.org
Message-ID: <387220DC.91A41302@alumni.caltech.edu>
Date: Tue, 04 Jan 2000 16:33:32 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgresql.org>
Subject: Regression tests
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I've started going through the regression tests and updating for the
new psql output. The first few tests have been committed, and I'll try
working through the others in the next few days.
I've also updated the test queries to use the extended SQL92 type
coersion syntax rather than the older, non-standard Postgres "::"
notation. I'll still keep some "::" queries somewhere so that the
syntax continues to be tested...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Tue Jan 4 09:26:56 2000
Received: from mx01.gis.net ([208.218.130.25])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA74240
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 09:26:20 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from laptop.pacifier.com (nas-3-54.boston.navinet.net [216.67.3.54])
by mx01.gis.net (8.8.8/8.8.8+pyrd) with SMTP id JAA20654;
Tue, 4 Jan 2000 09:22:48 -0500 (EST)
Message-Id: <3.0.1.32.20000104091903.00ed5ddc@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 04 Jan 2000 09:19:03 -0800
To: The Hermit Hacker <scrappy@hub.org>,
Stephen Birch <sbirch@ironmountainsystems.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open
source
Cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <Pine.BSF.4.21.0001032236140.18498-100000@thelab.hub.org>
References: <38714C01.81E26277@ironmountainsystems.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 10:39 PM 1/3/00 -0400, The Hermit Hacker wrote:
On Mon, 3 Jan 2000, Stephen Birch wrote:
(HH):
Two points...when will Interbase go open source? Right now they've
announced the intention to do so, and even given a very brood time
frame...but, when is it going to happen. two...what says Interbase will
continue to be "as good" when becomes open source and they are no longer
making any money on it?
They say they'll continue to sell it via their traditional channels
and sell support, too. So it's not really clear what open-source
means in this context. Open-source doesn't have to mean the disappearance
of license fees...
You guys have done a great job - but, frankly, IB is better.
In what ways?
Outer joins, for one.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Tue Jan 4 12:43:59 2000
Received: from postal.thewrittenword.com
(IDENT:china@postal.thewrittenword.com [208.150.51.101])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA30342
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 12:43:50 -0500 (EST)
(envelope-from pgsql-hackers@thewrittenword.com)
From: pgsql-hackers@thewrittenword.com
Received: (from china@localhost)
by postal.thewrittenword.com (8.9.3/8.9.3) id LAA18858
for pgsql-hackers@postgreSQL.org; Tue, 4 Jan 2000 11:41:07 -0600 (CST)
Date: Tue, 4 Jan 2000 11:40:44 -0600 (CST)
Message-Id: <200001041741.LAA18858@postal.thewrittenword.com>
X-Authentication-Warning: postal.thewrittenword.com: china set sender to
pgsql-hackers@thewrittenword.com using -f
To: pgsql-hackers@postgreSQL.org
Subject: Error compiling 6.5.3 on Solaris 2.7/x86 with Sun C compiler 5.0
Reply-To: pgsql-hackers@postgreSQL.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mutt-Fcc: =tww/sent
Status: RO
Lines: 19
songoku:/opt/build/postgresql-6.5.3/src/backend/utils/adt% gmake
cc -I../../../include -I../../../backend -I/opt/TWWfsw/tcl81/include
-I/opt/TWWfsw/tk81/include -I/opt/TWWfsw/readline/include -I../..
-c -o date.o date.c
"date.c", line 153: warning: statement not reached
"date.c", line 372: undefined symbol: __const
"date.c", line 372: syntax error before or at: double
cc: acomp failed for date.c
gmake: *** [date.o] Error 2
The Sun C compiler doesn't like the definition of NAN in
src/include/port/solaris_i386.h:
#define NAN (*(__const double *) __nan)
Is there a danger of removing this line? Should it be changed to
something else?
--
albert chin (china@thewrittenword.com)
From bouncefilter Tue Jan 4 13:08:59 2000
Received: from server.pyrenet.fr (server.pyrenet.fr [194.250.190.1])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA36300
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 13:08:29 -0500 (EST)
(envelope-from ohp@pyrenet.fr)
Received: from localhost (localhost [127.0.0.1])
by server.pyrenet.fr (8.8.7/8.8.8) with ESMTP id TAA13636;
Tue, 4 Jan 2000 19:07:39 +0100 (MET)
Date: Tue, 4 Jan 2000 19:07:38 +0100 (MET)
From: Olivier PRENANT <ohp@pyrenet.fr>
Reply-To: ohp@pyrenet.fr
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Tulassay Zsolt <zsolt@tek.bke.hu>,
pgsql-hackers@postgreSQL.org
Subject: Re: [BUGS] Date calc bug
In-Reply-To: <3871AB34.5ACE74C7@alumni.caltech.edu>
Message-ID: <Pine.UW2.4.21.0001041905510.13631-200000@server.pyrenet.fr>
MIME-Version: 1.0
Content-Type: MULTIPART/Mixed; BOUNDARY=------------0D67EBB5BB25DC2D84AE64E5
Content-ID: <Pine.UW2.4.21.0001041905511.13631@server.pyrenet.fr>
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
--------------0D67EBB5BB25DC2D84AE64E5
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.UW2.4.21.0001041905512.13631@server.pyrenet.fr>
Thanks you!!
Patch applied and tested.
Great job.
That's exactly the reason why I love Internet and postresql.
You find a bug.. Send a message and correct it.
Best wishes for 2000.
Regards
On Tue, 4 Jan 2000, Thomas Lockhart wrote:
forum=> select datetime(now())+'74565 days'::timespan as ido;
Thu Jan 19 14:07:30 2068and
select '12-01-1999'::datetime + '@ 1 month - 1 sec' ;
Thu Dec 30 23:59:59 1999 ESTI've repaired both problems in both the development and release trees.
Thanks for the reports and analysis. Patch enclosed...- Thomas
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)
--------------0D67EBB5BB25DC2D84AE64E5
Content-Type: TEXT/PLAIN; CHARSET=us-ascii; NAME="dt.c.patch"
Content-ID: <Pine.UW2.4.21.0001041905513.13631@server.pyrenet.fr>
Content-Description:
Content-Disposition: INLINE; FILENAME="dt.c.patch"
*** ../src/backend/utils/adt/dt.c.orig Mon Jan 3 08:27:24 2000
--- ../src/backend/utils/adt/dt.c Mon Jan 3 16:41:08 2000
***************
*** 787,792 ****
--- 787,793 ----
* To add a month, increment the month, and use the same day of month.
* Then, if the next month has fewer days, set the day of month
* to the last day of month.
+ * Lastly, add in the "quantitative time".
*/
DateTime *
datetime_pl_span(DateTime *datetime, TimeSpan *span)
***************
*** 815,826 ****
{
dt = (DATETIME_IS_RELATIVE(*datetime) ? SetDateTime(*datetime) : *datetime);- #ifdef ROUND_ALL
- dt = JROUND(dt + span->time);
- #else
- dt += span->time;
- #endif
-
if (span->month != 0)
{
struct tm tt,
--- 816,821 ----
***************
*** 853,858 ****
--- 848,859 ----
DATETIME_INVALID(dt);
}+ #ifdef ROUND_ALL
+ dt = JROUND(dt + span->time);
+ #else
+ dt += span->time;
+ #endif
+
*result = dt;
}***************
*** 2441,2447 ****
tm2timespan(struct tm * tm, double fsec, TimeSpan *span)
{
span->month = ((tm->tm_year * 12) + tm->tm_mon);
! span->time = ((((((tm->tm_mday * 24) + tm->tm_hour) * 60) + tm->tm_min) * 60) + tm->tm_sec);
span->time = JROUND(span->time + fsec);
return 0;
--- 2442,2451 ----
tm2timespan(struct tm * tm, double fsec, TimeSpan *span)
{
span->month = ((tm->tm_year * 12) + tm->tm_mon);
! span->time = ((((((tm->tm_mday * 24.0)
! + tm->tm_hour) * 60.0)
! + tm->tm_min) * 60.0)
! + tm->tm_sec);
span->time = JROUND(span->time + fsec);return 0;
--------------0D67EBB5BB25DC2D84AE64E5--
From bouncefilter Tue Jan 4 14:11:00 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id OAA59332
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 14:10:08 -0500 (EST)
(envelope-from wieck@debis.com)
Received: from debis.com by orion.SAPserv.Hamburg.dsh.de with smtp
for <pgsql-hackers@postgreSQL.org>
id m125ZB4-0003kGC; Tue, 4 Jan 100 19:59 MET
Sender: wieck
Message-ID: <387244DF.F0B33D5E@debis.com>
Date: Tue, 04 Jan 2000 20:07:11 +0100
From: Jan Wieck <wieck@debis.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
CC: Jose Soares <jose@sferacarta.com>, The Hermit Hacker <scrappy@hub.org>,
Stephen Birch <sbirch@ironmountainsystems.com>,
Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Opensource
References: <38714C01.81E26277@ironmountainsystems.com>
<3.0.1.32.20000104091903.00ed5ddc@mail.pacifier.com>
<3.0.1.32.20000104122131.00ed42bc@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Don Baccus wrote:
So they'll sell 5.6 but maybe 6 will be free? Strange. Rumor on Slashdot
is that they've lost their key developers (a month or so ago).
If THAT's the case, man, then they try to get back experienced
programmers for development and support for free via the internet. Then
it would take some time until they're able to offer professional
support.
And (in response to Jan), yeah, I know outer joins are scheduled
to be completed in 7.1. Personally, the interbase news leaves me
yawning. Postgres, since 6.5, is meeting my needs just fine.
Was Marc IIRC. Anyway, most of our proposed features appear in time or
with a 25-50% overrun. What's absolutely strong for free+open software.
And moreover, almost every serious bug, that is fixable without
destroying anything else, get's fixed in a couple of days or weeks. The
reason for the latter is, that we have a fistfull of programmes who
work for years now on the code. Some of us since the release from
Berkeley. That are key developers, who know intuitively into what
region of the code to dive if some strange misbehaviour is reported.
So if Inprise really lost them, they have a severe problem.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Tue Jan 4 15:07:02 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA72341
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 15:06:32 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA20503;
Tue, 4 Jan 2000 14:42:19 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001041942.OAA20503@candle.pha.pa.us>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
In-Reply-To: <Pine.BSF.4.21.0001041024401.18498-100000@thelab.hub.org> from
The
Hermit Hacker at "Jan 4, 2000 10:25:09 am"
To: The Hermit Hacker <scrappy@hub.org>
Date: Tue, 4 Jan 2000 14:42:19 -0500 (EST)
CC: Don Baccus <dhogaza@pacifier.com>,
Stephen Birch <sbirch@ironmountainsystems.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
They say they'll continue to sell it via their traditional channels
and sell support, too. So it's not really clear what open-source
means in this context. Open-source doesn't have to mean the disappearance
of license fees...You guys have done a great job - but, frankly, IB is better.
In what ways?
Outer joins, for one.
currently being worked on by Thomas, schedualed for, I believe, v7.1 this
summer ...
I have spoken to him about getting some minimal OUTER join functionality
in 7.0. Let's see what happens.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 4 14:55:01 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA67282
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 14:54:32 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA20919;
Tue, 4 Jan 2000 14:50:04 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001041950.OAA20919@candle.pha.pa.us>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Opensource
In-Reply-To: <387244DF.F0B33D5E@debis.com> from Jan Wieck at "Jan 4,
2000 08:07:11 pm"
To: Jan Wieck <wieck@debis.com>
Date: Tue, 4 Jan 2000 14:50:04 -0500 (EST)
CC: Don Baccus <dhogaza@pacifier.com>, Jose Soares <jose@sferacarta.com>,
The Hermit Hacker <scrappy@hub.org>,
Stephen Birch <sbirch@ironmountainsystems.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Was Marc IIRC. Anyway, most of our proposed features appear in time or
with a 25-50% overrun. What's absolutely strong for free+open software.
And moreover, almost every serious bug, that is fixable without
destroying anything else, get's fixed in a couple of days or weeks. The
reason for the latter is, that we have a fistfull of programmes who
work for years now on the code. Some of us since the release from
Berkeley. That are key developers, who know intuitively into what
region of the code to dive if some strange misbehaviour is reported.So if Inprise really lost them, they have a severe problem.
Another _big_ issue is how clean the code is. MySQL, for example,
probably loses tons of people because their code is so poorly designed,
and just plain ugly to me.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 4 14:54:03 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA67087
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 14:53:28 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA21002;
Tue, 4 Jan 2000 14:52:25 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001041952.OAA21002@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: date/time type changes
In-Reply-To: <3871A01E.F7B047E7@alumni.caltech.edu> from Thomas Lockhart at
"Jan 4, 2000 07:24:15 am"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Tue, 4 Jan 2000 14:52:25 -0500 (EST)
CC: Stephen Birch <sbirch@ironmountainsystems.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Could you outline the proposed changes? I am currently using datetime
and want to make sure my code doesn't break.Thomas, are you planning on unifying the date/time types for 7.0?
The datetime type will become "timestamp" and the timespan type will
become "interval". Both "datetime" and "timespan" will become aliases
for timestamp and interval, respectively, and code *should* work
without having to be changed.
Wouldn't it make more sense to rename timestamp to datetime because
datetime is the ANSI name? Just asking.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 4 14:55:00 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA67274
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 14:54:21 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA21075;
Tue, 4 Jan 2000 14:53:40 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001041953.OAA21075@candle.pha.pa.us>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
In-Reply-To: <1BF7C7482189D211B03F00805F8527F748C3BE@S-NATH-EXCH2> from
"Ansley, Michael" at "Jan 4, 2000 00:26:26 am"
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>
Date: Tue, 4 Jan 2000 14:53:40 -0500 (EST)
CC: "'PostgreSQL-development '" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Great. Rumour has it there is some HOT transaction code in there, among
other things.FYI:
SCOTTS VALLEY, Calif., Jan. 3 /PRNewswire/ -- Inprise Corporation
(Nasdaq: INPR) today announced that it is jumping to the forefront of
the Linux database market by open-sourcing the beta version of
InterBase 6, the new version of its SQL database. InterBase will be
released in open-source form for multiple platforms, including Linux,
Windows NT, and Solaris.
We may find that that HOT transaction code is the same as our
transaction code, which I guess would mean ours is HOT too.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 4 12:17:58 2000
Received: from mx02.gis.net ([208.218.130.7])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA24417
for <pgsql-hackers@postgresql.org>; Tue, 4 Jan 2000 12:17:05 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from laptop.pacifier.com (nas-3-78.boston.navinet.net [216.67.3.78])
by mx02.gis.net (8.8.8/8.8.8+pyrd) with SMTP id MAA29287;
Tue, 4 Jan 2000 12:12:54 -0500 (EST)
Message-Id: <3.0.1.32.20000104122131.00ed42bc@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 04 Jan 2000 12:21:31 -0800
To: Jose Soares <jose@sferacarta.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Opensource
Cc: The Hermit Hacker <scrappy@hub.org>,
Stephen Birch <sbirch@ironmountainsystems.com>,
Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
In-Reply-To: <387211C5.B7BA949B@sferacarta.com>
References: <38714C01.81E26277@ironmountainsystems.com>
<3.0.1.32.20000104091903.00ed5ddc@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 04:29 PM 1/4/00 +0100, Jose Soares wrote:
Don Baccus wrote:
They say they'll continue to sell it via their traditional channels
and sell support, too.They say:
"The source code for InterBase 6 is scheduled to be published during the
first
part of the year 2000.
The company also announced it plans to continue to sell and support InterBase
5.6 through normal distribution channels..."If I understand seems they refer to previous version i.e. InterBase ver. 5.6
but version 6 will be open source, maybe...
So they'll sell 5.6 but maybe 6 will be free? Strange. Rumor on Slashdot
is that they've lost their key developers (a month or so ago).
And (in response to Jan), yeah, I know outer joins are scheduled
to be completed in 7.1. Personally, the interbase news leaves me
yawning. Postgres, since 6.5, is meeting my needs just fine.
BTW, it appears that they have "multi-generational" concurrency
control, which sounds very much like MVCC. Indeed, the white
paper describing it makes it sound as though the basic strategy
for storing tuples with transaction ids (the "generations") is
kinda similar to PostgreSQL. They support dirty reads and some
ways to specify which "generation" to read from. Might be some
ideas there worth looking at for future PostgreSQL work...
Keep in mind that I spent no more than 15 minutes trucking around
their site and docs so I picked up no more than a very, very
surface impression of stuff. (in other words, my quick impressions
may be very innaccurate).
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Tue Jan 4 16:09:01 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA92055
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 16:08:20 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA73433;
Tue, 4 Jan 2000 17:07:41 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 4 Jan 2000 17:07:41 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Don Baccus <dhogaza@pacifier.com>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
"Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'PostgreSQL-development '" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
In-Reply-To: <3.0.1.32.20000104155222.00eded90@mail.pacifier.com>
Message-ID: <Pine.BSF.4.21.0001041707100.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 4 Jan 2000, Don Baccus wrote:
At 02:53 PM 1/4/00 -0500, Bruce Momjian wrote:
Great. Rumour has it there is some HOT transaction code in there, among
other things.We may find that that HOT transaction code is the same as our
transaction code, which I guess would mean ours is HOT too.(redundant, but what the heck)
Their "multi-generational" concurrency control sure sounds just like
MVCC.
I wonder when they implemented theirs? Basically...is their's based on
old technology/concepts, while ours is based on newer ones?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Tue Jan 4 16:38:01 2000
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id QAA98251
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 16:37:08 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <ZW4G6YBH>; Tue, 4 Jan 2000 23:34:08 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C3CB@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Bruce Momjian '" <pgman@candle.pha.pa.us>
Cc: "''PostgreSQL-development ' '" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Inprise/Borland releasing Interbase as Open source
Date: Tue, 4 Jan 2000 23:28:33 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"
Great. Rumour has it there is some HOT transaction code in there,
among
other things.
We may find that that HOT transaction code is the same as our
transaction code, which I guess would mean ours is HOT too.
Yes, that's the point. It gives us a measure of where our code stands in
relation to (previously) commercial code. If it's as good or better than
IBs (assuming that IBs is good in the area of concern), great. If not, we
can look for ideas. Either way, we win!
MikeA
From bouncefilter Tue Jan 4 16:51:03 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA99869
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 16:50:39 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
QAA25414;
Tue, 4 Jan 2000 16:49:21 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001042149.QAA25414@candle.pha.pa.us>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Opensource
In-Reply-To: <3.0.1.32.20000104154931.00ed9658@mail.pacifier.com> from Don
Baccus at "Jan 4, 2000 03:49:31 pm"
To: Don Baccus <dhogaza@pacifier.com>
Date: Tue, 4 Jan 2000 16:49:21 -0500 (EST)
CC: Jan Wieck <wieck@debis.com>, Jose Soares <jose@sferacarta.com>,
The Hermit Hacker <scrappy@hub.org>,
Stephen Birch <sbirch@ironmountainsystems.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
At 02:50 PM 1/4/00 -0500, Bruce Momjian wrote:
Another _big_ issue is how clean the code is. MySQL, for example,
probably loses tons of people because their code is so poorly designed,
and just plain ugly to me.I'll have to say that the Postgres code's quite easy to follow, at
least at the "grasp-the-big-picture" level at which I've been reading
it on a casual, off-and-on basis. Understanding it well enough to
contribute - well, that's another issue 'cause by its nature it is
a fairly complex beast!
Totally true. Education is very important, and clean coding helps with
that.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 4 16:52:02 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA99997
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 16:51:08 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
QAA25430;
Tue, 4 Jan 2000 16:50:37 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001042150.QAA25430@candle.pha.pa.us>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
In-Reply-To: <3.0.1.32.20000104155222.00eded90@mail.pacifier.com> from Don
Baccus at "Jan 4, 2000 03:52:22 pm"
To: Don Baccus <dhogaza@pacifier.com>
Date: Tue, 4 Jan 2000 16:50:37 -0500 (EST)
CC: "Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'PostgreSQL-development '" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
At 02:53 PM 1/4/00 -0500, Bruce Momjian wrote:
Great. Rumour has it there is some HOT transaction code in there, among
other things.We may find that that HOT transaction code is the same as our
transaction code, which I guess would mean ours is HOT too.(redundant, but what the heck)
Their "multi-generational" concurrency control sure sounds just like
MVCC.
Reminds me of the guy who said our MVCC was a leader in database
technology. He did not realize is was only one person, Vadim, who did
the whole thing.
Amazing when just one of our developers makes the commercial db's look
like they are standing still.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 4 17:24:03 2000
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA09563
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 17:23:09 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <ZW4G6YBT>; Wed, 5 Jan 2000 00:20:11 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C3CC@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Bruce Momjian '" <pgman@candle.pha.pa.us>, "'Don Baccus '"
<dhogaza@pacifier.com>
Cc: "''PostgreSQL-development ' '" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Inprise/Borland releasing Interbase as Open source
Date: Wed, 5 Jan 2000 00:16:02 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"
Makes you wonder what people (companies) are spending their money on. My
take on it is that commercial software licensing is, by and large, a hoax.
MikeA
-----Original Message-----
From: Bruce Momjian
To: Don Baccus
Cc: Ansley, Michael; 'PostgreSQL-development '
Sent: 00/01/04 11:50
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
At 02:53 PM 1/4/00 -0500, Bruce Momjian wrote:
Great. Rumour has it there is some HOT transaction code in there,
among
other things.
We may find that that HOT transaction code is the same as our
transaction code, which I guess would mean ours is HOT too.(redundant, but what the heck)
Their "multi-generational" concurrency control sure sounds just like
MVCC.
Reminds me of the guy who said our MVCC was a leader in database
technology. He did not realize is was only one person, Vadim, who did
the whole thing.
Amazing when just one of our developers makes the commercial db's look
like they are standing still.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania
19026From bouncefilter Tue Jan 4 17:49:02 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id RAA16065
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 17:48:38 -0500 (EST)
(envelope-from wieck@debis.com)
Received: from debis.com by orion.SAPserv.Hamburg.dsh.de with smtp
for <pgsql-hackers@postgreSQL.org>
id m125ca5-0003kGC; Tue, 4 Jan 100 23:37 MET
Sender: wieck
Message-ID: <387277F8.64CEDE35@debis.com>
Date: Tue, 04 Jan 2000 23:45:13 +0100
From: Jan Wieck <wieck@debis.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
CC: Don Baccus <dhogaza@pacifier.com>, Bruce Momjian <pgman@candle.pha.pa.us>,
"Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'PostgreSQL-development '" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
References: <Pine.BSF.4.21.0001041707100.18498-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The Hermit Hacker wrote:
I wonder when they implemented theirs? Basically...is their's based on
old technology/concepts, while ours is based on newer ones?
Maybe it's based on the same technology. If the've used a similar (HOT)
transactional concept for tuples, based legally on the PG technique
released under the BSD license years ago, they might have come to the
same conclusion. That'd mean - well - OLD concepts like ours.
Truth remains truth.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Tue Jan 4 17:55:04 2000
Received: from onestone.elsinore.klever.net (root@onestone.elsinore.klever.net
[207.175.129.2]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA16969
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 17:54:36 -0500 (EST)
(envelope-from sbirch@ironmountainsystems.com)
Received: from ironmountainsystems.com ([209.234.201.22]) by
onestone.elsinore.klever.net (8.8.7/8.8.0) with ESMTP id
PAA07341; Tue, 4 Jan 2000 15:51:09 -0800
Sender: sbirch@onestone.elsinore.klever.net
Message-ID: <387279D2.E40315DC@ironmountainsystems.com>
Date: Tue, 04 Jan 2000 14:53:06 -0800
From: Stephen Birch <sbirch@ironmountainsystems.com>
Organization: Iron Mountain Systems, Inc.
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jan Wieck <jwieck@debis.com>
CC: The Hermit Hacker <scrappy@hub.org>,
Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
References: <Pine.BSF.4.21.0001032236140.18498-100000@thelab.hub.org>
<3871E6CD.2339E583@debis.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Jan Wieck wrote:
I haven't seen that many. And what kind of a project leader must it be,
that a simple announcement causes the work of several programmers over
months (sounds at least like a man-year) to be thrown away? IMHO the
kind of PL, companies like M$ are targeting with their huge amount of
announcements.
Ouch - that hurt.
Let me address the kind of project manager we are talking about here by looking
back at the decision to move from MS to Linux:
In fact, the move to Linux meant throwing away about 10 man years worth of
work on WIN32. However, the cost savings to my employer were substantial as
customer support issues disappeared overnight once the port was done. However,
the 10 MY were not discarded over a single announcement, we watched Linux and
experimented with it for about 3 years before starting the port.
To see why we would abort development on a PostgreSQL port of our servers
because of the IB announcement, you must understand why we financed the port to
PG in the first place. When GNU changed the C run time library to 2.1 (again),
it broke our IB 4.0 based software and prevented us from moving forward to the
current SuSE 6.2 (at the time) release. We knew the IB problem could be fixed
in an hour or two by recompiling the IB code - but we did not have the source
and Borland considered 4.0 dead.
In itself, this problem did not justify authorizing the PG development - but we
felt it was indicative of future problems with IB. Hence we started to
research PG to see if it was a suitable replacement. Investing in PG made me
damn nervous because I failed to locate example sites trusting it with mission
critical work. In fact, I was convinced by reading the discussion groups and
noting the extremely high caliber of people working on PG and also the
incredible integrity these guys have. Evenb though they don't make a dime from
PostgreSQL, they really, really care about the software and its users.
We now have PG based servers under test in the lab and are still solving PG
issues before releasing alpha code. Of course, the IB announcement forces us
to rethink the issue.
As for me being influenced by marketing literature, especially from MS - you
are way off mark.
By the way, I was the idiot that specified NT to our customer base in the first
place - I consider that to be the single worst decision of my successful 20
year computing career.
One final point, I live in a 100% commercial world. In the capacity of my
work, I am not concerned about the free software ethos, nor do I care if
software is free or not (as in beer) - I just need to deploy solutions that
work.
Steve
{{{{{{{{ {{{{{ 1 hour of real time passed here }}}}}}}}}
Since writing the above, I was called to attend a telecon with my manager and
the ITS managers from our two biggest customers to discuss exactly this issue.
The decision has been made to deploy the PostgreSQL based server. We all
agreed that whatever happens to Interbase, the personal commitment by the
PostgreSQL folks is not likely to dry up. Hence the code will continue to
improve over time. I believe that they clearly understand how important
reliability is to a database server.
There is a good chance that the Borland decision will have a benificial ripple
effect on PG as other engineers turn their attention to Open Source
alternatives.
Wish us luck, we will load the new software on our customers' servers for a FOT
(field operational test) next week.
Steve
From bouncefilter Tue Jan 4 18:12:03 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA22062
for <pgsql-hackers@postgresql.org>; Tue, 4 Jan 2000 18:11:46 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id TAA74477;
Tue, 4 Jan 2000 19:10:22 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 4 Jan 2000 19:10:22 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Stephen Birch <sbirch@ironmountainsystems.com>
cc: Jan Wieck <jwieck@debis.com>, Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
In-Reply-To: <387279D2.E40315DC@ironmountainsystems.com>
Message-ID: <Pine.BSF.4.21.0001041904120.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 4 Jan 2000, Stephen Birch wrote:
By the way, I was the idiot that specified NT to our customer base in
the first place - I consider that to be the single worst decision of
my successful 20 year computing career.
Ouch, that must have hurt :(
Since writing the above, I was called to attend a telecon with my
manager and the ITS managers from our two biggest customers to discuss
exactly this issue. The decision has been made to deploy the
PostgreSQL based server. We all agreed that whatever happens to
Interbase, the personal commitment by the PostgreSQL folks is not
likely to dry up. Hence the code will continue to improve over time.
I believe that they clearly understand how important reliability is to
a database server.There is a good chance that the Borland decision will have a
benificial ripple effect on PG as other engineers turn their attention
to Open Source alternatives.Wish us luck, we will load the new software on our customers' servers
for a FOT (field operational test) next week.
Good luck, and keep us informed as to how things are going ... :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Tue Jan 4 18:25:04 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA23357
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 18:25:01 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
SAA29444;
Tue, 4 Jan 2000 18:24:18 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001042324.SAA29444@candle.pha.pa.us>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
In-Reply-To: <1BF7C7482189D211B03F00805F8527F748C3CC@S-NATH-EXCH2> from
"Ansley, Michael" at "Jan 5, 2000 00:16:02 am"
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>
Date: Tue, 4 Jan 2000 18:24:18 -0500 (EST)
CC: "'Don Baccus '" <dhogaza@pacifier.com>,
"''PostgreSQL-development ' '" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Makes you wonder what people (companies) are spending their money on.
My take on it is that commercial software licensing is, by and large, a
hoax.MikeA
My guess is that in most organizations only a handful of people
understand the code. The rest do support/sales/marketing.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 4 18:49:03 2000
Received: from smtp01.infoave.net (smtp01.InfoAve.Net [165.166.0.26])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA29860
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 18:48:20 -0500 (EST)
(envelope-from jscottb@infoave.com)
Received: from dial-35.r7.scwlbo.infoave.net ("port 1867"@[207.144.212.45])
by SMTP00.InfoAve.Net (PMDF V5.1-12 #23426)
with ESMTP id <01JKBF4GWN2W8ZGYFI@SMTP00.InfoAve.Net> for
pgsql-hackers@postgreSQL.org; Tue, 4 Jan 2000 18:47:07 EST
Date: Tue, 04 Jan 2000 18:41:14 -0500 (EST)
From: Scott Beasley <jscottb@infoave.com>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
In-reply-to: <200001042324.SAA29444@candle.pha.pa.us>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Ansley Michael <Michael.Ansley@intec.co.za>,
"'Don Baccus '" <dhogaza@pacifier.com>,
"''PostgreSQL-development ' '" <pgsql-hackers@postgreSQL.org>
Message-id: <Pine.LNX.4.10.10001041837590.3445-100000@cowbox.infoave.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
On Tue, 4 Jan 2000, Bruce Momjian wrote:
Makes you wonder what people (companies) are spending their money on.
My take on it is that commercial software licensing is, by and large, a
hoax.MikeA
My guess is that in most organizations only a handful of people
understand the code. The rest do support/sales/marketing.
Thats the way it is every place I have worked. It's known as the 2/3
rule. 1/3 of your coders actually know what the hell is going on, the
other 2/3's of them are in the dark/do not care/collect a check.
scott
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026************
From bouncefilter Tue Jan 4 18:43:03 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA28691
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 18:42:56 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
SAA00412;
Tue, 4 Jan 2000 18:42:30 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001042342.SAA00412@candle.pha.pa.us>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
In-Reply-To: <387279D2.E40315DC@ironmountainsystems.com> from Stephen Birch at
"Jan 4, 2000 02:53:06 pm"
To: Stephen Birch <sbirch@ironmountainsystems.com>
Date: Tue, 4 Jan 2000 18:42:30 -0500 (EST)
CC: Jan Wieck <jwieck@debis.com>, The Hermit Hacker <scrappy@hub.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Since writing the above, I was called to attend a telecon with my manager and
the ITS managers from our two biggest customers to discuss exactly this issue.
The decision has been made to deploy the PostgreSQL based server. We all
agreed that whatever happens to Interbase, the personal commitment by the
PostgreSQL folks is not likely to dry up. Hence the code will continue to
improve over time. I believe that they clearly understand how important
reliability is to a database server.
All's well that end's well...
I have been very impressed over the three years of work on PostgreSQL
that everything is done is such a civilized matter. I mention that in
my book and in the development history.
Not sure how we have achieved this, but we certainly have.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 4 18:45:03 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA29024
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 18:44:48 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
SAA00438;
Tue, 4 Jan 2000 18:44:21 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001042344.SAA00438@candle.pha.pa.us>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
In-Reply-To: <Pine.BSF.4.21.0001041904120.18498-100000@thelab.hub.org> from
The
Hermit Hacker at "Jan 4, 2000 07:10:22 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Tue, 4 Jan 2000 18:44:21 -0500 (EST)
CC: Stephen Birch <sbirch@ironmountainsystems.com>,
Jan Wieck <jwieck@debis.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Since writing the above, I was called to attend a telecon with my
manager and the ITS managers from our two biggest customers to discuss
exactly this issue. The decision has been made to deploy the
PostgreSQL based server. We all agreed that whatever happens to
Interbase, the personal commitment by the PostgreSQL folks is not
likely to dry up. Hence the code will continue to improve over time.
I believe that they clearly understand how important reliability is to
a database server.There is a good chance that the Borland decision will have a
benificial ripple effect on PG as other engineers turn their attention
to Open Source alternatives.Wish us luck, we will load the new software on our customers' servers
for a FOT (field operational test) next week.Good luck, and keep us informed as to how things are going ... :)
Let me add we are planning a 7.0 release in the next few months that
improves reliability and adds new features. You can actually try the
snapshot if you want to see how we are doing. 6.5.* is based in code
that solidified in June of 1999, which is ages ago in PostgreSQL time.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 4 18:50:05 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id SAA30149
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 18:49:55 -0500 (EST)
(envelope-from wieck@debis.com)
Received: from debis.com by orion.SAPserv.Hamburg.dsh.de with smtp
for <pgsql-hackers@postgreSQL.org>
id m125dXv-0003kGC; Wed, 5 Jan 100 00:39 MET
Sender: wieck
Message-ID: <38728677.7C299DBA@debis.com>
Date: Wed, 05 Jan 2000 00:47:03 +0100
From: Jan Wieck <wieck@debis.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Birch <sbirch@ironmountainsystems.com>
CC: Jan Wieck <jwieck@debis.com>, The Hermit Hacker <scrappy@hub.org>,
Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
References: <Pine.BSF.4.21.0001032236140.18498-100000@thelab.hub.org>
<3871E6CD.2339E583@debis.com>
<387279D2.E40315DC@ironmountainsystems.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Stephen Birch wrote:
Jan Wieck wrote:
I haven't seen that many. And what kind of a project leader must it be,
that a simple announcement causes the work of several programmers over
months (sounds at least like a man-year) to be thrown away? IMHO the
kind of PL, companies like M$ are targeting with their huge amount of
announcements.Ouch - that hurt.
Pardon for beeing that harsh, but similar to you (as Marc said you
haven't had your first cup of coffee), I missed my required amount of
beer :-)
We now have PG based servers under test in the lab and are still solving PG
issues before releasing alpha code. Of course, the IB announcement forces us
to rethink the issue.
That sounds totally different to your first message. This is definitely
a PUSH BREAK for possible limitation of loss.
Since writing the above, I was called to attend a telecon with my manager and
the ITS managers from our two biggest customers to discuss exactly this issue.
The decision has been made to deploy the PostgreSQL based server. We all
agreed that whatever happens to Interbase, the personal commitment by the
PostgreSQL folks is not likely to dry up. Hence the code will continue to
improve over time. I believe that they clearly understand how important
reliability is to a database server.
Great news. Be sure, I'll be one of the last rats leaving the ship.
There is a good chance that the Borland decision will have a benificial ripple
effect on PG as other engineers turn their attention to Open Source
alternatives.
There aleady is a noticeable turn in attention. Creative recently
decided to put their SB-Live! drivers for Linux under GPL (after they
had severe problems with IRQ and DMA handling at least in the SMP
environment). One month later, the driver totally fit's my needs. Well,
they're a hardware vendor, primarily selling their cards to make money.
OTOH, I'm an SAP R/3 base consultant for years now. And all these DB
runtime license discussions are annoying. SAP needs about 2-3 months to
port R/3 to a new database. But they need another year or so to ship it
due to their internal quality assurance policy. And it's a not to
underestimate efford impact to support it in the future. The same
applies to the OS corner, but they decided to port R/3 to Linux anyway,
because coupling the benefits of the UNIX world (WRT administration
issues) with the low cost level of PC hardware, is definitely worth the
above efford.
So I wouldn't be surprised if SAP, one of the biggest software vendors
worldwide, would decide to support an open source database too at some
point in the future. And something like that might be the intention of
Inprise. As we both know, a customer usually keeps his database world
consistent to be able to share knowledge inside the company. So if they
can save tenth of thousands of dollars DB-license fee per year (a
usually small fee in the SAP market) when moving to an open source
database, they will decide to do so. And at that point, they'll need to
port their intranet-, internet- and other solutions as well.
If it's not true (as someone rumored) that Inprise lost the key
developers, that'd be the point.
Wish us luck, we will load the new software on our customers' servers for a FOT
(field operational test) next week.
Report any problems ASAP, and we'll help to make it a success-story.
Steve
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Tue Jan 4 18:50:03 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA29996
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 18:49:03 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
SAA00542;
Tue, 4 Jan 2000 18:48:28 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001042348.SAA00542@candle.pha.pa.us>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
In-Reply-To: <3.0.1.32.20000104172944.00ed9680@mail.pacifier.com> from Don
Baccus at "Jan 4, 2000 05:29:44 pm"
To: Don Baccus <dhogaza@pacifier.com>
Date: Tue, 4 Jan 2000 18:48:28 -0500 (EST)
CC: The Hermit Hacker <scrappy@hub.org>,
"Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'PostgreSQL-development '" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Apparently they were formed out of DEC in 1985, with the notion of
doing a "multi-generational" model from the beginning.I don't know enough Postgres history to answer. Obviously, MVCC
is new but the way that tuples are stored, which made MVCC fairly
simple to implement (for Vadim, at least!), has been part of
Postgres from the beginning.And, again, my information on Interbase comes from a VERY quick
read of docs and a white paper found on their site, take my
quick-hit analysis with a grain of salt, please!
Yes, MVCC was natural for us.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 4 15:46:02 2000
Received: from mx01.gis.net ([208.218.130.25])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA85613
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 15:45:17 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from laptop.pacifier.com (nas-77-5.boston.navinet.net [216.67.77.5])
by mx01.gis.net (8.8.8/8.8.8+pyrd) with SMTP id PAA11909;
Tue, 4 Jan 2000 15:41:39 -0500 (EST)
Message-Id: <3.0.1.32.20000104154931.00ed9658@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 04 Jan 2000 15:49:31 -0800
To: Bruce Momjian <pgman@candle.pha.pa.us>, Jan Wieck <wieck@debis.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Opensource
Cc: Jose Soares <jose@sferacarta.com>, The Hermit Hacker <scrappy@hub.org>,
Stephen Birch <sbirch@ironmountainsystems.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <200001041950.OAA20919@candle.pha.pa.us>
References: <387244DF.F0B33D5E@debis.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 02:50 PM 1/4/00 -0500, Bruce Momjian wrote:
Another _big_ issue is how clean the code is. MySQL, for example,
probably loses tons of people because their code is so poorly designed,
and just plain ugly to me.
I'll have to say that the Postgres code's quite easy to follow, at
least at the "grasp-the-big-picture" level at which I've been reading
it on a casual, off-and-on basis. Understanding it well enough to
contribute - well, that's another issue 'cause by its nature it is
a fairly complex beast!
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Tue Jan 4 15:46:01 2000
Received: from mx01.gis.net ([208.218.130.25])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA85665
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 15:45:28 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from laptop.pacifier.com (nas-77-5.boston.navinet.net [216.67.77.5])
by mx01.gis.net (8.8.8/8.8.8+pyrd) with SMTP id PAA11917;
Tue, 4 Jan 2000 15:41:44 -0500 (EST)
Message-Id: <3.0.1.32.20000104155222.00eded90@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 04 Jan 2000 15:52:22 -0800
To: Bruce Momjian <pgman@candle.pha.pa.us>,
"Ansley, Michael" <Michael.Ansley@intec.co.za>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open
source
Cc: "'PostgreSQL-development '" <pgsql-hackers@postgreSQL.org>
In-Reply-To: <200001041953.OAA21075@candle.pha.pa.us>
References: <1BF7C7482189D211B03F00805F8527F748C3BE@S-NATH-EXCH2>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 02:53 PM 1/4/00 -0500, Bruce Momjian wrote:
Great. Rumour has it there is some HOT transaction code in there, among
other things.
We may find that that HOT transaction code is the same as our
transaction code, which I guess would mean ours is HOT too.
(redundant, but what the heck)
Their "multi-generational" concurrency control sure sounds just like
MVCC.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Tue Jan 4 19:20:05 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA39544
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 19:19:18 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA01002;
Tue, 4 Jan 2000 19:18:35 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001050018.TAA01002@candle.pha.pa.us>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
In-Reply-To: <Pine.LNX.4.10.10001041837590.3445-100000@cowbox.infoave.com>
from
Scott Beasley at "Jan 4, 2000 06:41:14 pm"
To: Scott Beasley <jscottb@infoave.com>
Date: Tue, 4 Jan 2000 19:18:35 -0500 (EST)
CC: Ansley Michael <Michael.Ansley@intec.co.za>,
"'Don Baccus '" <dhogaza@pacifier.com>,
"''PostgreSQL-development ' '" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Tue, 4 Jan 2000, Bruce Momjian wrote:
Makes you wonder what people (companies) are spending their money on.
My take on it is that commercial software licensing is, by and large, a
hoax.MikeA
My guess is that in most organizations only a handful of people
understand the code. The rest do support/sales/marketing.Thats the way it is every place I have worked. It's known as the 2/3
rule. 1/3 of your coders actually know what the hell is going on, the
other 2/3's of them are in the dark/do not care/collect a check.
Oh, I didn't know it had a name. I find it usually less than 1/3.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 4 19:20:03 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA39597
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 19:19:38 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA01014;
Tue, 4 Jan 2000 19:19:01 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001050019.TAA01014@candle.pha.pa.us>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
In-Reply-To: <Pine.LNX.4.10.10001041837590.3445-100000@cowbox.infoave.com>
from
Scott Beasley at "Jan 4, 2000 06:41:14 pm"
To: Scott Beasley <jscottb@infoave.com>
Date: Tue, 4 Jan 2000 19:19:01 -0500 (EST)
CC: Ansley Michael <Michael.Ansley@intec.co.za>,
"'Don Baccus '" <dhogaza@pacifier.com>,
"''PostgreSQL-development ' '" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Tue, 4 Jan 2000, Bruce Momjian wrote:
Makes you wonder what people (companies) are spending their money on.
My take on it is that commercial software licensing is, by and large, a
hoax.MikeA
My guess is that in most organizations only a handful of people
understand the code. The rest do support/sales/marketing.Thats the way it is every place I have worked. It's known as the 2/3
rule. 1/3 of your coders actually know what the hell is going on, the
other 2/3's of them are in the dark/do not care/collect a check.
Yes, the 2/3's just push the bits around, making things worse.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 4 19:26:03 2000
Received: from smtp02.infoave.net (smtp02.InfoAve.Net [165.166.0.27])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA40784
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 19:25:56 -0500 (EST)
(envelope-from jscottb@infoave.com)
Received: from dial-35.r7.scwlbo.infoave.net ("port 1905"@[207.144.212.45])
by SMTP00.InfoAve.Net (PMDF V5.1-12 #23426)
with ESMTP id <01JKBGHES2UU8ZH38U@SMTP00.InfoAve.Net> for
pgsql-hackers@postgreSQL.org; Tue, 4 Jan 2000 19:25:47 EST
Date: Tue, 04 Jan 2000 19:19:54 -0500 (EST)
From: Scott Beasley <jscottb@infoave.com>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open source
In-reply-to: <200001050018.TAA01002@candle.pha.pa.us>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Ansley Michael <Michael.Ansley@intec.co.za>,
"'Don Baccus '" <dhogaza@pacifier.com>,
"''PostgreSQL-development ' '" <pgsql-hackers@postgreSQL.org>
Message-id: <Pine.LNX.4.10.10001041915040.3652-100000@cowbox.infoave.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
On Tue, 4 Jan 2000, Bruce Momjian wrote:
On Tue, 4 Jan 2000, Bruce Momjian wrote:
Makes you wonder what people (companies) are spending their money on.
My take on it is that commercial software licensing is, by and large, a
hoax.MikeA
My guess is that in most organizations only a handful of people
understand the code. The rest do support/sales/marketing.Thats the way it is every place I have worked. It's known as the 2/3
rule. 1/3 of your coders actually know what the hell is going on, the
other 2/3's of them are in the dark/do not care/collect a check.Oh, I didn't know it had a name. I find it usually less than 1/3.
It's from the book, "The rise and fall of the American programer", if I
remember right (It's been several years since I read it.) I would think
it's lower too, I guess it's an average, but I still find it true for the
most part. I see open source being diffent tho. The people working on OS
projects want to code.
scott
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From bouncefilter Tue Jan 4 19:23:03 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id TAA40063
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 19:22:18 -0500 (EST)
(envelope-from wieck@debis.com)
Received: from debis.com by orion.SAPserv.Hamburg.dsh.de with smtp
for <pgsql-hackers@postgreSQL.org>
id m125e3q-0003kGC; Wed, 5 Jan 100 01:12 MET
Sender: wieck
Message-ID: <38728E32.614C898@debis.com>
Date: Wed, 05 Jan 2000 01:20:02 +0100
From: Jan Wieck <wieck@debis.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
Subject: Thomas! FOREIGN KEY problem!
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Damned,
while hacking down a little test suite for FOREIGN KEY
(just to have some script based checking while doing
the file buffering of the event queue), I discovered
something looking wrong.
Having the following table schema:
CREATE TABLE t1 (
a int4 PRIMARY KEY,
b int4
);
CREATE TABLE t2 (
c int4,
d int4,
CONSTRAINT t2_d_t1_a FOREIGN KEY (d)
REFERENCES t1 MATCH FULL
ON UPDATE CASCADE
DEFERRABLE INITIALLY IMMEDIATE
);
I can do the following:
BEGIN;
SET CONSTRAINTS ALL DEFERRED;
UPDATE t1 SET a = 99 WHERE a = 1;
UPDATE t1 SET a = 1 WHERE a = 2;
UPDATE t1 SET a = 2 WHERE a = 99;
COMMIT;
to swap t1.a 1<->2.
The result (due to my internal condensing of trigger
events) is, that all references to the OLD.a=1 will end
up by referencing to NEW.a=1. In fact, they should
point to 2. What I'm unable to figure out from the SQL3
specs is, what is the correct behaviour in this case?
The simple solution would be, to bomb out at the third
UPDATE with a "triggered data change violation"
exception. Rows, resulting from the first UPDATE
(identified by XMIN) are subject to change again, and
there are outstanding trigger events. Or must the
references follow exactly the above swap? Would be more
tricky, but IMHO possible anyway.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Tue Jan 4 19:31:04 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA42969
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 19:30:46 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id TAA15958;
Tue, 4 Jan 2000 19:30:37 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] What does explain show ?
In-reply-to: <000501becda2$03e6b580$2801007e@cadzone.tpf.co.jp>
References: <000501becda2$03e6b580$2801007e@cadzone.tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Wed, 14 Jul 1999 11:38:54 +0900"
Date: Tue, 04 Jan 2000 19:30:37 -0500
Message-ID: <15955.947032237@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Quite some time ago, "Hiroshi Inoue" <Inoue@tpf.co.jp> wrote:
I have a question about "explain" output.
Table a has 15905 rows and table b has 25905 rows.
For the following query
select a.pkey, b.key2 from a, b
where b.key1 = 1369
and a.pkey = b.key1;
"explain" shows
NOTICE: QUERY PLAN:
Nested Loop (cost=6.19 rows=3 width=10)
-> Index Scan using b_pkey on b on b (cost=2.09 rows=2 width=6)
-> Index Scan using a_pkey on a on a (cost=2.05 rows=15905 width=4)
What does "rows=15905" of InnerPlan mean ?
I have finally traced through enough of the optimizer logic that I
understand where these numbers are coming from. A nestloop with an
inner index scan is a slightly unusual beast, because the cost of the
inner scan can often be reduced by using the join conditions as index
restrictions. For example, if we have "outer.a = inner.b" and the
inner scan is an indexscan on b, then during the inner scan that's
done for an outer tuple with a = 42 we'd use "b = 42" as an indexqual.
This makes the inner scan much cheaper than it would be if we had to
scan the whole table.
Now the problem is that the "rows=" numbers come from the RelOptInfo
nodes for each relation, and they are set independently of the context
that the relation is used in. For any context except an inner
indexscan, we would indeed have to scan all 15905 rows of a, because
we have no pure-restriction WHERE clauses that apply to a. So that's
why rows says 15905. The cost is being estimated correctly for the
context, though --- an indexscan across 15905 rows would take a lot more
than 2 disk accesses.
This is just a cosmetic bug since it doesn't affect the planner's cost
estimate; still, it makes the EXPLAIN output confusing. I think the
output for a nestloop should probably show the estimated number of rows
that will be scanned during each pass of the inner indexscan, which
would be about 1 in the above example. This could be done by saving the
estimated row count (or just the selectivity) in IndexScan path nodes.
Comments? Does anyone think we should show some other number?
regards, tom lane
From bouncefilter Tue Jan 4 17:24:02 2000
Received: from mx01.gis.net ([208.218.130.25])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA09611
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 17:23:34 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from laptop.pacifier.com (nas-76-111.boston.navinet.net
[216.67.76.111]) by mx01.gis.net (8.8.8/8.8.8+pyrd) with SMTP
id RAA18476; Tue, 4 Jan 2000 17:19:53 -0500 (EST)
Message-Id: <3.0.1.32.20000104172944.00ed9680@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 04 Jan 2000 17:29:44 -0800
To: The Hermit Hacker <scrappy@hub.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Inprise/Borland releasing Interbase as Open
source
Cc: Bruce Momjian <pgman@candle.pha.pa.us>,
"Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'PostgreSQL-development '" <pgsql-hackers@postgreSQL.org>
In-Reply-To: <Pine.BSF.4.21.0001041707100.18498-100000@thelab.hub.org>
References: <3.0.1.32.20000104155222.00eded90@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 05:07 PM 1/4/00 -0400, The Hermit Hacker wrote:
I wrote:
Their "multi-generational" concurrency control sure sounds just like
MVCC.
I wonder when they implemented theirs? Basically...is their's based on
old technology/concepts, while ours is based on newer ones?
Apparently they were formed out of DEC in 1985, with the notion of
doing a "multi-generational" model from the beginning.
I don't know enough Postgres history to answer. Obviously, MVCC
is new but the way that tuples are stored, which made MVCC fairly
simple to implement (for Vadim, at least!), has been part of
Postgres from the beginning.
And, again, my information on Interbase comes from a VERY quick
read of docs and a white paper found on their site, take my
quick-hit analysis with a grain of salt, please!
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Tue Jan 4 23:17:06 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA94049
for <pgsql-hackers@postgreSQL.org>; Tue, 4 Jan 2000 23:16:39 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id EAA08462;
Wed, 5 Jan 2000 04:24:52 GMT
Sender: lockhart@hub.org
Message-ID: <3872C794.A4751262@alumni.caltech.edu>
Date: Wed, 05 Jan 2000 04:24:52 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: Stephen Birch <sbirch@ironmountainsystems.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: date/time type changes
References: <200001041952.OAA21002@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Wouldn't it make more sense to rename timestamp to datetime because
datetime is the ANSI name? Just asking.
timestamp is the SQL92 name for the date+time data type. datetime was
a name concocted by me to avoid conflicting with other possible
standard names when I first implemented the "new and improved"
date/time types. Am I missing something in my recollection??
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Wed Jan 5 00:02:09 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA03485
for <pgsql-hackers@postgreSQL.org>; Wed, 5 Jan 2000 00:01:46 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
XAA03415;
Tue, 4 Jan 2000 23:44:15 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001050444.XAA03415@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: date/time type changes
In-Reply-To: <3872C794.A4751262@alumni.caltech.edu> from Thomas Lockhart at
"Jan 5, 2000 04:24:52 am"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Tue, 4 Jan 2000 23:44:14 -0500 (EST)
CC: Stephen Birch <sbirch@ironmountainsystems.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Wouldn't it make more sense to rename timestamp to datetime because
datetime is the ANSI name? Just asking.timestamp is the SQL92 name for the date+time data type. datetime was
a name concocted by me to avoid conflicting with other possible
standard names when I first implemented the "new and improved"
date/time types. Am I missing something in my recollection??
Oh, I better fix my book.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Jan 5 00:02:10 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA02941
for <pgsql-hackers@postgreSQL.org>; Wed, 5 Jan 2000 00:01:23 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
XAA04152;
Tue, 4 Jan 2000 23:56:28 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001050456.XAA04152@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: date/time type changes
In-Reply-To: <3872C794.A4751262@alumni.caltech.edu> from Thomas Lockhart at
"Jan 5, 2000 04:24:52 am"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Tue, 4 Jan 2000 23:56:28 -0500 (EST)
CC: Stephen Birch <sbirch@ironmountainsystems.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Wouldn't it make more sense to rename timestamp to datetime because
datetime is the ANSI name? Just asking.timestamp is the SQL92 name for the date+time data type. datetime was
a name concocted by me to avoid conflicting with other possible
standard names when I first implemented the "new and improved"
date/time types. Am I missing something in my recollection??
I had refered to datetime in my book, thinking that was the standard
name. I now see it is TIMESTAMP. Good thing someone asked about this.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Jan 5 01:57:08 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA27659
for <pgsql-hackers@postgreSQL.org>; Wed, 5 Jan 2000 01:56:15 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA16593
for <pgsql-hackers@postgreSQL.org>; Wed, 5 Jan 2000 01:56:14 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: Y2K glitch in pgsql mail list archives
Date: Wed, 05 Jan 2000 01:56:14 -0500
Message-ID: <16590.947055374@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
By now, most of the pgsql mailing lists surely have messages
dated later than 31-Dec-1999 ... but you wouldn't know it by
looking at http://www.postgresql.org/lists/mailing-list.html.
I'm guessing the code that adds links to those pages has a
little Y2K bug.
regards, tom lane
From bouncefilter Wed Jan 5 02:25:09 2000
Received: from mail.etechnologiescorp.com (postfix@[210.8.40.210])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA33502
for <pgsql-interfaces@postgresql.org>;
Wed, 5 Jan 2000 02:24:17 -0500 (EST)
(envelope-from timk@hotgames.com)
Received: from hotgames.com (timk.pn.etechnologiescorp.com [192.168.1.125])
by mail.etechnologiescorp.com (Postfix) with ESMTP id DA0E17504A
for <pgsql-interfaces@postgresql.org>;
Wed, 5 Jan 2000 18:24:14 +1100 (EST)
Message-ID: <3872F1C3.8007B24B@hotgames.com>
Date: Wed, 05 Jan 2000 18:24:51 +1100
From: Tim Kane <timk@hotgames.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-interfaces@postgresql.org
Subject: ECPG and FETCH
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
First of all, ECPG doesn't seem to recognise the FETCH command at all,
returning with Syntax Error (see below).
Secondly, are there any postgres specific Embedded SQL docs around
'anywhere'?
I've already have a few difficulties with subtle differences between
different precompiler syntax, and it's becoming frustrating.
Thanks for any help!
Tim.
eg:
EXEC SQL DECLARE rowcur CURSOR FOR
SELECT prod_id, name, format
FROM products
WHERE name like '%ABC%';
EXEC SQL OPEN rowcur;
for (i=0; i<5; i++)
{
EXEC SQL FETCH rowcur INTO :prod_id, :title, :format;
// Do something.
}
From bouncefilter Wed Jan 5 02:38:10 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA37767
for <pgsql-hackers@postgreSQL.org>; Wed, 5 Jan 2000 02:38:01 -0500 (EST)
(envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id QAA01162; Wed, 05 Jan 2000 16:36:29 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] What does explain show ?
Date: Wed, 5 Jan 2000 16:41:52 +0900
Message-ID: <000101bf5750$550a45c0$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <15955.947032237@sss.pgh.pa.us>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Wednesday, January 05, 2000 9:31 AMQuite some time ago, "Hiroshi Inoue" <Inoue@tpf.co.jp> wrote:
I have a question about "explain" output.
Table a has 15905 rows and table b has 25905 rows.
For the following query
select a.pkey, b.key2 from a, b
where b.key1 = 1369
and a.pkey = b.key1;
"explain" showsNOTICE: QUERY PLAN:
Nested Loop (cost=6.19 rows=3 width=10)
-> Index Scan using b_pkey on b on b (cost=2.09 rows=2 width=6)
-> Index Scan using a_pkey on a on a (cost=2.05 rows=15905 width=4)What does "rows=15905" of InnerPlan mean ?
I have finally traced through enough of the optimizer logic that I
understand where these numbers are coming from. A nestloop with an
inner index scan is a slightly unusual beast, because the cost of the
inner scan can often be reduced by using the join conditions as index
restrictions. For example, if we have "outer.a = inner.b" and the
inner scan is an indexscan on b, then during the inner scan that's
done for an outer tuple with a = 42 we'd use "b = 42" as an indexqual.
This makes the inner scan much cheaper than it would be if we had to
scan the whole table.Now the problem is that the "rows=" numbers come from the RelOptInfo
nodes for each relation, and they are set independently of the context
that the relation is used in. For any context except an inner
indexscan, we would indeed have to scan all 15905 rows of a, because
we have no pure-restriction WHERE clauses that apply to a. So that's
why rows says 15905. The cost is being estimated correctly for the
context, though --- an indexscan across 15905 rows would take a lot more
than 2 disk accesses.This is just a cosmetic bug since it doesn't affect the planner's cost
estimate; still, it makes the EXPLAIN output confusing. I think the
output for a nestloop should probably show the estimated number of rows
that will be scanned during each pass of the inner indexscan, which
would be about 1 in the above example. This could be done by saving the
estimated row count (or just the selectivity) in IndexScan path nodes.Comments? Does anyone think we should show some other number?
I agree with you.
The rows should show some kind of average number of rows,because
the cost of innerplan seems to mean average cost.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Wed Jan 5 02:38:08 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA37698
for <pgsql-hackers@postgreSQL.org>; Wed, 5 Jan 2000 02:37:19 -0500 (EST)
(envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id QAA01166; Wed, 05 Jan 2000 16:37:04 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Jan Wieck" <wieck@debis.com>
Cc: <a.joubert@albourne.com>, <pgsql-hackers@postgreSQL.org>,
"Tom Lane" <tgl@sss.pgh.pa.us>
Subject: RE: [HACKERS] Index corruption
Date: Wed, 5 Jan 2000 16:42:27 +0900
Message-ID: <000201bf5750$69f187a0$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <m123SUu-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Jan WieckAnyway, I still think that a new implementation of reindexdb
would be good. Some of the system indices can cause big, big
trouble, if they get corrupted. If you would ever be faced
with a corrupted pg_class_... index, you won't be able to
dump any more, because the backend will fail to startup at
all.I analyzed the problem of recreating system catalog indices
some weeks ago, and ISTM that during bootstrap operation, ALL
tuples are visible.I hacked in a "drop index" for the bootstrap parser, and on a
freshly created DB some hand-made BKI script ran smooth and
recreated all the indices well. But it failed on the
regression DB, bacause it bombed out with duplicate errors.
First I was a little puzzled about it, because I allways
thought that only vacuum removes index tuples. So it could
only be the main tuples visibility that prevents from dup
errors between vacuum times.Thus, IMHO there should be another command added to the
bootstrap parser. This would recreate ALL existing indices
(system and user ones), but tell the visibility code somehow
to ignore deleted tuples. I don't have the time to do it now,
so at least I'd like to have a TODO item for it.
I may be able to implement reindex command unless you have
the time to do it.
Different from your suggestion,I would implement it in a non-bootstrap
standalone postgres with the new option by which PostgreSQL ignores
system indexes.
Comments ?
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Wed Jan 5 03:06:09 2000
Received: from cap-ferrat.albourne.com (cap-ferrat.albourne.com
[195.89.178.227]) by hub.org (8.9.3/8.9.3) with ESMTP id DAA47884
for <pgsql-hackers@postgreSQL.org>; Wed, 5 Jan 2000 03:05:25 -0500 (EST)
(envelope-from a.joubert@albourne.com)
Received: from albourne.com (bishop-rock.albourne.com [195.89.178.230])
by cap-ferrat.albourne.com (8.9.3/8.9.3/Albourne/UKS/2.9/MAPS) with
ESMTP id IAA12604
for <pgsql-hackers@postgreSQL.org>; Wed, 5 Jan 2000 08:05:23 GMT
Sender: a.joubert@albourne.com
Message-ID: <3872FD18.E9BDB7AC@albourne.com>
Date: Wed, 05 Jan 2000 10:13:13 +0200
From: Adriaan Joubert <a.joubert@albourne.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.38 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Index corruption
References: <000201bf5750$69f187a0$2801007e@tpf.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I may be able to implement reindex command unless you have
the time to do it.Different from your suggestion,I would implement it in a non-bootstrap
standalone postgres with the new option by which PostgreSQL ignores
system indexes.Comments ?
That would be really useful. BTW, I've been running the patched database
fora little while now and all my problems seem to have gone away. Thanks
a lot to all of you!
Adriaan
From bouncefilter Wed Jan 5 07:00:11 2000
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA89398
for <pgsql-hackers@postgreSQL.org>; Wed, 5 Jan 2000 06:59:28 -0500 (EST)
(envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA10386
for <pgsql-hackers@postgreSQL.org>; Wed, 5 Jan 2000 12:44:59 +0100
Date: Wed, 5 Jan 2000 12:44:59 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: ordinal decimal number
Message-ID: <Pine.LNX.3.96.1000105123912.9961A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi,
I add to the to_char() routine "ordinal-number" feature, but my
English is insufficient for this :-( (sorry)
I good know how is it for non-decimal numbers, but if number has
decimal part?
Example: 2.6 --> 2.6th
or 2.6 --> 2.6nd
Please!
Karel
----------------------------------------------------------------------
Karel Zak <zakkr@zf.jcu.cz> http://home.zf.jcu.cz/~zakkr/
Docs: http://docs.linux.cz (big docs archive)
Kim Project: http://home.zf.jcu.cz/~zakkr/kim/ (process manager)
FTP: ftp://ftp2.zf.jcu.cz/users/zakkr/ (C/ncurses/PgSQL)
-----------------------------------------------------------------------
From bouncefilter Wed Jan 5 07:11:12 2000
Received: from tango.SoftHome.net (tango.SoftHome.net [204.144.231.49])
by hub.org (8.9.3/8.9.3) with SMTP id HAA93798
for <pgsql-hackers@postgreSQL.org>; Wed, 5 Jan 2000 07:10:41 -0500 (EST)
(envelope-from j.roeleveld@softhome.net)
Received: (qmail 32281 invoked by uid 417); 5 Jan 2000 12:10:53 -0000
Received: from sentec.demon.nl (HELO joost) (212.238.106.25)
by smtpb.softhome.net with SMTP; 5 Jan 2000 12:10:53 -0000
Message-ID: <000901bf5775$c5a55480$8402a8c0@sentec.demon.nl>
From: "J. Roeleveld" <j.roeleveld@softhome.net>
To: "Karel Zak - Zakkr" <zakkr@zf.jcu.cz>,
"pgsql-hackers" <pgsql-hackers@postgreSQL.org>
References: <Pine.LNX.3.96.1000105123912.9961A-100000@ara.zf.jcu.cz>
Subject: Re: [HACKERS] ordinal decimal number
Date: Wed, 5 Jan 2000 13:09:50 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Hi,
I add to the to_char() routine "ordinal-number" feature, but my
English is insufficient for this :-( (sorry)
There are enough people that speak English, what we don't have enough
of on this world are people that know what they can and can't do :)
I good know how is it for non-decimal numbers, but if number has
decimal part?Example: 2.6 --> 2.6th
or 2.6 --> 2.6nd
It's: 2.6 --> 2.6th
Joost Roeleveld
From bouncefilter Wed Jan 5 09:06:14 2000
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA17759
for <pgsql-hackers@postgreSQL.org>; Wed, 5 Jan 2000 09:06:12 -0500 (EST)
(envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA19946;
Wed, 5 Jan 2000 14:51:35 +0100
Date: Wed, 5 Jan 2000 14:51:35 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Oliver Elphick <olly@lfix.co.uk>
cc: "J. Roeleveld" <j.roeleveld@softhome.net>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ordinal decimal number
In-Reply-To: <200001051355.NAA13989@linda.lfix.co.uk>
Message-ID: <Pine.LNX.3.96.1000105144609.10672B-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 5 Jan 2000, Oliver Elphick wrote:
"J. Roeleveld" wrote:
Hi,
I add to the to_char() routine "ordinal-number" feature, but my
English is insufficient for this :-( (sorry)There are enough people that speak English, what we don't have enough
of on this world are people that know what they can and can't do :)I good know how is it for non-decimal numbers, but if number has
decimal part?Example: 2.6 --> 2.6th
or 2.6 --> 2.6ndIt's: 2.6 --> 2.6th
It isn't really possible to have an ordinal with decimal places in
English; it sounds very awkward.Ordinals designate placing in a list; a computer example would be an
array index. How can such a number have decimal places?
I implement it to to_char (ordinal with decimal places), but is user choise
if use or not use it...
Karel
From bouncefilter Wed Jan 5 08:56:14 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA13357
for <pgsql-hackers@postgreSQL.org>; Wed, 5 Jan 2000 08:55:54 -0500 (EST)
(envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max01-017.enterprise.net
[194.72.195.17])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id NAA20258;
Wed, 5 Jan 2000 13:55:49 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id NAA13989;
Wed, 5 Jan 2000 13:55:47 GMT
Message-Id: <200001051355.NAA13989@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: "J. Roeleveld" <j.roeleveld@softhome.net>
cc: "Karel Zak - Zakkr" <zakkr@zf.jcu.cz>,
"pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ordinal decimal number
In-Reply-To: Message from "J. Roeleveld" <j.roeleveld@softhome.net> of "Wed,
05 Jan 2000 13:09:50 +0100."
<000901bf5775$c5a55480$8402a8c0@sentec.demon.nl>
References: <Pine.LNX.3.96.1000105123912.9961A-100000@ara.zf.jcu.cz>
<000901bf5775$c5a55480$8402a8c0@sentec.demon.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 05 Jan 2000 13:55:47 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
"J. Roeleveld" wrote:
Hi,
I add to the to_char() routine "ordinal-number" feature, but my
English is insufficient for this :-( (sorry)There are enough people that speak English, what we don't have enough
of on this world are people that know what they can and can't do :)I good know how is it for non-decimal numbers, but if number has
decimal part?Example: 2.6 --> 2.6th
or 2.6 --> 2.6ndIt's: 2.6 --> 2.6th
It isn't really possible to have an ordinal with decimal places in
English; it sounds very awkward.
Ordinals designate placing in a list; a computer example would be an
array index. How can such a number have decimal places?
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"And thou shalt love the LORD thy God with all thine
heart, and with all thy soul, and with all thy might."
Deuteronomy 6:5
From bouncefilter Wed Jan 5 09:37:13 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id JAA23810
for <pgsql-hackers@postgreSQL.org>; Wed, 5 Jan 2000 09:37:05 -0500 (EST)
(envelope-from wieck@debis.com)
Received: from debis.com by orion.SAPserv.Hamburg.dsh.de with smtp
for <pgsql-hackers@postgreSQL.org>
id m125rOY-0003kGC; Wed, 5 Jan 100 15:26 MET
Sender: wieck
Message-ID: <38735666.AB28504B@debis.com>
Date: Wed, 05 Jan 2000 15:34:14 +0100
From: Jan Wieck <wieck@debis.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Hiroshi Inoue <Inoue@tpf.co.jp>
CC: a.joubert@albourne.com, pgsql-hackers@postgreSQL.org,
Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: [HACKERS] Index corruption
References: <000201bf5750$69f187a0$2801007e@tpf.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hiroshi Inoue wrote:
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Jan WieckThus, IMHO there should be another command added to the
bootstrap parser. This would recreate ALL existing indices
(system and user ones), but tell the visibility code somehow
to ignore deleted tuples. I don't have the time to do it now,
so at least I'd like to have a TODO item for it.I may be able to implement reindex command unless you have
the time to do it.Different from your suggestion,I would implement it in a non-bootstrap
standalone postgres with the new option by which PostgreSQL ignores
system indexes.
Sounds good to me.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Wed Jan 5 10:01:13 2000
Received: from punta.ultra.hr (ip.zadarnet.hr [195.29.197.33])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA31280
for <pgsql-interfaces@postgresql.org>;
Wed, 5 Jan 2000 10:00:19 -0500 (EST)
(envelope-from ivo@punta.ultra.hr)
Received: by punta.ultra.hr (Postfix, from userid 1001)
id CE1483C8EC; Wed, 5 Jan 2000 16:04:20 +0100 (CET)
Date: Wed, 5 Jan 2000 16:04:20 +0100
From: Ivo Simicevic <ivo@ultra.hr>
To: Tim Kane <timk@hotgames.com>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: [INTERFACES] ECPG and FETCH
Message-ID: <20000105160420.A740@ultra.hr>
References: <3872F1C3.8007B24B@hotgames.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/0.95.7i
In-Reply-To: <3872F1C3.8007B24B@hotgames.com>
Sender: ivo@punta.ultra.hr
On Wed, Jan 05, 2000 at 06:24:51PM +1100, Tim Kane wrote:
EXEC SQL FETCH rowcur INTO :prod_id, :title, :format;
Try EXEC SQL FETCH IN rowcur ...
Ivo.
From bouncefilter Wed Jan 5 10:57:14 2000
Received: from hu.tm.ee (isdn-54.uninet.ee [194.204.0.118])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA44062
for <pgsql-hackers@postgreSQL.org>; Wed, 5 Jan 2000 10:56:33 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 1EF58B3C2; Wed, 5 Jan 2000 18:00:56 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38736AB7.54CCA399@tm.ee>
Date: Wed, 05 Jan 2000 18:00:55 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
Cc: Oliver Elphick <olly@lfix.co.uk>,
"J. Roeleveld" <j.roeleveld@softhome.net>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ordinal decimal number
References: <Pine.LNX.3.96.1000105144609.10672B-100000@ara.zf.jcu.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Karel Zak - Zakkr wrote:
On Wed, 5 Jan 2000, Oliver Elphick wrote:
"J. Roeleveld" wrote:
Hi,
I add to the to_char() routine "ordinal-number" feature, but my
English is insufficient for this :-( (sorry)There are enough people that speak English, what we don't have enough
of on this world are people that know what they can and can't do :)I good know how is it for non-decimal numbers, but if number has
decimal part?Example: 2.6 --> 2.6th
or 2.6 --> 2.6ndIt's: 2.6 --> 2.6th
It isn't really possible to have an ordinal with decimal places in
English; it sounds very awkward.Ordinals designate placing in a list; a computer example would be an
array index. How can such a number have decimal places?
I guess they are awkward in most languages, except for designating powers
where they _could_ be used by extension of their use for integer powers?
e raised to the pi-th power ?
btw, should 2.2 be 2.2nd or 2.2th (two point tooth :)
what about rationals 7 2/3 th ?
what about legal float numbers like infinity (is it infinitieth)
and NaN - NaN-th or NaNd :)
for me 2.2nd represents not decimal but hierrachy, so it should be possible to
have
2.2.2.2nd
I implement it to to_char (ordinal with decimal places), but is user choise
if use or not use it...
Is your code locale-aware ?
I guess that this is something that could probbaly be found in localisation
tables,
except perhaps for floats.
------------------
Hannu
From bouncefilter Wed Jan 5 10:59:14 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA44269
for <pgsql-interfaces@postgreSQL.org>;
Wed, 5 Jan 2000 10:58:36 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA15122;
Wed, 5 Jan 2000 16:07:02 GMT
Sender: lockhart@hub.org
Message-ID: <38736C26.4A9B8777@alumni.caltech.edu>
Date: Wed, 05 Jan 2000 16:07:02 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tim Kane <timk@hotgames.com>
CC: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] ECPG and FETCH
References: <3872F1C3.8007B24B@hotgames.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Secondly, are there any postgres specific Embedded SQL docs around
'anywhere'?
I've already have a few difficulties with subtle differences between
different precompiler syntax, and it's becoming frustrating.
That's one of the holes in our documentation. If you get inspired to
write, we would welcome a contribution of any sort (including just
your notes on syntax as you learn to use the preprocessor). Our doc
sources are in sgml, but if you want to just write flat files I'll
convert it for you...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Wed Jan 5 11:43:15 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA54826
for <pgsql-hackers@postgresql.org>; Wed, 5 Jan 2000 11:42:44 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id LAA06879
for <pgsql-hackers@postgresql.org>; Wed, 5 Jan 2000 11:42:48 -0500
Message-ID: <38737481.4B7A5406@wgcr.org>
Date: Wed, 05 Jan 2000 11:42:41 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: InterBase interview on Linux Journal
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
They need to be educated about us.....
http://www2.linuxjournal.com/articles/conversations/010.html
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Wed Jan 5 12:22:15 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA74631
for <pgsql-hackers@postgreSQL.org>; Wed, 5 Jan 2000 12:21:50 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id RAA16073;
Wed, 5 Jan 2000 17:30:15 GMT
Sender: lockhart@hub.org
Message-ID: <38737FA7.1AF1EE0B@alumni.caltech.edu>
Date: Wed, 05 Jan 2000 17:30:15 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Lamar Owen <lamar.owen@wgcr.org>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] InterBase interview on Linux Journal
References: <38737481.4B7A5406@wgcr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
They need to be educated about us.....
http://www2.linuxjournal.com/articles/conversations/010.html
Yeah. I just sent a comment to them on this. I had talked to Marjorie
Richards (from memory; I think that is the name) at LinuxWorld in
August regarding Postgres articles, and she indicated that they might
be interested in principle but that that they had recently done an
introductory review article (nice and complimentary btw) and didn't
have a specific need for more intro material. We have had mention in
other articles since then, as the tool used to implement other apps.
But it seems that Doc Searls doesn't read them very carefully ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Wed Jan 5 13:04:16 2000
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA86312
for <pgsql-hackers@postgreSQL.org>; Wed, 5 Jan 2000 13:04:02 -0500 (EST)
(envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA30366;
Wed, 5 Jan 2000 18:49:13 +0100
Date: Wed, 5 Jan 2000 18:49:12 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Hannu Krosing <hannu@tm.ee>
cc: Oliver Elphick <olly@lfix.co.uk>,
"J. Roeleveld" <j.roeleveld@softhome.net>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ordinal decimal number
In-Reply-To: <38736AB7.54CCA399@tm.ee>
Message-ID: <Pine.LNX.3.96.1000105184134.23260A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 5 Jan 2000, Hannu Krosing wrote:
I guess they are awkward in most languages, except for designating powers
where they _could_ be used by extension of their use for integer powers?e raised to the pi-th power ?
btw, should 2.2 be 2.2nd or 2.2th (two point tooth :)
what about rationals 7 2/3 th ?
what about legal float numbers like infinity (is it infinitieth)
and NaN - NaN-th or NaNd :)for me 2.2nd represents not decimal but hierrachy, so it should be possible to
have
2.2.2.2ndI implement it to to_char (ordinal with decimal places), but is user choise
if use or not use it...Is your code locale-aware ?
I guess that this is something that could probbaly be found in localisation
tables,
except perhaps for floats.
(IMHO) POSIX locale not contains information about ordinal numbers (if
you mean this). But to_char supports locales for currency symbol, decimal
poin and group separator.
Karel
From bouncefilter Wed Jan 5 13:02:17 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA84096
for <hackers@postgresql.org>; Wed, 5 Jan 2000 13:01:55 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id SAA16211;
Wed, 5 Jan 2000 18:10:14 GMT
Sender: lockhart@hub.org
Message-ID: <38738906.91E42C78@alumni.caltech.edu>
Date: Wed, 05 Jan 2000 18:10:14 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Ivo Simicevic <ivo@ultra.hr>
CC: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: ECPG documentation
References: <3872F1C3.8007B24B@hotgames.com>
<38736C26.4A9B8777@alumni.caltech.edu>
<20000105185234.H740@ultra.hr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
(back on-list; hope that is OK...)
I just wanted to let you know that some time ago, after contacting
Michael Meskes I have started working on ECPG documentation.
... you can see some text file sketches on my web at
http://www.ultra.hr/gpl/ecpg
Looks great! Hope you find time to get back to it, and I'll be happy
to help with sgml markup.
btw, if you could finish a first draft (or have enough sections to be
usable) within a month or so there is a good chance we can get it
included in the v7.0 release. Much later than that and we'll probably
miss the window...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Wed Jan 5 13:22:18 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA88633
for <pgsql-hackers@postgreSQL.org>; Wed, 5 Jan 2000 13:22:15 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id OAA83198;
Wed, 5 Jan 2000 14:21:55 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 5 Jan 2000 14:21:55 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Lamar Owen <lamar.owen@wgcr.org>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] InterBase interview on Linux Journal
In-Reply-To: <38737FA7.1AF1EE0B@alumni.caltech.edu>
Message-ID: <Pine.BSF.4.21.0001051420420.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 5 Jan 2000, Thomas Lockhart wrote:
They need to be educated about us.....
http://www2.linuxjournal.com/articles/conversations/010.htmlYeah. I just sent a comment to them on this. I had talked to Marjorie
Richards (from memory; I think that is the name) at LinuxWorld in
August regarding Postgres articles, and she indicated that they might
be interested in principle but that that they had recently done an
introductory review article (nice and complimentary btw) and didn't
have a specific need for more intro material. We have had mention in
other articles since then, as the tool used to implement other apps.
But it seems that Doc Searls doesn't read them very carefully ;)
Personally, I think that everyone should go to that article and put in a
comment to the effect that the Title of the article is inaccurate, and
insults the whole Open Source movement by claiming that a commercial
product, going open source, gets labelled as "The first major..."
From bouncefilter Wed Jan 5 13:38:17 2000
Received: from p3E9C145E.dip0.t-ipconnect.de
(root@p3E9C145E.dip0.t-ipconnect.de [62.156.20.94])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA94407
for <pgsql-interfaces@postgreSQL.org>;
Wed, 5 Jan 2000 13:37:51 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.3/Debian 8.9.3-6) id TAA13160
for pgsql-interfaces@postgreSQL.org; Wed, 5 Jan 2000 19:30:59 +0100
Date: Wed, 5 Jan 2000 19:30:59 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] ECPG and FETCH
Message-ID: <20000105193059.A13149@fam-meskes.de>
Mail-Followup-To: pgsql-interfaces@postgreSQL.org
References: <3872F1C3.8007B24B@hotgames.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <3872F1C3.8007B24B@hotgames.com>;
from timk@hotgames.com on Wed, Jan 05, 2000 at 06:24:51PM +1100
On Wed, Jan 05, 2000 at 06:24:51PM +1100, Tim Kane wrote:
First of all, ECPG doesn't seem to recognise the FETCH command at all,
returning with Syntax Error (see below).
FETCH IN should work as well as FETCH FROM. I think this is what standard
says. I once tried to add FETCH without IN but got some shift/reduce
conflicts. I haven't looked into it for quite some time, so maybe I can add
a compatibility rule. But don't bet on it.
Secondly, are there any postgres specific Embedded SQL docs around
'anywhere'?
Unfortunately not much. But there are some (5 to be precise) demo files in
the source tree.
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Wed Jan 5 14:40:17 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA09687
for <pgsql-hackers@postgreSQL.org>; Wed, 5 Jan 2000 14:39:19 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA28588;
Wed, 5 Jan 2000 14:23:17 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001051923.OAA28588@candle.pha.pa.us>
Subject: Re: [HACKERS] InterBase interview on Linux Journal
In-Reply-To: <Pine.BSF.4.21.0001051420420.18498-100000@thelab.hub.org> from
The
Hermit Hacker at "Jan 5, 2000 02:21:55 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Wed, 5 Jan 2000 14:23:17 -0500 (EST)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Lamar Owen <lamar.owen@wgcr.org>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Wed, 5 Jan 2000, Thomas Lockhart wrote:
They need to be educated about us.....
http://www2.linuxjournal.com/articles/conversations/010.htmlYeah. I just sent a comment to them on this. I had talked to Marjorie
Richards (from memory; I think that is the name) at LinuxWorld in
August regarding Postgres articles, and she indicated that they might
be interested in principle but that that they had recently done an
introductory review article (nice and complimentary btw) and didn't
have a specific need for more intro material. We have had mention in
other articles since then, as the tool used to implement other apps.
But it seems that Doc Searls doesn't read them very carefully ;)Personally, I think that everyone should go to that article and put in a
comment to the effect that the Title of the article is inaccurate, and
insults the whole Open Source movement by claiming that a commercial
product, going open source, gets labelled as "The first major..."
Totally agree. And as far as I am concerned, Interbase is not major at
all.
So we have a non-major database vendor claiming they are the first major
database vendor to go open-source.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Jan 5 14:52:18 2000
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA11550
for <pgsql-hackers@postgreSQL.org>; Wed, 5 Jan 2000 14:52:10 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <ZW4G6Y88>; Wed, 5 Jan 2000 21:49:08 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C3DF@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To:
Cc: "'pgsql-hackers '" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] ordinal decimal number
Date: Wed, 5 Jan 2000 21:38:43 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"
My personal opinion: ordinal numbers can get a th, rd, nd, or st. That
implies whole numbers only. If an ordinal is requested, test for a positive
integer; if not an integer, leave alone, otherwise add whichever suffix is
required.
2 -> 2nd
2.2 -> 2.2
NaN -> NaN
4 -> 4th
-6 -> -6
MikeA
-----Original Message-----
From: Hannu Krosing
To: Karel Zak - Zakkr
Cc: Oliver Elphick; J. Roeleveld; pgsql-hackers
Sent: 00/01/05 06:00
Subject: Re: [HACKERS] ordinal decimal number
Karel Zak - Zakkr wrote:
On Wed, 5 Jan 2000, Oliver Elphick wrote:
"J. Roeleveld" wrote:
Hi,
I add to the to_char() routine "ordinal-number" feature, but my
English is insufficient for this :-( (sorry)There are enough people that speak English, what we don't have
enough
of on this world are people that know what they can and can't do
:)
I good know how is it for non-decimal numbers, but if number
has
decimal part?
Example: 2.6 --> 2.6th
or 2.6 --> 2.6ndIt's: 2.6 --> 2.6th
It isn't really possible to have an ordinal with decimal places in
English; it sounds very awkward.Ordinals designate placing in a list; a computer example would be an
array index. How can such a number have decimal places?
I guess they are awkward in most languages, except for designating
powers
where they _could_ be used by extension of their use for integer powers?
e raised to the pi-th power ?
btw, should 2.2 be 2.2nd or 2.2th (two point tooth :)
what about rationals 7 2/3 th ?
what about legal float numbers like infinity (is it infinitieth)
and NaN - NaN-th or NaNd :)
for me 2.2nd represents not decimal but hierrachy, so it should be
possible to
have
2.2.2.2nd
I implement it to to_char (ordinal with decimal places), but is user
choise
if use or not use it...
Is your code locale-aware ?
I guess that this is something that could probbaly be found in
localisation
tables,
except perhaps for floats.
------------------
Hannu
************
From bouncefilter Wed Jan 5 14:42:18 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA09990
for <pgsql-hackers@postgresql.org>; Wed, 5 Jan 2000 14:41:40 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id PAA84255
for <pgsql-hackers@postgresql.org>; Wed, 5 Jan 2000 15:41:47 -0400 (AST)
(envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 5 Jan 2000 15:41:47 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: My response/comments to Inbase Interview ...
Message-ID: <Pine.BSF.4.21.0001051540530.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
More:
Technical:
Comments: As a developing member of *several* Open Source Projects (INN,
FreeBSD, PostgreSQL, WU-FTPd *and* OpenSSH), I would like to
state that I find the title of this whole article to be
insulting to the Open Source Community ... to classify a
commercial vendor as "the first major..." when they haven't even
*released* the source yet is, at best, premature. Both
PostgreSQL and MySQL have *always* been Open Source, and
probably have more influence on the OS-DBMS market then Inbase
does, or even will ...
Series: Conversations
Article: 10
Title: The First Major Open Source Database
Author: Doc Searls
Author's email: doc@ssc.com
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Wed Jan 5 15:37:19 2000
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id PAA26385
for <pgsql-hackers@postgresql.org>; Wed, 5 Jan 2000 15:37:07 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <ZW4G6Y9F>; Wed, 5 Jan 2000 22:34:07 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C3E1@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'The Hermit Hacker '" <scrappy@hub.org>, "'Thomas Lockhart '"
<lockhart@alumni.caltech.edu>
Cc: "'Lamar Owen '" <lamar.owen@wgcr.org>, "'pgsql-hackers@postgresql.org '"
<pgsql-hackers@postgresql.org>
Subject: RE: [HACKERS] InterBase interview on Linux Journal
Date: Wed, 5 Jan 2000 22:20:57 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"
Yes, it was a little inaccurate ;-)
However, having read the article, I think that there may just be a decent
product out at the end under a good license. Borland have always, for
better or worse (and it shows in their last couple of income statements ;-)
made a habit of putting technology before profits. I think that they're
about to do it again. However, this time, they appear to have someone who
has a reasonable understanding of what he's doing in business terms at the
head, and I think that they may just make good here, for the benefit of all
of us. Doing open source business is something that people like Bill will
never be able to understand completely. This guy seemed to almost grow up
on it, and understands it like must of us do.
Perhaps the coding is crappy, or perhaps they do what Sun did for licensing,
or something even worse.
But maybe the code is good, and the license really open, and no programmer
can get too much exposure to other peoples code, whether it's to learn how
to do things, or to learn how not to do things.
I think that PostgreSQL stands to gain an enormous amount out of the whole
episode, both in marketing, as well as guidance in certain areas, and
verification (that's not the word I'm looking for, but I can't think of the
right one now) in others.
Anyway, EXPLAIN needs some adjustments, so no more rambling...
MikeA
-----Original Message-----
From: The Hermit Hacker
To: Thomas Lockhart
Cc: Lamar Owen; pgsql-hackers@postgresql.org
Sent: 00/01/05 08:21
Subject: Re: [HACKERS] InterBase interview on Linux Journal
On Wed, 5 Jan 2000, Thomas Lockhart wrote:
They need to be educated about us.....
http://www2.linuxjournal.com/articles/conversations/010.htmlYeah. I just sent a comment to them on this. I had talked to Marjorie
Richards (from memory; I think that is the name) at LinuxWorld in
August regarding Postgres articles, and she indicated that they might
be interested in principle but that that they had recently done an
introductory review article (nice and complimentary btw) and didn't
have a specific need for more intro material. We have had mention in
other articles since then, as the tool used to implement other apps.
But it seems that Doc Searls doesn't read them very carefully ;)
Personally, I think that everyone should go to that article and put in a
comment to the effect that the Title of the article is inaccurate, and
insults the whole Open Source movement by claiming that a commercial
product, going open source, gets labelled as "The first major..."
************
From bouncefilter Wed Jan 5 23:25:23 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA32404
for <pgsql-hackers@postgreSQL.org>; Wed, 5 Jan 2000 23:25:09 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id XAA20068
for <pgsql-hackers@postgreSQL.org>; Wed, 5 Jan 2000 23:25:08 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: Proposed cleanup of index-related planner estimation procedures
Date: Wed, 05 Jan 2000 23:25:08 -0500
Message-ID: <20065.947132708@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
I am thinking about redefining and simplifying the planner's interface
to index-type-dependent estimation routines.
Currently, each defined index type is supposed to supply two routines:
an "amopselect" routine and an "amopnpages" routine. (The existing
actual routines of this kind are btreesel, btreenpages, etc in
src/backend/utils/adt/selfuncs.c.) These things are called by
index_selectivity() in src/backend/optimizer/util/plancat.c. amopselect
tries to determine the selectivity of an indexqual (the fraction of
main-table tuples it will select) and amopnpages tries to determine
the number of index pages that will be read to do it.
Now, this collection of code is largely redundant with
optimizer/path/clausesel.c, which also tries to estimate the selectivity
of qualification conditions. Furthermore, the interface to these
routines is fundamentally misdesigned, because there is no way to deal
with interrelated qualification conditions --- for example, if we have
a range query like "... WHERE x > 10 AND x < 20", the code estimates
the selectivity as the product of the selectivities of the two terms
independently, but the actual selectivity is very different from that.
I am working on fixing clausesel.c to be smarter about correlated
conditions, but it won't do much good to fix that code without fixing
the index-related code.
What I'm thinking about doing is replacing these two per-index-type
routines with a single routine, which is called once per proposed
indexscan rather than once per qual clause. It would receive the
whole indexqual list as a parameter, instead of just one qual.
A typical implementation would just call clausesel.c's general-purpose
code to estimate the selectivity, and then do a little bit of extra
work to derive the estimated number of index pages from that number.
I suppose the original reason for having amopselect at all was to allow
exploitation of index-specific knowledge during selectivity estimation
--- but none of the existing index types actually provide any such
knowledge in their amopselect routines. Still, this redesign preserves
the flexibility for an index type to do something specialized.A possible objection to this scheme is that the inputs and outputs
of these routines would be structs that aren't full-fledged SQL types
(and no, I'm not willing to promote parser expression trees into an
SQL type ;-)). But I don't think that's a real problem. No one is
going to be inventing new index types without doing a lot of C coding,
so having to write the amopselect routines in C doesn't seem like a
big drawback.
Comments, objections, better ideas?
regards, tom lane
From bouncefilter Thu Jan 6 00:09:23 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA43631
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 00:08:42 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id BAA90402
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 01:08:44 -0400 (AST)
(envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 6 Jan 2000 01:08:44 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: UdmSearch: tables vs indices ...
Message-ID: <Pine.BSF.4.21.0001060105030.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
We've almost got UdmSearch up and running, and I'm noticing something odd:
-rw------- 1 pgsql pgsql 204800 Jan 6 00:05 url
-rw------- 1 pgsql pgsql 1622016 Jan 6 00:05 word_url
url is:
CREATE TABLE "url" (
"rec_id" int4 DEFAULT nextval('next_url_id') PRIMARY KEY,
"status" int4 NOT NULL DEFAULT 0,
"url" character varying(128) NOT NULL,
"content_type" character varying(32) NOT NULL DEFAULT '',
"last_modified" character varying(32) NOT NULL DEFAULT '',
"title" character varying(128) NOT NULL DEFAULT '',
"text" character varying(255) NOT NULL DEFAULT '',
"size" int4 NOT NULL DEFAULT 0,
"indexed" int4 NOT NULL DEFAULT 0,
"last_index_time" datetime NOT NULL DEFAULT 'Thu Dec 31 20:00:00 1970 GMT',
"next_index_time" datetime NOT NULL DEFAULT 'Thu Dec 31 20:00:00 1970 GMT',
"referrer" int4 NOT NULL DEFAULT 0,
"tag" int4 NOT NULL DEFAULT 0,
"hops" int4 NOT NULL DEFAULT 0,
"keywords" character varying(255) NOT NULL DEFAULT '',
"description" character varying(100) NOT NULL DEFAULT '',
"crc" character varying(33) NOT NULL DEFAULT '');
and word_url is:
CREATE INDEX "word_url" on "dict" using btree ( "word" "varchar_ops", "url_id" "int4_ops" );
=============
is it just me, or does an index ~6x the size of the data itself look
"odd"?
Its an older v6.5.0 database (haven't had time to upgrade *sigh*), so if
explains it, so be it...I'll do an upgrade ASAP...but if that doesn't?
Thanks...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Thu Jan 6 00:25:23 2000
Received: from corvette.mascari.com (dhcp26131045.columbus.rr.com
[24.26.131.45]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA45769
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 00:25:05 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.9.3/8.9.3) with ESMTP id UAA00892;
Wed, 5 Jan 2000 20:25:10 -0500
Message-ID: <387426D4.6CA9E3B7@mascari.com>
Date: Thu, 06 Jan 2000 00:23:32 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] UdmSearch: tables vs indices ...
References: <Pine.BSF.4.21.0001060105030.18498-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The Hermit Hacker wrote:
We've almost got UdmSearch up and running, and I'm noticing something odd:
-rw------- 1 pgsql pgsql 204800 Jan 6 00:05 url
-rw------- 1 pgsql pgsql 1622016 Jan 6 00:05 word_urlurl is:
CREATE TABLE "url" (
"rec_id" int4 DEFAULT nextval('next_url_id') PRIMARY KEY,
"status" int4 NOT NULL DEFAULT 0,
"url" character varying(128) NOT NULL,
"content_type" character varying(32) NOT NULL DEFAULT '',
"last_modified" character varying(32) NOT NULL DEFAULT '',
"title" character varying(128) NOT NULL DEFAULT '',
"text" character varying(255) NOT NULL DEFAULT '',
"size" int4 NOT NULL DEFAULT 0,
"indexed" int4 NOT NULL DEFAULT 0,
"last_index_time" datetime NOT NULL DEFAULT 'Thu Dec 31 20:00:00 1970 GMT',
"next_index_time" datetime NOT NULL DEFAULT 'Thu Dec 31 20:00:00 1970 GMT',
"referrer" int4 NOT NULL DEFAULT 0,
"tag" int4 NOT NULL DEFAULT 0,
"hops" int4 NOT NULL DEFAULT 0,
"keywords" character varying(255) NOT NULL DEFAULT '',
"description" character varying(100) NOT NULL DEFAULT '',
"crc" character varying(33) NOT NULL DEFAULT '');and word_url is:
CREATE INDEX "word_url" on "dict" using btree ( "word" "varchar_ops", "url_id" "int4_ops" );
=============
is it just me, or does an index ~6x the size of the data itself look
"odd"?Its an older v6.5.0 database (haven't had time to upgrade *sigh*), so if
explains it, so be it...I'll do an upgrade ASAP...but if that doesn't?Thanks...
According to your CREATE INDEX statement, word_url is on the
table dict, not url. Is dict a large dictionary of some sort?
Mike
From bouncefilter Thu Jan 6 00:32:23 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA50649
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 00:31:30 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id BAA90496;
Thu, 6 Jan 2000 01:31:27 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 6 Jan 2000 01:31:27 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Mike Mascari <mascarm@mascari.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] UdmSearch: tables vs indices ...
In-Reply-To: <387426D4.6CA9E3B7@mascari.com>
Message-ID: <Pine.BSF.4.21.0001060130340.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 6 Jan 2000, Mike Mascari wrote:
According to your CREATE INDEX statement, word_url is on the
table dict, not url. Is dict a large dictionary of some sort?
Damn...ya, thanks for pointing what should have been obvious :( dict is
~10Meg and growing, word_url is now 7meg *sigh*
okay...ignore that one :(
From bouncefilter Thu Jan 6 01:53:24 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA66568
for <hackers@postgresql.org>; Thu, 6 Jan 2000 01:52:24 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id HAA20937
for <hackers@postgresql.org>; Thu, 6 Jan 2000 07:01:01 GMT
Sender: lockhart@hub.org
Message-ID: <38743DAD.6A651D27@alumni.caltech.edu>
Date: Thu, 06 Jan 2000 07:01:01 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgresql.org>
Subject: Regression tests
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
OK, I've updated most of the regression tests to match the new psql
output conventions. Several of the tests at the end, starting with
"join", currently fail on my test setup, but that is probably because
I've got a few changes in for "outer join syntax" which are not
sufficient to avoid crashes. It might be good for someone to run the
regression test and hand-inspect the tests which fail to verify that
it is just a formatting difference and not the "backend closed
connection" I'm seeing here.
Once I've got a bit more code done, I'll come back to the regression
tests. If someone wants to finish up the regression test updates, then
the only thing remaining is to do the following:
1) run the regression test (hey, that "parallel testing" looks
interesting btw; thanks Jan!)
2) cd results
3) For each of the failed tests at the end,
diff -w <testfile.out> ../expected/ | less
(if differences are not in the query results)
cp -p <testfile.out> ../expected/
3') There may be one or two "expected" files coming from ../output/;
it isn't that complicated to get those updated, involving copying the
results file to ../output/ and then modifying the file path names.
4) Commit the changed "expected" files to CVS
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Jan 6 05:05:36 2000
Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net
[194.217.242.39]) by hub.org (8.9.3/8.9.3) with ESMTP id FAA11065
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 05:05:09 -0500 (EST)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1)
id 1269mx-000H2j-0B; Thu, 6 Jan 2000 10:05:03 +0000
Received: from exchange1.nt.maidstone.gov.uk (exchange1.nt.maidstone.gov.uk
[172.16.0.150])
by gatekeeper.maidstone.gov.uk (8.9.3/8.9.3) with ESMTP id KAA11515;
Thu, 6 Jan 2000 10:53:19 GMT
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <CNA8Q4AQ>; Thu, 6 Jan 2000 10:04:46 -0000
Message-ID:
<1B3D5E532D18D311861A00600865478C70C03C@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'The Hermit Hacker'" <scrappy@hub.org>, Bruce Momjian
<pgman@candle.pha.pa.us>
Cc: Jan Wieck <wieck@debis.com>, Hannu Krosing <hannu@tm.ee>,
Thomas Lockhart <lockhart@alumni.caltech.edu>, PostgreSQL-development
<pgsql-hackers@postgresql.org>
Subject: RE: [HACKERS] Source code format vote
Date: Thu, 6 Jan 2000 10:04:45 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
I've got no problems with spaces being used rather than the tab
character either.
Peter
--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.
-----Original Message-----
From: The Hermit Hacker [mailto:scrappy@hub.org]
Sent: Tuesday, January 04, 2000 12:21 AM
To: Bruce Momjian
Cc: Jan Wieck; Hannu Krosing; Thomas Lockhart; PostgreSQL-development
Subject: Re: [HACKERS] Source code format vote
I'm for no-tabs personally ...
On Mon, 3 Jan 2000, Bruce Momjian wrote:
Hannu Krosing wrote:
Tom Lane wrote:
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
Was "spaces instead of tabs" one of the voted-on options? That
would
make the tab issue moot, and would result in consistant
appearance not
matter what tab setting one is using.
I'd be willing to vote for this if the space penalty is not
large...
Me too!
Count me in.
Do I need to tabluate a vote on this too?
I have to get all new votes from everyone on:
8-space tabs
no tabsIndentaion is still 4-spaces.
I prefer the 8-space tabs to no tabs. Seems like 8-space tabs won
over
4-space tabs, so we need a vote on 8-space tabs vs. no tabs.
I will need new votes because I have not kept any of the old messages.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania
19026
************
Marc G. Fournier ICQ#7615664 IRC Nick:
Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary:
scrappy@{freebsd|postgresql}.org
************
From bouncefilter Thu Jan 6 06:08:27 2000
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA24187
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 06:07:59 -0500 (EST)
(envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA03826;
Thu, 6 Jan 2000 11:52:55 +0100
Date: Thu, 6 Jan 2000 11:52:55 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>
cc: "'pgsql-hackers '" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] ordinal decimal number
In-Reply-To: <1BF7C7482189D211B03F00805F8527F748C3DF@S-NATH-EXCH2>
Message-ID: <Pine.LNX.3.96.1000106114524.3280A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 5 Jan 2000, Ansley, Michael wrote:
My personal opinion: ordinal numbers can get a th, rd, nd, or st. That
implies whole numbers only. If an ordinal is requested, test for a positive
integer; if not an integer, leave alone, otherwise add whichever suffix is
required.2 -> 2nd
2.2 -> 2.2
NaN -> NaN
4 -> 4th
-6 -> -6
Well, it is good solution. I implement it. Or exist the other suggestion?
Karel
From bouncefilter Thu Jan 6 06:06:27 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id GAA24006
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 06:06:05 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 5817 invoked by uid 1001); 6 Jan 2000 11:06:01 -0000
Date: Thu, 6 Jan 2000 06:06:01 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] UdmSearch: tables vs indices ...
In-Reply-To: <Pine.BSF.4.21.0001060105030.18498-100000@thelab.hub.org>
Message-ID: <Pine.BSF.4.05.10001060604280.5766-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 6 Jan 2000, The Hermit Hacker wrote:
We've almost got UdmSearch up and running, and I'm noticing something odd:
-rw------- 1 pgsql pgsql 204800 Jan 6 00:05 url
-rw------- 1 pgsql pgsql 1622016 Jan 6 00:05 word_url
Here's what I have on the test system I'm working with. The apache
docs are the only thing in it (or that should be in it).
-rw------- 1 postgres postgres 1671168 Dec 15 08:35 url
-rw------- 1 postgres postgres 278528 Dec 15 08:35 url_crc
-rw------- 1 postgres postgres 106496 Dec 15 08:35 url_pkey
-rw------- 1 postgres postgres 335872 Dec 15 08:35 url_url
-rw------- 1 postgres postgres 1179648 Dec 15 08:35 word_url
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
From bouncefilter Thu Jan 6 07:50:28 2000
Received: from shiela.querix.co.uk (sheila.querix.co.uk [212.158.91.227])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA43133
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 07:49:28 -0500 (EST)
(envelope-from rod@querix.com)
Received: from localhost (rod@localhost)
by shiela.querix.co.uk (8.9.3/8.8.7) with ESMTP id MAA22501
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 12:49:36 GMT
Date: Thu, 6 Jan 2000 12:49:36 +0000 (GMT)
From: Rod Chamberlin <rod@querix.com>
X-Sender: rod@shiela.querix.co.uk
To: pgsql-hackers@postgresql.org
Subject: Enhancing PGSQL to be compatible with Informix SQL
Message-ID: <Pine.LNX.4.10.10001061220560.14942-100000@shiela.querix.co.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I am currently looking into the possibility of extending the current
postgres SQL implementation to be compatible with Informix's SQL
implementation.
The changes required seem relatively straightforward, with one notable
exception.
Requirements:
1/ Datetime type specifiers (should have no impact)
o informix uses datetime specifiers of the form
DATETIME YEAR TO HOUR. (which is just the year,
month, day and hour portion of a datetime).
2/ Interval type specifiers (ditto)
o informix uses interval specifiers of the form
INTERVAL DAY TO HOUR. (which is just the
day and hour portion of an interval).
3/ Money type specifiers
o informix has money type specifiers that are akin
to decimal speicifiers
4/ Informix outer join syntax
o informix uses outer joins of the form
SELECT * FROM a, outer b where a.nr = b.nr
This will require some post-processing to determine
the actual join conditions.
5/ serial data type
o Serial type must return inserted key value
o Unfortunately (and this is the big bad hit)
informix's serial datatype does serial number
generation on a zero inserted valued.
The modification required to do this may have
impact on existing programs.
I'd be interested if anyone can see any conceptual difficulties i've
missed in these definitions, and welcome any concepts on the
implementation.
.............................Rod
+-----------------------------------------------------------------------------+
| Rod Chamberlin | rod@querix.com Tel +44 1703 232345 |
| Software Engineer | Mob +44 7803 295406 |
| QueriX | Fax +44 1703 399685 |
+-----------------------------------------------------------------------------+
| The views expressed in this document do not necessarily represent those of |
| the management of QueriX (UK) Ltd. |
+-----------------------------------------------------------------------------+From bouncefilter Thu Jan 6 08:15:29 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA50672
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 08:14:57 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id JAA92994;
Thu, 6 Jan 2000 09:15:11 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 6 Jan 2000 09:15:11 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Vince Vielhaber <vev@michvhf.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] UdmSearch: tables vs indices ...
In-Reply-To: <Pine.BSF.4.05.10001060604280.5766-100000@paprika.michvhf.com>
Message-ID: <Pine.BSF.4.21.0001060908050.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 6 Jan 2000, Vince Vielhaber wrote:
On Thu, 6 Jan 2000, The Hermit Hacker wrote:
We've almost got UdmSearch up and running, and I'm noticing something odd:
-rw------- 1 pgsql pgsql 204800 Jan 6 00:05 url
-rw------- 1 pgsql pgsql 1622016 Jan 6 00:05 word_urlHere's what I have on the test system I'm working with. The apache
docs are the only thing in it (or that should be in it).-rw------- 1 postgres postgres 1671168 Dec 15 08:35 url
-rw------- 1 postgres postgres 278528 Dec 15 08:35 url_crc
-rw------- 1 postgres postgres 106496 Dec 15 08:35 url_pkey
-rw------- 1 postgres postgres 335872 Dec 15 08:35 url_url
-rw------- 1 postgres postgres 1179648 Dec 15 08:35 word_url
Here is *just* http://www.postgresql.org/docs:
-rw------- 1 pgsql pgsql 3039232 Jan 6 06:02 url
-rw------- 1 pgsql pgsql 35602432 Jan 6 06:02 dict
-rw------- 1 pgsql pgsql 303104 Jan 6 06:02 url_pkey
-rw------- 1 pgsql pgsql 376832 Jan 6 06:02 url_crc
-rw------- 1 pgsql pgsql 1294336 Jan 6 06:02 url_url
-rw------- 1 pgsql pgsql 27385856 Jan 6 06:02 word_url
-rw------- 1 pgsql pgsql 8192 Jan 6 06:01 next_url_id
They are generating what I think is a very very weird looking query on the
tables that appears to be just hanging the whole thing...can someone
explain to me what *this* would do:
sum(case dict.word when '$t' then 1 else 0 end)
I'm trying to get more details out of Alexander, since I'm guessing that
the query itself could possibly be done cleaner, but they acknowledge that
their PostgreSQL knowledge tends to be rather "sparse", at best :)
More as it becomes available ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Thu Jan 6 09:40:31 2000
Received: from www.geocrawler.com (sourceforge.net [209.81.8.17])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA68569
for <pgsql-hackers@hub.org>; Thu, 6 Jan 2000 09:40:07 -0500 (EST)
(envelope-from nobody@www.geocrawler.com)
Received: (from nobody@localhost)
by www.geocrawler.com (8.9.3/8.9.3) id GAA30525;
Thu, 6 Jan 2000 06:40:07 -0800
Date: Thu, 6 Jan 2000 06:40:07 -0800
Message-Id: <200001061440.GAA30525@www.geocrawler.com>
To: pgsql-hackers@hub.org
Subject: btree: failed to add item to
From: "Adam Walczykiewicz" <archiver@db.geocrawler.com>
Reply-To: "Adam Walczykiewicz" <adam.walczykiewicz@multiuser.com.pl>
This message was sent from Geocrawler.com by "Adam Walczykiewicz" <adam.walczykiewicz@multiuser.com.pl>
Be sure to reply to that address.
Hi!
I've tried to create function in plpgsql in
postgresql 6.5 (on Linux Suse 6.2).
: i file.pl
In response I got on the screen an error message :
"gReadData()-- backend closed the channel
unexpectadly..."
I was back in shell.
In /var/lib/pgsql/pgserver.log I saw :
FATAL1 : btree: failed to add item to the page
The next thing I did was to cut some last 3 lines
(those beginning with substr(...))
And I run again
: i file.pl
In response I got again on the screen an error
message :
"gReadData()-- backend closed the channel
unexpectadly..."
I was back in shell.
In /var/lib/pgsql/pgserver.log I saw :
FATAL1 : my bits moved right off to the end of
the world!
After all of it I cut some more lines (I thougt
that the function was
to long to write it down in pg_proc).
And execute once again:
: i file.pl
and it works.
Next I add some more lines and start again to
create this function and
it failed again with the same effects.
Why it hapenned?? What can I do to solve that
problem.
Thanks for any help!!!!
Regards
Adam Walczykiewicz
(adam.walczykiewicz@multiuser.com.pl)
(file.pl)
drop function insklient(text);
create function insklient(text) returns text as '
declare
kl_wa klient.wa%TYPE;
kl_typk klient.typk%TYPE;
kl_czas_od_ob klient.czas_od_ob%TYPE;
kl_plec klient.plec%TYPE;
kl_nazwisko klient.nazwisko%TYPE;
kl_imie klient.imie%TYPE;
kl_imied klient.imied%TYPE;
kl_pesel klient.pesel%TYPE;
kl_nip klient.nip%TYPE;
kl_i_ojca klient.i_ojca%TYPE;
kl_nazwisko_r klient.nazwisko_r%TYPE;
kl_data_ur klient.data_ur%TYPE;
kl_tel_dom klient.tel_dom%TYPE;
kl_kod_p klient.kod_p%TYPE;
kl_miasto klient.miasto%TYPE;
kl_ulica klient.ulica%TYPE;
kl_kr_tel klient.kr_tel%TYPE;
kl_kr_kod_p klient.kr_kod_p%TYPE;
kl_kr_miasto klient.kr_miasto%TYPE;
kl_kr_ulica klient.kr_ulica%TYPE;
kl_tel_pr klient.tel_pr%TYPE;
kl_nzprac klient.nzprac%TYPE;
kl_zp_kod klient.zp_kod_p%TYPE;
kl_zp_miasto klient.zp_miasto%TYPE;
kl_zp_ulica klient.zp_ulica%TYPE;
kl_uwagi1 klient.uwagi1%TYPE;
kl_uwagi2 klient.uwagi2%TYPE;
str text;
kl_serial int4;
begin
--str := $1;
kl_wa := substr(str,1,textpos(str,'','')-
1);
str := substr(str,textpos(str,'','')+1);
kl_typk := substr(str,1,textpos
(str,'','')-1);
str := substr(str,textpos(str,'','')+1);
kl_czas_od_ob := substr(str,1,textpos
(str,'','')-1);
str := substr(str,textpos(str,'','')+1);
kl_plec := substr(str,1,textpos
(str,'','')-1);
str := substr(str,textpos(str,'','')+1);
kl_nazwisko := substr(str,1,textpos
(str,'','')-1);
str := substr(str,textpos(str,'','')+1);
kl_imie := substr(str,1,textpos
(str,'','')-1);
str := substr(str,textpos(str,'','')+1);
kl_imied := substr(str,1,textpos
(str,'','')-1);
str := substr(str,textpos(str,'','')+1);
kl_pesel := substr(str,1,textpos
(str,'','')-1);
str := substr(str,textpos(str,'','')+1);
kl_nip := substr(str,1,textpos(str,'','')-
1);
str := substr(str,textpos(str,'','')+1);
kl_i_ojca := substr(str,1,textpos
(str,'','')-1);
str := substr(str,textpos(str,'','')+1);
kl_nazwisko_r := substr(str,1,textpos
(str,'','')-1);
str := substr(str,textpos(str,'','')+1);
kl_data_ur := substr(str,1,textpos
(str,'','')-1);
str := substr(str,textpos(str,'','')+1);
kl_tel_dom := substr(str,1,textpos
(str,'','')-1);
str := substr(str,textpos(str,'','')+1);
kl_kod_p := substr(str,1,textpos
(str,'','')-1);
str := substr(str,textpos(str,'','')+1);
kl_miasto := substr(str,1,textpos
(str,'','')-1);
str := substr(str,textpos(str,'','')+1);
kl_ulica := substr(str,1,textpos
(str,'','')-1);
str := substr(str,textpos(str,'','')+1);
kl_kr_tel := substr(str,1,textpos
(str,'','')-1);
str := substr(str,textpos(str,'','')-1);
str := substr(str,textpos(str,'','')-1);
kl_kr_miasto := substr(str,1,texpos
(str,'','')-1);
str := substr(str,textpos(str,'','')-1);
kl_kr_ulica := substr(str,1,textpos
(str,'','')-1);
kl_tel_pr := substr(str,1,textpos
(str,'','')-1);
return ''rrrr'';
end;
' language 'plpgsql';
After executing that file (so similar to file.1
but shorter) the function
was created without any errors. I did it again
and it works.
(file2.pl)
-- wywolanie select ia('W^45^34');
drop function insdokument(text);
CREATE FUNCTION insdokument(text) RETURNS int4
AS '
DECLARE
dok_wa dokument.wa%TYPE;
dok_nrk dokument.nrk%TYPE;
dok_rodzaj dokument.rodzaj%TYPE;
dok_seria dokument.seria%TYPE;
dok_numer dokument.numer%TYPE;
dok_uwagi1 dokument.uwagi1%TYPE;
dok_uwagi2 dokument.uwagi2%TYPE;
str text;
dok_serial int4;
begin
str := $1;
dok_wa := substr(str,1,textpos(str,''^'')-
1);
str := substr(str,textpos(str,''^'')+1);
dok_nrk := substr(str,1,textpos
(str,''^'')-1);
str := substr(str,textpos(str,''^'')+1);
dok_rodzaj := substr(str,1,textpos
(str,''^'')-1);
str := substr(str,textpos(str,''^'')+1);
dok_seria := substr(str,1,textpos
(str,''^'')-1);
str := substr(str,textpos(str,''^'')+1);
dok_numer := substr(str,1,textpos
(str,''^'')-1);
str := substr(str,textpos(str,''^'')+1);
dok_uwagi1 := substr(str,1,textpos
(str,''^'')-1);
str := substr(str,textpos(str,''^'')+1);
dok_uwagi2 := substr(str,1,textpos
(str,''^'')-1);
str := substr(str,textpos(str,''^'')+1);
insert into dokument
(wa,nrk,rodzaj,seria,numer,uwagi1,uwagi2) values
(dok_wa,dok_nrk,dok_rodzaj,dok_seria,dok_numer,dok
_uwagi1,dok_uwagi2);
select last_value into dok_serial from
dokument_nr_seq;
return dok_serial;
end;
' language 'plpgsql';
Geocrawler.com - The Knowledge Archive
From bouncefilter Thu Jan 6 10:10:31 2000
Received: from shiela.querix.co.uk (sheila.querix.co.uk [212.158.91.227])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA77502
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 10:09:35 -0500 (EST)
(envelope-from rod@querix.com)
Received: from localhost (rod@localhost)
by shiela.querix.co.uk (8.9.3/8.8.7) with ESMTP id PAA23828;
Thu, 6 Jan 2000 15:09:02 GMT
Date: Thu, 6 Jan 2000 15:09:02 +0000 (GMT)
From: Rod Chamberlin <rod@querix.com>
X-Sender: rod@shiela.querix.co.uk
To: Don Baccus <dhogaza@pacifier.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
In-Reply-To: <3.0.1.32.20000106092353.00ee115c@mail.pacifier.com>
Message-ID: <Pine.LNX.4.10.10001061450170.14942-100000@shiela.querix.co.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 6 Jan 2000, Don Baccus wrote:
At 12:49 PM 1/6/00 +0000, Rod Chamberlin wrote:
4/ Informix outer join syntax
o informix uses outer joins of the form
SELECT * FROM a, outer b where a.nr = b.nr
This will require some post-processing to determine
the actual join conditions.Rather than go blow-by-blow, why should Postgres adopt (say) Informix
syntax vs. Sybase or Oracle?If Postgres were to adopt a non-standard syntax for a feature like outer
joins, wouldn't it make more sense to pick the syntax used by the market
leader (Oracle), simply because it would make porting easier for a much
larger group of database users?Of course, my REAL feeling is that supporting SQL 92 outer join syntax - which
is the approach being taken by the developers - is the right answer.And, of course, that Oracle, Informix and the rest ought to get off their
collective asses and support SQL 92. After all, they undoubtably contributed
to the development of those standards - I can't believe they didn't fund
representatives to the committees.But if one were to want to mimic a commercial DB, one would presumably
mimic the market leader...
Actually what I'm proposing is more to support mutiple database syntaxes
wherever possible. The INFORMIX style of outer join (and for that matter
the oracle style), are not gramatically exclusive. There is no reason why
you should not allow *all* sane outer join syntaxes, apart from the added
complexity in the parser.
The same is true largely for the other changes I suggested. They are for
portability with other systems to attempt to minimise the amount of work
necessary to migrate a given application.
Why is this interesting for Informix? Two reasons I can list
offhand:
1/ Informix is currently deserting it's customer base of small
business users, instead trying to concetrate on larger organisations.
There are therefore vasts numbers of users crying out for something to
fill that gap. This I will admit provides a commercial basis for any such
attempt, since we have already got some of the other tools which
informix users will be interested in.
2/ The datatypes already tie in much more closely in informix than
they do in oracle (I can't speak for any of the other major
databases, I haven't actually looked at the type comparisons). Actually
trying creating a useable sensible level of compatability with oracle
would take considerably more work than doing the same for informix.
.............................Rod
+-----------------------------------------------------------------------------+
| Rod Chamberlin | rod@querix.com Tel +44 1703 232345 |
| Software Engineer | Mob +44 7803 295406 |
| QueriX | Fax +44 1703 399685 |
+-----------------------------------------------------------------------------+
| The views expressed in this document do not necessarily represent those of |
| the management of QueriX (UK) Ltd. |
+-----------------------------------------------------------------------------+From bouncefilter Thu Jan 6 10:50:30 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id KAA87062
for <pgsql-hackers@hub.org>; Thu, 6 Jan 2000 10:50:16 -0500 (EST)
(envelope-from wieck@debis.com)
Received: from debis.com by orion.SAPserv.Hamburg.dsh.de with smtp
for <pgsql-hackers@hub.org>
id m126F1a-0003kGC; Thu, 6 Jan 100 16:40 MET
Sender: wieck
Message-ID: <3874B76E.CAF80AA8@debis.com>
Date: Thu, 06 Jan 2000 16:40:30 +0100
From: Jan Wieck <wieck@debis.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.9 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Adam Walczykiewicz <adam.walczykiewicz@multiuser.com.pl>
CC: pgsql-hackers@hub.org
Subject: Re: [HACKERS] btree: failed to add item to
References: <200001061440.GAA30525@www.geocrawler.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Adam Walczykiewicz wrote:
Hi!
I've tried to create function in plpgsql in
[...]
FATAL1 : my bits moved right off to the end of
the world!
After all of it I cut some more lines (I thougt
that the function was
to long to write it down in pg_proc).
And execute once again:
: i file.pl
and it works.
Surely you ran into the pg_proc_prosrc_index problem with it.
This is fixed in the CURRENT tree. I've placed the patch against v6.5.2 onto the FTP server now.
Grab it from
ftp://ftp.postgresql.org/pub/patches/v6.5/
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Thu Jan 6 10:52:31 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA87263
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 10:51:39 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA21239;
Thu, 6 Jan 2000 10:50:27 -0500 (EST)
To: Rod Chamberlin <rod@querix.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
In-reply-to: <Pine.LNX.4.10.10001061220560.14942-100000@shiela.querix.co.uk>
References: <Pine.LNX.4.10.10001061220560.14942-100000@shiela.querix.co.uk>
Comments: In-reply-to Rod Chamberlin <rod@querix.com>
message dated "Thu, 06 Jan 2000 12:49:36 +0000"
Date: Thu, 06 Jan 2000 10:50:27 -0500
Message-ID: <21236.947173827@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Rod Chamberlin <rod@querix.com> writes:
I am currently looking into the possibility of extending the current
postgres SQL implementation to be compatible with Informix's SQL
implementation.
Don Baccus already made the point that we are more interested in being
compatible with the standard than with specific commercial
implementations, so I won't repeat it. I do have a couple of practical
suggestions though:
1/ Datetime type specifiers (should have no impact)
2/ Interval type specifiers (ditto)
We support enough datestyle variants already that it's hard to believe
there isn't one that will meet your needs. But if not, I think adding
an "Informix" datestyle option might be considered reasonable.
5/ serial data type
o Serial type must return inserted key value
o Unfortunately (and this is the big bad hit)
informix's serial datatype does serial number
generation on a zero inserted valued.
The modification required to do this may have
impact on existing programs.
Breaking existing applications will not fly. If you have lots of
code that depends on this behavior, you could easily emulate it
by adding a BEFORE INSERT trigger on each table that needs it.
Ignoring the boilerplate, the critical bit would look like:
if new.serialcolumn = 0 then
new.serialcolumn = nextval('sequenceobject');
However, if you need to know what value is being given to the
inserted tuple, much the cleanest solution is to select nextval
before inserting:
SELECT nextval('sequenceobject');
INSERT INTO table VALUES(... , value-you-just-got, ...);
If you are always going to do that, then a trigger is a waste of cycles.
regards, tom lane
From bouncefilter Thu Jan 6 10:53:30 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA87404
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 10:52:39 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA21277;
Thu, 6 Jan 2000 10:52:32 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: Vince Vielhaber <vev@michvhf.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] UdmSearch: tables vs indices ...
In-reply-to: <Pine.BSF.4.21.0001060908050.18498-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0001060908050.18498-100000@thelab.hub.org>
Comments: In-reply-to The Hermit Hacker <scrappy@hub.org>
message dated "Thu, 06 Jan 2000 09:15:11 -0400"
Date: Thu, 06 Jan 2000 10:52:32 -0500
Message-ID: <21273.947173952@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
explain to me what *this* would do:
sum(case dict.word when '$t' then 1 else 0 end)
Looks to me like it generates the same result as
select count(*) where dict.word = '$t';
regards, tom lane
From bouncefilter Thu Jan 6 10:58:32 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA88095;
Thu, 6 Jan 2000 10:57:51 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id LAA94308;
Thu, 6 Jan 2000 11:57:52 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 6 Jan 2000 11:57:52 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-announce@postgresql.org
cc: pgsql-hackers@postgresql.org, pgsql-general@postgresql.org
Subject: New Search Engine ... UdmSearch
Message-ID: <Pine.BSF.4.21.0001061154090.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Well, we've finally gotten what seems to be a working version of this
going, and, so far, I'm quite impressed...
If you go to http://www.postgresql.org/cgi/search.cgi (URL to change), you
can see it in action.
The WebMaster still has to do formatting work on it, and link it into the
main site, and the database is just being populated right now, and ...
... but its a start.
So far, from what i've seen, its a nice tool ... I like the fact that
there is no such thing as "Search downtime", since the indexer can run
while ppl are seaching. With ht/Dig, while it was indexing, the databases
were down and you couldn't search anything...
And, I think, its much faster then the old, but am not sure about that...
Oh well, give her a go, but expect changes over the next little while as
we integrate it better...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Thu Jan 6 11:08:31 2000
Received: from mail1.andrew.cmu.edu (MAIL1.ANDREW.CMU.EDU [128.2.10.131])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA93254
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 11:08:02 -0500 (EST)
(envelope-from geek+@cmu.edu)
Received: from export.andrew.cmu.edu (EXPORT.ANDREW.CMU.EDU [128.2.23.2])
by mail1.andrew.cmu.edu (8.9.3/8.9.3) with SMTP id LAA02902
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 11:08:01 -0500 (EST)
Date: 6 Jan 2000 11:08:00 -0500
Message-ID: <emacs-smtp-21101-14452-48608-822759@export.andrew.cmu.edu>
From: Brian E Gallew <geek+@cmu.edu>
X-Mailer: BatIMail version 3.2
To: pgsql-hackers@postgreSQL.org
In-reply-to: <3.0.1.32.20000106092353.00ee115c@mail.pacifier.com>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
References: <3.0.1.32.20000106092353.00ee115c@mail.pacifier.com>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: multipart/signed; protocol="application/pgp-signature";
boundary="pgp-sign-Multipart_Thu_Jan__6_11:08:00_2000-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit
--pgp-sign-Multipart_Thu_Jan__6_11:08:00_2000-1
Content-Type: text/plain; charset=US-ASCII
Then <dhogaza@pacifier.com> spoke up and said:
But if one were to want to mimic a commercial DB, one would presumably
mimic the market leader...
Market leader or not, Oracle causes us sufficient pain here that I
would never consider it important. But then again, I'm bitter.
--
=====================================================================
| JAVA must have been developed in the wilds of West Virginia. |
| After all, why else would it support only single inheritance?? |
=====================================================================
| Finger geek@cmu.edu for my public key. |
=====================================================================
--pgp-sign-Multipart_Thu_Jan__6_11:08:00_2000-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface
iQBVAwUBOHS94IdzVnzma+gdAQGndQIAv35EAxWLbtu1k32mJ11r7WbGggetJT9B
JD05q8/pM9jrDcdNQWB9s032mV+h/3NiDN7zpvfoqO65z0spUkaOlw==
=PBiV
-----END PGP MESSAGE-----
--pgp-sign-Multipart_Thu_Jan__6_11:08:00_2000-1--
From bouncefilter Thu Jan 6 11:10:31 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA93573
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 11:10:06 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA13338;
Thu, 6 Jan 2000 11:08:43 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001061608.LAA13338@candle.pha.pa.us>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
In-Reply-To: <Pine.LNX.4.10.10001061220560.14942-100000@shiela.querix.co.uk>
from Rod Chamberlin at "Jan 6, 2000 12:49:36 pm"
To: Rod Chamberlin <rod@querix.com>
Date: Thu, 6 Jan 2000 11:08:43 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I am currently looking into the possibility of extending the current
postgres SQL implementation to be compatible with Informix's SQL
implementation.The changes required seem relatively straightforward, with one notable
exception.
I am very familiar wit Informix.
Requirements:
1/ Datetime type specifiers (should have no impact)
o informix uses datetime specifiers of the form
DATETIME YEAR TO HOUR. (which is just the year,
month, day and hour portion of a datetime).
I have to admit I usually find this very confusing with Informix.
2/ Interval type specifiers (ditto)
o informix uses interval specifiers of the form
INTERVAL DAY TO HOUR. (which is just the
day and hour portion of an interval).
This I can usually understand, though I think we can do this too clearer
than Informix.
3/ Money type specifiers
o informix has money type specifiers that are akin
to decimal speicifiers
We have a MONEY type now, and are looking to invisibly use DECIMAL for
this instead.
4/ Informix outer join syntax
o informix uses outer joins of the form
SELECT * FROM a, outer b where a.nr = b.nr
This will require some post-processing to determine
the actual join conditions.
Believe it or not, I am hoping to get this into 7.0. The ANSI syntax
requires a lot of optimizer changes, because it basically allows user
specification of the join order. In talking to Thomas, we hoped to
implement OUTER as a flag on the table that we could easily implement in
7.0. Let's see how it goes.
5/ serial data type
o Serial type must return inserted key value
How does Informix return the value?
o Unfortunately (and this is the big bad hit)
informix's serial datatype does serial number
generation on a zero inserted valued.
The modification required to do this may have
impact on existing programs.
Yes, I have been thrown off by this. We don't allow a zero to
auto-number. You have to use nextval('sequence_name') in the query to
supply the sequence value, not a zero. I can see this as a pain, but
the developers think the 0 replace with nextval() thing is strange and
non-intuitive. The current behavior fits in the DEFAULT column
activation in a logical way. I don't think I can get people to make
this change. The 0 replacement is a behind the scenes thing, while
DEFAULT and nextval() calls are logically consistent.
I'd be interested if anyone can see any conceptual difficulties i've
missed in these definitions, and welcome any concepts on the
implementation.
I agree Informix compatibility is a good thing.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 6 11:32:31 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA98928
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 11:31:30 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA13385;
Thu, 6 Jan 2000 11:11:32 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001061611.LAA13385@candle.pha.pa.us>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
In-Reply-To: <21236.947173827@sss.pgh.pa.us> from Tom Lane at "Jan 6,
2000 10:50:27 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu, 6 Jan 2000 11:11:32 -0500 (EST)
CC: Rod Chamberlin <rod@querix.com>, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
However, if you need to know what value is being given to the
inserted tuple, much the cleanest solution is to select nextval
before inserting:SELECT nextval('sequenceobject');
INSERT INTO table VALUES(... , value-you-just-got, ...);If you are always going to do that, then a trigger is a waste of cycles.
He can do:
INSERT INTO table VALUES(... , nextval('sequenceobject'), ...);
and currval() will get him the previous nextval() value.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 6 11:21:35 2000
Received: from fep132.fep.ru (mail@fep132.fep.ru [195.230.89.88])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA96077;
Thu, 6 Jan 2000 11:20:50 -0500 (EST) (envelope-from phd@phd.russ.ru)
Received: from localhost [127.0.0.1] (phd)
by fep132.fep.ru with esmtp (Exim 2.05 #1 (Debian))
id 126FeN-0003wi-00; Thu, 6 Jan 2000 19:20:35 +0300
Date: Thu, 6 Jan 2000 16:20:35 +0000 (GMT)
From: Oleg Broytmann <phd@phd.russ.ru>
X-Sender: phd@fep132.fep.ru
Reply-To: phd2@earthling.net
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-announce@postgreSQL.org, pgsql-hackers@postgreSQL.org,
pgsql-general@postgreSQL.org
Subject: Re: [HACKERS] New Search Engine ... UdmSearch
In-Reply-To: <Pine.BSF.4.21.0001061154090.18498-100000@thelab.hub.org>
Message-ID: <Pine.LNX.4.21.0001061618450.15137-100000@fep132.fep.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 6 Jan 2000, The Hermit Hacker wrote:
So far, from what i've seen, its a nice tool ... I like the fact that
there is no such thing as "Search downtime", since the indexer can run
while ppl are seaching. With ht/Dig, while it was indexing, the databases
were down and you couldn't search anything...
You are certailnly wrong, as htDig has a concept of "work files" (option -a).
Oleg.
----
Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net
Programmers don't die, they just GOSUB without RETURN.
From bouncefilter Thu Jan 6 11:37:31 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA02349
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 11:36:38 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id MAA94666;
Thu, 6 Jan 2000 12:36:10 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 6 Jan 2000 12:36:10 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Rod Chamberlin <rod@querix.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
In-Reply-To: <21236.947173827@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0001061235450.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 6 Jan 2000, Tom Lane wrote:
1/ Datetime type specifiers (should have no impact)
2/ Interval type specifiers (ditto)We support enough datestyle variants already that it's hard to believe
there isn't one that will meet your needs. But if not, I think adding
an "Informix" datestyle option might be considered reasonable.
Isn't Thomas trying to reduce the number of variants?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Thu Jan 6 11:40:31 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA03140
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 11:40:08 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA21560;
Thu, 6 Jan 2000 11:40:03 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: Rod Chamberlin <rod@querix.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
In-reply-to: <Pine.BSF.4.21.0001061235450.18498-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0001061235450.18498-100000@thelab.hub.org>
Comments: In-reply-to The Hermit Hacker <scrappy@hub.org>
message dated "Thu, 06 Jan 2000 12:36:10 -0400"
Date: Thu, 06 Jan 2000 11:40:03 -0500
Message-ID: <21557.947176803@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
On Thu, 6 Jan 2000, Tom Lane wrote:
We support enough datestyle variants already that it's hard to believe
there isn't one that will meet your needs. But if not, I think adding
an "Informix" datestyle option might be considered reasonable.
Isn't Thomas trying to reduce the number of variants?
He wants to eliminate the essentially-duplicate datatypes, but I didn't
think he was proposing eliminating any datestyle functionality...
there would be squawks if he did, methinks...
regards, tom lane
From bouncefilter Thu Jan 6 11:43:32 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA03658;
Thu, 6 Jan 2000 11:42:37 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id MAA94719;
Thu, 6 Jan 2000 12:42:38 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 6 Jan 2000 12:42:37 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: phd2@earthling.net
cc: pgsql-announce@postgreSQL.org, pgsql-hackers@postgreSQL.org,
pgsql-general@postgreSQL.org
Subject: Re: [HACKERS] New Search Engine ... UdmSearch
In-Reply-To: <Pine.LNX.4.21.0001061618450.15137-100000@fep132.fep.ru>
Message-ID: <Pine.BSF.4.21.0001061241510.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 6 Jan 2000, Oleg Broytmann wrote:
On Thu, 6 Jan 2000, The Hermit Hacker wrote:
So far, from what i've seen, its a nice tool ... I like the fact that
there is no such thing as "Search downtime", since the indexer can run
while ppl are seaching. With ht/Dig, while it was indexing, the databases
were down and you couldn't search anything...You are certailnly wrong, as htDig has a concept of "work files"
(option -a).
Ah, okay...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Thu Jan 6 11:44:31 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA03923
for <pgsql-hackers@hub.org>; Thu, 6 Jan 2000 11:43:50 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA21594;
Thu, 6 Jan 2000 11:43:47 -0500 (EST)
To: "Adam Walczykiewicz" <adam.walczykiewicz@multiuser.com.pl>
cc: pgsql-hackers@hub.org
Subject: Re: [HACKERS] btree: failed to add item to
In-reply-to: <200001061440.GAA30525@www.geocrawler.com>
References: <200001061440.GAA30525@www.geocrawler.com>
Comments: In-reply-to "Adam Walczykiewicz" <archiver@db.geocrawler.com>
message dated "Thu, 06 Jan 2000 06:40:07 -0800"
Date: Thu, 06 Jan 2000 11:43:46 -0500
Message-ID: <21591.947177026@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Adam, I think you are running into the same problem with overly large
procedure definitions that's been discussed here recently. In 6.5.*
it's not safe to create a procedure def that's more than 2700 bytes.
Workaround: split your code into smaller functions.
7.0 will be better...
regards, tom lane
From bouncefilter Thu Jan 6 11:46:31 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA04346
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 11:46:11 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id MAA94777;
Thu, 6 Jan 2000 12:46:10 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 6 Jan 2000 12:46:10 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Rod Chamberlin <rod@querix.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
In-Reply-To: <21557.947176803@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0001061245260.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 6 Jan 2000, Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
On Thu, 6 Jan 2000, Tom Lane wrote:
We support enough datestyle variants already that it's hard to believe
there isn't one that will meet your needs. But if not, I think adding
an "Informix" datestyle option might be considered reasonable.Isn't Thomas trying to reduce the number of variants?
He wants to eliminate the essentially-duplicate datatypes, but I didn't
think he was proposing eliminating any datestyle functionality...
there would be squawks if he did, methinks...
'K, just wanted to clarify that point...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Thu Jan 6 11:48:32 2000
Received: from shiela.querix.co.uk (sheila.querix.co.uk [212.158.91.227])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA04734
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 11:47:57 -0500 (EST)
(envelope-from rod@querix.com)
Received: from localhost (rod@localhost)
by shiela.querix.co.uk (8.9.3/8.8.7) with ESMTP id QAA25665;
Thu, 6 Jan 2000 16:46:58 GMT
Date: Thu, 6 Jan 2000 16:46:58 +0000 (GMT)
From: Rod Chamberlin <rod@querix.com>
X-Sender: rod@shiela.querix.co.uk
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
In-Reply-To: <200001061611.LAA13385@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.10.10001061636460.14942-100000@shiela.querix.co.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 6 Jan 2000, Bruce Momjian wrote:
However, if you need to know what value is being given to the
inserted tuple, much the cleanest solution is to select nextval
before inserting:SELECT nextval('sequenceobject');
INSERT INTO table VALUES(... , value-you-just-got, ...);If you are always going to do that, then a trigger is a waste of cycles.
He can do:
INSERT INTO table VALUES(... , nextval('sequenceobject'), ...);
and currval() will get him the previous nextval() value.
The problem is unfortunately much more generic than this. I would like
able to take an informix/4GL program an run it without modification on a
postgres backend. The difficulty here is that the database interface
*does not know* the datatypes in the insert statement. The problem
actually becomes more tricky because the catalog tables don't even know
that the original datatype was a serial, so the interface layer cannot
take any special steps to pre-process the data.
The only other alternative is to write a secondary parser in the interface
layer which does the SQL conversion. This strikes me as an exceptionally
complex solution given the relative similarity between Informix/SQL and
Postgress SQL.
.............................Rod
+-----------------------------------------------------------------------------+
| Rod Chamberlin | rod@querix.com Tel +44 1703 232345 |
| Software Engineer | Mob +44 7803 295406 |
| QueriX | Fax +44 1703 399685 |
+-----------------------------------------------------------------------------+
| The views expressed in this document do not necessarily represent those of |
| the management of QueriX (UK) Ltd. |
+-----------------------------------------------------------------------------+From bouncefilter Thu Jan 6 12:10:32 2000
Received: from shiela.querix.co.uk (sheila.querix.co.uk [212.158.91.227])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA12481
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 12:09:43 -0500 (EST)
(envelope-from rod@querix.com)
Received: from localhost (rod@localhost)
by shiela.querix.co.uk (8.9.3/8.8.7) with ESMTP id RAA25846;
Thu, 6 Jan 2000 17:09:16 GMT
Date: Thu, 6 Jan 2000 17:09:16 +0000 (GMT)
From: Rod Chamberlin <rod@querix.com>
X-Sender: rod@shiela.querix.co.uk
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
In-Reply-To: <200001061608.LAA13338@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.10.10001061647090.14942-100000@shiela.querix.co.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 6 Jan 2000, Bruce Momjian wrote:
I am currently looking into the possibility of extending the current
postgres SQL implementation to be compatible with Informix's SQL
implementation.The changes required seem relatively straightforward, with one notable
exception.I am very familiar wit Informix.
Requirements:
1/ Datetime type specifiers (should have no impact)
o informix uses datetime specifiers of the form
DATETIME YEAR TO HOUR. (which is just the year,
month, day and hour portion of a datetime).I have to admit I usually find this very confusing with Informix.
I can't disagree. The way informix decided to do DATETIME stuff is
definately odd. That said, from a calcualtion standpoint you can pretty
much ignore the qualifier during calcualtions, its only really important
in the representation. (I'm actually making assumptions here, and it
produces considerable work at the representation stages, but that can
easily be accomodated).
2/ Interval type specifiers (ditto)
o informix uses interval specifiers of the form
INTERVAL DAY TO HOUR. (which is just the
day and hour portion of an interval).This I can usually understand, though I think we can do this too clearer
than Informix.3/ Money type specifiers
o informix has money type specifiers that are akin
to decimal speicifiersWe have a MONEY type now, and are looking to invisibly use DECIMAL for
this instead.
This would actually be sensible. My comment about money, is that the
existing type doesn't have a concept of precision; two decimal places of
money is somewhat meaningless where in the local currency it takes 1000
washers to buy a packet of crisps. The ability to set the precision of
the MONEY type is kinda important in this case.
4/ Informix outer join syntax
o informix uses outer joins of the form
SELECT * FROM a, outer b where a.nr = b.nr
This will require some post-processing to determine
the actual join conditions.Believe it or not, I am hoping to get this into 7.0. The ANSI syntax
requires a lot of optimizer changes, because it basically allows user
specification of the join order. In talking to Thomas, we hoped to
implement OUTER as a flag on the table that we could easily implement in
7.0. Let's see how it goes.
Sounds great! :)
5/ serial data type
o Serial type must return inserted key valueHow does Informix return the value?
From a user standpoint it mystically appears in sqlca just after the
insert statement is executed. Actually the informix engine recognises
it's just done a serial insert, and sends it back in addition to the
standard status packets.
o Unfortunately (and this is the big bad hit)
informix's serial datatype does serial number
generation on a zero inserted valued.
The modification required to do this may have
impact on existing programs.Yes, I have been thrown off by this. We don't allow a zero to
auto-number. You have to use nextval('sequence_name') in the query to
supply the sequence value, not a zero. I can see this as a pain, but
the developers think the 0 replace with nextval() thing is strange and
non-intuitive. The current behavior fits in the DEFAULT column
activation in a logical way. I don't think I can get people to make
this change. The 0 replacement is a behind the scenes thing, while
DEFAULT and nextval() calls are logically consistent.
I can understand the situation here (one of the main reasons I raised the
thread in the first place). Above all else the difficulty I have with
serial at the moment is the impossibility of differentiating a serial with
an int4 after creation (after all the database treats them identically).
The catalog tables don't contain any information. The only way you can
work out you created a serial column is by looking for an appropriately
named sequence in the database on every int4 column that exists (or am I
wrong?). This is not exactly something that appeals to me
Also, in order to get correct returns from the serial column insert it
seems likely that the serial type would have to gain some kind of extra
special processing within the database above what it has already. In this
case all of the required behaviour could probably be implemented.
I'd be interested if anyone can see any conceptual difficulties i've
missed in these definitions, and welcome any concepts on the
implementation.I agree Informix compatibility is a good thing.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
.............................Rod
+-----------------------------------------------------------------------------+
| Rod Chamberlin | rod@querix.com Tel +44 1703 232345 |
| Software Engineer | Mob +44 7803 295406 |
| QueriX | Fax +44 1703 399685 |
+-----------------------------------------------------------------------------+
| The views expressed in this document do not necessarily represent those of |
| the management of QueriX (UK) Ltd. |
+-----------------------------------------------------------------------------+From bouncefilter Thu Jan 6 09:13:30 2000
Received: from mx01.gis.net ([208.218.130.25])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA62361
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 09:13:09 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from laptop.pacifier.com (nas-45-223.boston.navinet.net
[216.67.45.223]) by mx01.gis.net (8.8.8/8.8.8+pyrd) with SMTP
id JAA16566; Thu, 6 Jan 2000 09:12:32 -0500 (EST)
Message-Id: <3.0.1.32.20000106092353.00ee115c@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 06 Jan 2000 09:23:53 -0800
To: Rod Chamberlin <rod@querix.com>, pgsql-hackers@postgreSQL.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix
SQL
In-Reply-To: <Pine.LNX.4.10.10001061220560.14942-100000@shiela.querix.co .uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 12:49 PM 1/6/00 +0000, Rod Chamberlin wrote:
4/ Informix outer join syntax
o informix uses outer joins of the form
SELECT * FROM a, outer b where a.nr = b.nr
This will require some post-processing to determine
the actual join conditions.
Rather than go blow-by-blow, why should Postgres adopt (say) Informix
syntax vs. Sybase or Oracle?
If Postgres were to adopt a non-standard syntax for a feature like outer
joins, wouldn't it make more sense to pick the syntax used by the market
leader (Oracle), simply because it would make porting easier for a much
larger group of database users?
Of course, my REAL feeling is that supporting SQL 92 outer join syntax - which
is the approach being taken by the developers - is the right answer.
And, of course, that Oracle, Informix and the rest ought to get off their
collective asses and support SQL 92. After all, they undoubtably contributed
to the development of those standards - I can't believe they didn't fund
representatives to the committees.
But if one were to want to mimic a commercial DB, one would presumably
mimic the market leader...
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Thu Jan 6 12:59:32 2000
Received: from postal.dn.net (postal.dn.net [207.153.221.107])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA23746
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 12:59:27 -0500 (EST)
(envelope-from frankpit@pop.dn.net)
Received: from pop.dn.net (pm-57.ppp.wdc.dn.net [207.226.188.57])
by postal.dn.net (102199-jg) with ESMTP id MAA29744;
Thu, 6 Jan 2000 12:59:23 -0500 (EST)
Sender: bernie@postal.dn.net
Message-ID: <3874D8D8.3534D782@pop.dn.net>
Date: Thu, 06 Jan 2000 13:03:04 -0500
From: Bernard Adrian Frankpitt <frankpit@pop.dn.net>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Proposed cleanup of index-related planner estimation
procedures
References: <20065.947132708@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
I am thinking about redefining and simplifying the planner's interface
to index-type-dependent estimation routines.
Good Idea. I looked at that code quite closely in the past year, and I
agree that, though harmless, much of it seems bogus --- or at least not
well motivated by thorough analysis. One reason for this is that the
problem of
computing index search costs is very difficult, the theoretical papers
that I could find on the subject are not terribly satisfactory.
Currently only equals operators for hash and linear comparison operators
for nbtree really implement anything, the other access method operator
classes merely copy the nbtree operator algorithms.
What I'm thinking about doing is replacing these two per-index-type
routines with a single routine, which is called once per proposed
indexscan rather than once per qual clause. It would receive the
whole indexqual list as a parameter, instead of just one qual.
A typical implementation would just call clausesel.c's general-purpose
code to estimate the selectivity, and then do a little bit of extra
work to derive the estimated number of index pages from that number.I suppose the original reason for having amopselect at all was to allow exploitation of index-specific knowledge during selectivity estimation --- but none of the existing index types actually provide any such knowledge in their amopselect routines. Still, this redesign preserves the flexibility for an index type to do something specialized.
Good, I have a special access method that needs to subvert the normal
optimizer in a way that ensures an index scan is used for every heap
access predicated on a particular attribute. The reason for this is
that the data (representations of cells in a partition of a high
dimensional space) that would normally sit in heap tuples are actually
distributed through the index structure. A query predicated on a
property of my special attributes needs to be executed with an index
scan, so I subvert the optimizer by coding amopselect and amopnpages to
always give zero cost for an index scan. Since index scans are always
considered first, this hairy hack works. I would certainly breath more
easily at each new release of PostgreSQl if the ability of the system to
support this type of hack were a recognized feature.
A possible objection to this scheme is that the inputs and outputs
of these routines would be structs that aren't full-fledged SQL types
(and no, I'm not willing to promote parser expression trees into an
SQL type ;-)). But I don't think that's a real problem. No one is
going to be inventing new index types without doing a lot of C coding,
Yes, a lot of C-code, I have 10K lines in my access method. What is
remarkable about Postgresql is that the interface between index access
methods and the rest of the system is so clean that this sort of project
is feasible.
so having to write the amopselect routines in C doesn't seem like a
big drawback.
One thing that I have on my `really cool ideas' list would be to link
somehing like a Python interpreter and compiler into the backend. one
would use the scripting language to write and debug stuff like this, and
then compile and dynamically link the debugged code into the backend.
What I ended up doing in my index scheme was to code all the
mathematical algorithms in MATLAB and get them working there, and then
hand translate the MATLAB code to C (there is a lot of linear algebra in
the algorithms). Debugging was a major pain. With my idea you could
write the whole access method in a high-level language, and the low
level backend interfaces to things like buffer locking, MVCC and
postgresql memory management would be encapsulated by interfaces in the
high-level language. If there were something like that in PostgreSQL I
bet a lot more people would be rolling their own access methods. I am
not sure that people who value stability over new features would see
this as a step in the right direction. ;-)
Comments, objections, better ideas?
regards, tom lane
************
From bouncefilter Thu Jan 6 13:13:32 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA31003
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 13:13:17 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA15830;
Thu, 6 Jan 2000 13:12:46 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001061812.NAA15830@candle.pha.pa.us>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
In-Reply-To: <Pine.LNX.4.10.10001061647090.14942-100000@shiela.querix.co.uk>
from Rod Chamberlin at "Jan 6, 2000 05:09:16 pm"
To: Rod Chamberlin <rod@querix.com>
Date: Thu, 6 Jan 2000 13:12:46 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I have to admit I usually find this very confusing with Informix.
I can't disagree. The way informix decided to do DATETIME stuff is
definately odd. That said, from a calcualtion standpoint you can pretty
much ignore the qualifier during calcualtions, its only really important
in the representation. (I'm actually making assumptions here, and it
produces considerable work at the representation stages, but that can
easily be accomodated).
Yes, I don't want to start having explain that mess to people.
2/ Interval type specifiers (ditto)
o informix uses interval specifiers of the form
INTERVAL DAY TO HOUR. (which is just the
day and hour portion of an interval).This I can usually understand, though I think we can do this too clearer
than Informix.3/ Money type specifiers
o informix has money type specifiers that are akin
to decimal speicifiersWe have a MONEY type now, and are looking to invisibly use DECIMAL for
this instead.This would actually be sensible. My comment about money, is that the
existing type doesn't have a concept of precision; two decimal places of
money is somewhat meaningless where in the local currency it takes 1000
washers to buy a packet of crisps. The ability to set the precision of
the MONEY type is kinda important in this case.
The move to make MONEY use decimal would add precision.
5/ serial data type
o Serial type must return inserted key valueHow does Informix return the value?
From a user standpoint it mystically appears in sqlca just after the
insert statement is executed. Actually the informix engine recognises
it's just done a serial insert, and sends it back in addition to the
standard status packets.
Yes, we have currval() which allows such retrieval _inside_ the
database, as well as in the application.
I can understand the situation here (one of the main reasons I raised the
thread in the first place). Above all else the difficulty I have with
serial at the moment is the impossibility of differentiating a serial with
an int4 after creation (after all the database treats them identically).
The catalog tables don't contain any information. The only way you can
work out you created a serial column is by looking for an appropriately
named sequence in the database on every int4 column that exists (or am I
wrong?). This is not exactly something that appeals to me
Yes, the SERIAL gets lost once it is created. This can cause confusion
because doing a \dt on the table shows it as an INT4 with DEFAULT, and
not a serial. This can confuse people. I remember someone saying we
would need to keep the SERIAL understanding around so we would use it
for pg_dump, but I don't remember why we needed to do that.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 6 13:21:32 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA32102
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 13:20:41 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA15983;
Thu, 6 Jan 2000 13:20:03 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001061820.NAA15983@candle.pha.pa.us>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
In-Reply-To: <3.0.1.32.20000106124001.00ed6310@mail.pacifier.com> from Don
Baccus at "Jan 6, 2000 12:40:01 pm"
To: Don Baccus <dhogaza@pacifier.com>
Date: Thu, 6 Jan 2000 13:20:03 -0500 (EST)
CC: Rod Chamberlin <rod@querix.com>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I've been wanting outer joins, but in my porting efforts have managed
to work around them without too much difficulty, even though 6.5's
limitations on subselects (not in target lists) requires that I
create PL/pgSQL functions in some cases.I certainly can't speak for the majority of users, but as one data
point I'd personally rather see outer joins done right (SQL 92
syntax) and wait a bit.Then again, I tend to be a bit of a language purist...
Thomas has tried to explain the ANSI syntax for outer joins, and I must
say I am quite confused by it. A simple OUTER added before the column
name would be a quick and simple way to do outers, perhap get them into
7.0, and allow new users to do outers without having to learn the quite
complex ANSI syntax.
At least that was my idea.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 6 13:35:33 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA37492
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 13:34:35 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id OAA95816
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 14:34:40 -0400 (AST)
(envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 6 Jan 2000 14:34:40 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: Still investigating, but ... CREATE INDEX problem in v6.5.x ...
Message-ID: <Pine.BSF.4.21.0001061428260.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Working on a database that has a table that looks like:
Table = daily
+----------------------------------+----------------------------------+-------+
| Field | Type | Length|
+----------------------------------+----------------------------------+-------+
| n | int4 | 4 |
| date | date | 4 |
| cookie | char() | 1 |
| id | text | var |
+----------------------------------+----------------------------------+-------+
Indices: zdaily_cookie
zdaily_date_nWant to create a third index on id, so run:
CREATE INDEX zdaily_id ON daily (id);
Eventually, the CREATE INDEX just crashes...
daily is big:
-rw------- 1 postgres postgres 979255296 Jan 6 02:04 daily
But, the other two indices are fine:
-rw------- 1 postgres postgres 241123328 Jan 6 02:26 zdaily_date_n
-rw------- 1 postgres postgres 229220352 Jan 6 02:13 zdaily_cookie
We're currently using v6.5.1, since it used to work there, but have tried
with with v6.5.3 also, same results...
I've thought about out of disk space problems, but the file system that
its on has over 2gig free on it, and the table is <1gig to start with...
I'm running it again right now, after running a vacuum on it, just in case
that picked up something, but the vacuum looks clean:
webusers=> vacuum verbose daily;
NOTICE: --Relation daily--
NOTICE: Pages 119538: Changed 0, Reapped 0, Empty 0, New 0; Tup 11358404: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 53, MaxLen 3959; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. Elapsed 9/2 sec.
NOTICE: Index zdaily_date_n: Pages 29434; Tuples 11358404. Elapsed 2/18 sec.
NOTICE: Index zdaily_cookie: Pages 27981; Tuples 11358404. Elapsed 3/18 sec.
The index is being created on disk, but doesn't grow beyond the 16k shown
here:
ls -lt *daily*
-rw------- 1 postgres postgres 16384 Jan 6 13:32 zdaily_id
-rw------- 1 postgres postgres 241123328 Jan 6 02:26 zdaily_date_n
-rw------- 1 postgres postgres 229220352 Jan 6 02:13 zdaily_cookie
-rw------- 1 postgres postgres 979255296 Jan 6 02:04 daily
We have no "verbose" mode for a create index, do we? Something that would
narrow down a record whose 'id' field has bad data in it?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Thu Jan 6 13:41:35 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA38240
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 13:40:43 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id OAA95849;
Thu, 6 Jan 2000 14:39:55 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 6 Jan 2000 14:39:55 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Don Baccus <dhogaza@pacifier.com>, Rod Chamberlin <rod@querix.com>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
In-Reply-To: <200001061820.NAA15983@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001061436550.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 6 Jan 2000, Bruce Momjian wrote:
I've been wanting outer joins, but in my porting efforts have managed
to work around them without too much difficulty, even though 6.5's
limitations on subselects (not in target lists) requires that I
create PL/pgSQL functions in some cases.I certainly can't speak for the majority of users, but as one data
point I'd personally rather see outer joins done right (SQL 92
syntax) and wait a bit.Then again, I tend to be a bit of a language purist...
Thomas has tried to explain the ANSI syntax for outer joins, and I must
say I am quite confused by it. A simple OUTER added before the column
name would be a quick and simple way to do outers, perhap get them into
7.0, and allow new users to do outers without having to learn the quite
complex ANSI syntax.At least that was my idea.
First, I'm for getting OUTER JOINs in ASAP...but, I'm a little concerned
with thought of throwing in what *sounds* like a 'stop gap' measure...
Just to clarify..."A simple OUTER added before the column" would be a
PostgreSQL-ism? Sort of like Oracle and all the rest have their own
special traits? Eventually, the plan is to implement OJs as "SQL92 spec",
and leave our -ism in for backwards compatibility?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Thu Jan 6 13:46:32 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA38951
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 13:45:38 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA16391;
Thu, 6 Jan 2000 13:44:57 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001061844.NAA16391@candle.pha.pa.us>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
In-Reply-To: <Pine.BSF.4.21.0001061436550.18498-100000@thelab.hub.org> from
The
Hermit Hacker at "Jan 6, 2000 02:39:55 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Thu, 6 Jan 2000 13:44:57 -0500 (EST)
CC: Don Baccus <dhogaza@pacifier.com>, Rod Chamberlin <rod@querix.com>,
pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Thomas has tried to explain the ANSI syntax for outer joins, and I must
say I am quite confused by it. A simple OUTER added before the column
name would be a quick and simple way to do outers, perhap get them into
7.0, and allow new users to do outers without having to learn the quite
complex ANSI syntax.At least that was my idea.
First, I'm for getting OUTER JOINs in ASAP...but, I'm a little concerned
with thought of throwing in what *sounds* like a 'stop gap' measure...Just to clarify..."A simple OUTER added before the column" would be a
PostgreSQL-ism? Sort of like Oracle and all the rest have their own
special traits? Eventually, the plan is to implement OJs as "SQL92 spec",
and leave our -ism in for backwards compatibility?
Yes, OUTER is an Informix-ism. Oracle uses *=. I think the first is
easier to add and makes more sense for us. *= could be defined by
someone as an operator, and overloading our already complex operator
code to do *= for OUTER may be too complex for people to understand.
It would be:
SELECT *
FROM tab1, OUTER tab2
WHERE tab1.col1 = tab2.col2
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 6 14:03:33 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA43300
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 14:02:43 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id PAA96018;
Thu, 6 Jan 2000 15:01:49 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 6 Jan 2000 15:01:49 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Don Baccus <dhogaza@pacifier.com>, Rod Chamberlin <rod@querix.com>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
In-Reply-To: <200001061844.NAA16391@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001061500560.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 6 Jan 2000, Bruce Momjian wrote:
Thomas has tried to explain the ANSI syntax for outer joins, and I must
say I am quite confused by it. A simple OUTER added before the column
name would be a quick and simple way to do outers, perhap get them into
7.0, and allow new users to do outers without having to learn the quite
complex ANSI syntax.At least that was my idea.
First, I'm for getting OUTER JOINs in ASAP...but, I'm a little concerned
with thought of throwing in what *sounds* like a 'stop gap' measure...Just to clarify..."A simple OUTER added before the column" would be a
PostgreSQL-ism? Sort of like Oracle and all the rest have their own
special traits? Eventually, the plan is to implement OJs as "SQL92 spec",
and leave our -ism in for backwards compatibility?Yes, OUTER is an Informix-ism. Oracle uses *=. I think the first is
easier to add and makes more sense for us. *= could be defined by
someone as an operator, and overloading our already complex operator
code to do *= for OUTER may be too complex for people to understand.It would be:
SELECT *
FROM tab1, OUTER tab2
WHERE tab1.col1 = tab2.col2
What about >2 table joins? Wish I had my book here, but I though tyou
could do multiple OUTER joins, no?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Thu Jan 6 14:00:33 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA41177
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 14:00:18 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id TAA21858;
Thu, 6 Jan 2000 19:08:00 GMT
Sender: lockhart@hub.org
Message-ID: <3874E810.4762A42@alumni.caltech.edu>
Date: Thu, 06 Jan 2000 19:08:00 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
CC: Bruce Momjian <pgman@candle.pha.pa.us>, Rod Chamberlin <rod@querix.com>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with InformixSQL
References: <Pine.LNX.4.10.10001061220560.14942-100000@shiela.querix.co.uk>
<3.0.1.32.20000106124001.00ed6310@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I've been wanting outer joins, but in my porting efforts have managed
to work around them without too much difficulty, even though 6.5's
limitations on subselects (not in target lists) requires that I
create PL/pgSQL functions in some cases.
I certainly can't speak for the majority of users, but as one data
point I'd personally rather see outer joins done right (SQL 92
syntax) and wait a bit.
A bit of a misunderstanding here: we are using SQL92 syntax but will
try to implement the outer join operation using *internal* data
structures similar to what we have now.
Any alternate syntaxes are just a diversion which slow us down on the
road to world domination ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Jan 6 14:17:39 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA46898
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 14:17:06 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA16888;
Thu, 6 Jan 2000 14:16:30 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001061916.OAA16888@candle.pha.pa.us>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
In-Reply-To: <Pine.BSF.4.21.0001061500560.18498-100000@thelab.hub.org> from
The
Hermit Hacker at "Jan 6, 2000 03:01:49 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Thu, 6 Jan 2000 14:16:30 -0500 (EST)
CC: Don Baccus <dhogaza@pacifier.com>, Rod Chamberlin <rod@querix.com>,
pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Yes, OUTER is an Informix-ism. Oracle uses *=. I think the first is
easier to add and makes more sense for us. *= could be defined by
someone as an operator, and overloading our already complex operator
code to do *= for OUTER may be too complex for people to understand.It would be:
SELECT *
FROM tab1, OUTER tab2
WHERE tab1.col1 = tab2.col2What about >2 table joins? Wish I had my book here, but I though tyou
could do multiple OUTER joins, no?
SELECT *
FROM tab1, OUTER tab2, OUTER tab3
WHERE tab1.col1 = tab2.col2 AND
tab1.col3 = tab3.col3
My assumption is that you can't join tab2 to tab3 becaue tab2 is already
outer, but I don't know.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 6 14:19:33 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA47112
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 14:18:35 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA16902;
Thu, 6 Jan 2000 14:17:17 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001061917.OAA16902@candle.pha.pa.us>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with InformixSQL
In-Reply-To: <3874E810.4762A42@alumni.caltech.edu> from Thomas Lockhart at
"Jan
6, 2000 07:08:00 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Thu, 6 Jan 2000 14:17:17 -0500 (EST)
CC: Don Baccus <dhogaza@pacifier.com>, Rod Chamberlin <rod@querix.com>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I've been wanting outer joins, but in my porting efforts have managed
to work around them without too much difficulty, even though 6.5's
limitations on subselects (not in target lists) requires that I
create PL/pgSQL functions in some cases.
I certainly can't speak for the majority of users, but as one data
point I'd personally rather see outer joins done right (SQL 92
syntax) and wait a bit.A bit of a misunderstanding here: we are using SQL92 syntax but will
try to implement the outer join operation using *internal* data
structures similar to what we have now.Any alternate syntaxes are just a diversion which slow us down on the
road to world domination ;)
OK, I stand corrected. Let world domination continue.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 6 15:27:33 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA60719
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 15:26:59 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1) id 126JV3-0007K8-00
for pgsql-hackers@postgresql.org; Thu, 6 Jan 2000 20:27:13 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 126JUq-0000RI-00
for pgsql-hackers@postgresql.org; Thu, 6 Jan 2000 20:27:00 +0000
Subject: vacuum problem
To: pgsql-hackers@postgresql.org
Date: Thu, 6 Jan 2000 20:27:00 +0000 (GMT)
Reply-To: prlw1@cam.ac.uk
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E126JUq-0000RI-00@quartz.newn.cam.ac.uk>
From: "Patrick Welche,SCC,ext.35710," <prlw1@newn.cam.ac.uk>
This oddity became apparent during the numeric test:
test=> create table atable (an int, some text);
CREATE
test=> \d atable
Table "atable"
Attribute | Type | Extra
-----------+------+-------
an | int4 |
some | text |
test=> vacuum analyze atable;
NOTICE: Vacuum: table not found
VACUUM
From today's cvs. Have I missed something?
Cheers,
Patrick
From bouncefilter Thu Jan 6 15:30:34 2000
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA60994;
Thu, 6 Jan 2000 15:29:36 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.56]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Thu, 6 Jan 2000 14:20:34 -0600
Sender: ed
Message-ID: <3874FB6F.7E562625@austin.rr.com>
Date: Thu, 06 Jan 2000 14:30:39 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
CC: pgsql-announce@postgreSQL.org, pgsql-hackers@postgreSQL.org,
pgsql-general@postgreSQL.org
Subject: Re: [HACKERS] New Search Engine ... UdmSearch
References: <Pine.BSF.4.21.0001061154090.18498-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The Hermit Hacker wrote:
Well, we've finally gotten what seems to be a working version of this
going, and, so far, I'm quite impressed...If you go to http://www.postgresql.org/cgi/search.cgi (URL to change), you
can see it in action.
Site-wide search for pgsql yielded no results moments ago.
Cheers,
Ed Loehr
From bouncefilter Thu Jan 6 12:32:32 2000
Received: from mx02.gis.net ([208.218.130.7])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA17206
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 12:32:06 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from laptop.pacifier.com (nas-76-214.boston.navinet.net
[216.67.76.214]) by mx02.gis.net (8.8.8/8.8.8+pyrd) with SMTP
id MAA20911; Thu, 6 Jan 2000 12:31:57 -0500 (EST)
Message-Id: <3.0.1.32.20000106123107.00edd1f0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 06 Jan 2000 12:31:07 -0800
To: Rod Chamberlin <rod@querix.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix
SQL
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <Pine.LNX.4.10.10001061450170.14942-100000@shiela.querix.co .uk>
References: <3.0.1.32.20000106092353.00ee115c@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 03:09 PM 1/6/00 +0000, Rod Chamberlin wrote:
I wrote:
Rather than go blow-by-blow,
(I meant blow-by-blow through Rod's list)...
Actually what I'm proposing is more to support mutiple database syntaxes
wherever possible. The INFORMIX style of outer join (and for that matter
the oracle style), are not gramatically exclusive. There is no reason why
you should not allow *all* sane outer join syntaxes, apart from the added
complexity in the parser.
Well, there are reasons, actually. Documentation as well as the parser
becomes more complex, and ... well ... it's messy and ugly.
The same is true largely for the other changes I suggested. They are for
portability with other systems to attempt to minimise the amount of work
necessary to migrate a given application.
In many cases you could write a pre-processor to bulk-translate stuff
if you wanted. Indeed, friends and I porting the Ars Digita Community
system have done some of that ourselves (moving it from Oracle).
Why is this interesting for Informix? Two reasons I can list
offhand:
1/ Informix is currently deserting it's customer base of small
business users, instead trying to concetrate on larger organisations.
There are therefore vasts numbers of users crying out for something to
fill that gap. This I will admit provides a commercial basis for any such
attempt, since we have already got some of the other tools which
informix users will be interested in.
So write a portability tool to help them move their stuff.
Just MHO, of course.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Thu Jan 6 15:31:35 2000
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA61492;
Thu, 6 Jan 2000 15:31:03 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.56]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Thu, 6 Jan 2000 14:22:06 -0600
Sender: ed
Message-ID: <3874FBCC.F73209CA@austin.rr.com>
Date: Thu, 06 Jan 2000 14:32:12 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>, pgsql-announce@postgresql.org,
pgsql-hackers@postgresql.org, pgsql-general@postgresql.org
Subject: Re: [HACKERS] New Search Engine ... UdmSearch
References: <Pine.BSF.4.21.0001061154090.18498-100000@thelab.hub.org>
<3874FB6F.7E562625@austin.rr.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Ed Loehr wrote:
The Hermit Hacker wrote:
Well, we've finally gotten what seems to be a working version of this
going, and, so far, I'm quite impressed...If you go to http://www.postgresql.org/cgi/search.cgi (URL to change), you
can see it in action.Site-wide search for pgsql yielded no results moments ago.
Correction: Search in hackers/general for pgsql yields no results.
Cheers,
Ed Loehr
From bouncefilter Thu Jan 6 12:33:32 2000
Received: from mx02.gis.net ([208.218.130.7])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA17747
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 12:32:37 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from laptop.pacifier.com (nas-76-214.boston.navinet.net
[216.67.76.214]) by mx02.gis.net (8.8.8/8.8.8+pyrd) with SMTP
id MAA20922; Thu, 6 Jan 2000 12:32:03 -0500 (EST)
Message-Id: <3.0.1.32.20000106124001.00ed6310@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 06 Jan 2000 12:40:01 -0800
To: Bruce Momjian <pgman@candle.pha.pa.us>, Rod Chamberlin <rod@querix.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix
SQL
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <200001061608.LAA13338@candle.pha.pa.us>
References: <Pine.LNX.4.10.10001061220560.14942-100000@shiela.querix.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 11:08 AM 1/6/00 -0500, Bruce Momjian wrote:
4/ Informix outer join syntax
o informix uses outer joins of the form
SELECT * FROM a, outer b where a.nr = b.nr
This will require some post-processing to determine
the actual join conditions.Believe it or not, I am hoping to get this into 7.0. The ANSI syntax
requires a lot of optimizer changes, because it basically allows user
specification of the join order. In talking to Thomas, we hoped to
implement OUTER as a flag on the table that we could easily implement in
7.0. Let's see how it goes.
Hmmm...I have to question this wisdom of this, because once in and
used there will be pressure to support it forever. How will this
play with the SQL 92 syntax? Order specification isn't a bad thing
given the fact that outer joins aren't associative (SQL for smarties
gives examples).
I've been wanting outer joins, but in my porting efforts have managed
to work around them without too much difficulty, even though 6.5's
limitations on subselects (not in target lists) requires that I
create PL/pgSQL functions in some cases.
I certainly can't speak for the majority of users, but as one data
point I'd personally rather see outer joins done right (SQL 92
syntax) and wait a bit.
Then again, I tend to be a bit of a language purist...
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Thu Jan 6 15:45:35 2000
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA66305;
Thu, 6 Jan 2000 15:44:52 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.56]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Thu, 6 Jan 2000 14:35:50 -0600
Sender: ed
Message-ID: <3874FF04.19DAFFB9@austin.rr.com>
Date: Thu, 06 Jan 2000 14:45:56 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
CC: pgsql-announce@postgresql.org, pgsql-hackers@postgresql.org,
pgsql-general@postgresql.org
Subject: Re: [GENERAL] New Search Engine ... UdmSearch
References: <Pine.BSF.4.21.0001061154090.18498-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I said: "There aren't any results for pgsql..."
The Hermit Hacker wrote:
... and the database is just being populated right now, and ...
D'oh!!! Read more carefully! My apologies for the brain-dead spam...
From bouncefilter Thu Jan 6 15:48:34 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA66990
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 15:48:24 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1) id 126Jpn-0007Kk-00
for pgsql-hackers@postgresql.org; Thu, 6 Jan 2000 20:48:39 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 126Jpa-0000V8-00
for pgsql-hackers@postgresql.org; Thu, 6 Jan 2000 20:48:26 +0000
Subject: pg_dumpall prob
To: pgsql-hackers@postgresql.org
Date: Thu, 6 Jan 2000 20:48:26 +0000 (GMT)
Reply-To: prlw1@cam.ac.uk
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E126Jpa-0000V8-00@quartz.newn.cam.ac.uk>
From: "Patrick Welche,SCC,ext.35710," <prlw1@newn.cam.ac.uk>
line 50 of pg_dumpall (cvs of today) has
psql -l -A -q -t| tr '|' ' ' | grep -v '^template1 ' | \
psql -l -A -q -t| tr '|' ' '
will return a list of databases beginning with the two lines
List of databases
Database Owner
and ending with
(n rows)
So, should psql's -q option suppress these three lines, or should pg_dumpall
get rid of them?
(We don't want to connect to database "List" as user "of" with encoding
"databases")
Cheers,
Patrick
From bouncefilter Thu Jan 6 16:02:34 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id QAA05410
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 16:02:30 -0500 (EST)
(envelope-from wieck@debis.com)
Received: from debis.com by orion.SAPserv.Hamburg.dsh.de with smtp
for <pgsql-hackers@postgreSQL.org>
id m126Jtl-0003kGC; Thu, 6 Jan 100 21:52 MET
Sender: wieck
Message-ID: <3875009C.947CE2B2@debis.com>
Date: Thu, 06 Jan 2000 21:52:44 +0100
From: Jan Wieck <wieck@debis.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.9 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Thomas! FOREIGN KEY problem!
References: <38728E32.614C898@debis.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I wrote:
Damned,
while hacking down a little test suite for FOREIGN KEY
(just to have some script based checking while doing
the file buffering of the event queue), I discovered
something looking wrong.
After rereading the part of the SQL3 spec in question, I saw that
the checks I did for "triggered data change violation" where
wrong.
The just committed changes to the trigger manager and related
areas cause ANY second change of a value, possibly referenced by
a foreign key, to bomb out with the above exception. So the
example below doesn't work any more.
That means, that a row cannot get deleted, if it has been
inserted or possibly referenced attributes updated inside the
same transaction. Also, possibly referenced attributes cannot be
changed twice inside one and the same transaction. The previous
"event condensing" is gone.
The benefit is, that since the trigger manager now checks for
RI_FKey... triggers, if the referenced attributes change while
adding the event to the queue, he will suppress the real trigger
call at all if the key's are equal. This saves fetching back OLD
and NEW at the time, the checks have to be executed.
Having the following table schema:
CREATE TABLE t1 (
a int4 PRIMARY KEY,
b int4
);CREATE TABLE t2 (
c int4,
d int4,CONSTRAINT t2_d_t1_a FOREIGN KEY (d)
REFERENCES t1 MATCH FULL
ON UPDATE CASCADE
DEFERRABLE INITIALLY IMMEDIATE
);I can do the following:
BEGIN;
SET CONSTRAINTS ALL DEFERRED;
UPDATE t1 SET a = 99 WHERE a = 1;
UPDATE t1 SET a = 1 WHERE a = 2;
UPDATE t1 SET a = 2 WHERE a = 99;
COMMIT;to swap t1.a 1<->2.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Thu Jan 6 16:22:34 2000
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id QAA08891
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 16:22:17 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <ZW4G6Z03>; Thu, 6 Jan 2000 23:19:14 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C3FC@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'The Hermit Hacker '" <scrappy@hub.org>, "'Bruce Momjian '"
<pgman@candle.pha.pa.us>
Cc: "'Don Baccus '" <dhogaza@pacifier.com>, "'Rod Chamberlin '"
<rod@querix.com>, "'pgsql-hackers@postgreSQL.org '"
<pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
Date: Thu, 6 Jan 2000 23:08:33 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"
Yes, OUTER is an Informix-ism. Oracle uses *=. I think the first is
easier to add and makes more sense for us. *= could be defined by
someone as an operator, and overloading our already complex operator
code to do *= for OUTER may be too complex for people to understand.It would be:
SELECT *
FROM tab1, OUTER tab2
WHERE tab1.col1 = tab2.col2What about >2 table joins? Wish I had my book here, but I though tyou
could do multiple OUTER joins, no?
Oracle uses a syntax which I quite like. The query above would become:
SELECT *
FROM tab, tab2
WHERE tab1.col1 = tab2.col2 (+)
I've actually used queries something like this:
SELECT blah, blah, blah
FROM t1, t2, t3, t4
WHERE t1.start_date BETWEEN t2.start_date (+) AND t2.end_date (+)
AND t1.y = t2.y (+)
AND t3.x (+) = t1.x
AND t3.y (+) = t1.y
AND t4.x = t1.x;
For example...
I realise that this is not standard, but it's easy to read, and easy to
develop.
The problem with OUTER is: OUTER on which relationship? Does this matter?
I haven't thought about it hugely, but it may not make sense when you try to
do this:
SELECT *
FROM t1, OUTER t2, t3
WHERE t1.x = t2.x
AND t2.y = t3.y
Which is the OUTER join? Outer joining to t1 and inner joining to t3 gives
(I think) a different result to inner joining to t1 and outer joining to t3.
Then you have to start creating language rules to help determine which join
becomes the outer join, and it becomes a bit of a mess. With Oracle's
notation, it's pretty clear (I think anyway).
Hope this adds some fuel to the process...
MikeA
From bouncefilter Thu Jan 6 16:18:34 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA08427
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 16:17:39 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
QAA21472;
Thu, 6 Jan 2000 16:17:05 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001062117.QAA21472@candle.pha.pa.us>
Subject: Re: [HACKERS] pg_dumpall prob
In-Reply-To: <E126Jpa-0000V8-00@quartz.newn.cam.ac.uk> from "Patrick Welche,
SCC, ext.35710, " at "Jan 6, 2000 08:48:26 pm"
To: prlw1@cam.ac.uk
Date: Thu, 6 Jan 2000 16:17:05 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
line 50 of pg_dumpall (cvs of today) has
psql -l -A -q -t| tr '|' ' ' | grep -v '^template1 ' | \
psql -l -A -q -t| tr '|' ' '
will return a list of databases beginning with the two lines
OK, this is an artifact of the new psql format. I have changed to the
code to be:
psql -l -A -q -t | grep '|' | tr '|' ' ' | sed -n '2,$p' | \
grep -v '^template1 ' | \
This removes all lines with no pipe, changes pipe to space, and removes
the first line and the template1 line from the output. This should work.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 6 16:30:35 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA10036;
Thu, 6 Jan 2000 16:30:06 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA97346;
Thu, 6 Jan 2000 17:30:15 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 6 Jan 2000 17:30:14 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Ed Loehr <eloehr@austin.rr.com>
cc: pgsql-announce@postgreSQL.org, pgsql-hackers@postgreSQL.org,
pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] New Search Engine ... UdmSearch
In-Reply-To: <3874FF04.19DAFFB9@austin.rr.com>
Message-ID: <Pine.BSF.4.21.0001061729460.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 6 Jan 2000, Ed Loehr wrote:
I said: "There aren't any results for pgsql..."
The Hermit Hacker wrote:
... and the database is just being populated right now, and ...
D'oh!!! Read more carefully! My apologies for the brain-dead spam...
ya, still playing with things...am currently doing the docs directory, and
then will start hitting the mailing lists...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Thu Jan 6 17:32:35 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA33303
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 17:32:26 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
RAA22918;
Thu, 6 Jan 2000 17:04:16 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001062204.RAA22918@candle.pha.pa.us>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
In-Reply-To: <1BF7C7482189D211B03F00805F8527F748C3FC@S-NATH-EXCH2> from
"Ansley, Michael" at "Jan 6, 2000 11:08:33 pm"
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>
Date: Thu, 6 Jan 2000 17:04:16 -0500 (EST)
CC: "'The Hermit Hacker '" <scrappy@hub.org>,
"'Don Baccus '" <dhogaza@pacifier.com>,
"'Rod Chamberlin '" <rod@querix.com>,
"'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
SELECT blah, blah, blah
FROM t1, t2, t3, t4
WHERE t1.start_date BETWEEN t2.start_date (+) AND t2.end_date (+)
AND t1.y = t2.y (+)
AND t3.x (+) = t1.x
AND t3.y (+) = t1.y
AND t4.x = t1.x;For example...
I realise that this is not standard, but it's easy to read, and easy to
develop.The problem with OUTER is: OUTER on which relationship? Does this matter?
I haven't thought about it hugely, but it may not make sense when you try to
do this:SELECT *
FROM t1, OUTER t2, t3
WHERE t1.x = t2.x
AND t2.y = t3.yWhich is the OUTER join? Outer joining to t1 and inner joining to t3 gives
(I think) a different result to inner joining to t1 and outer joining to t3.
Then you have to start creating language rules to help determine which join
becomes the outer join, and it becomes a bit of a mess. With Oracle's
notation, it's pretty clear (I think anyway).
This must be why the ANSI standard requires you to specify the join when
doing outer. Thomas says we are going only with ANSI syntax, and I can
see now why OUTER is just looking for problems.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 6 17:56:35 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA37440
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 17:56:20 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1) id 126Lpd-0007O8-00
for pgsql-hackers@postgresql.org; Thu, 6 Jan 2000 22:56:37 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 126LpP-0000bV-00
for pgsql-hackers@postgresql.org; Thu, 6 Jan 2000 22:56:23 +0000
Subject: pg_dump problem
To: pgsql-hackers@postgresql.org
Date: Thu, 6 Jan 2000 22:56:22 +0000 (GMT)
Reply-To: prlw1@cam.ac.uk
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E126LpP-0000bV-00@quartz.newn.cam.ac.uk>
From: "Patrick Welche,SCC,ext.35710," <prlw1@newn.cam.ac.uk>
% pg_dump -sv regression > foo
...
-- dumping out user-defined procedural languages
-- dumping out user-defined functions
Segmentation fault (core dumped)
#0 0x4810dc02 in vfprintf ()
#1 0x480c4963 in vsprintf ()
#2 0x48078e8a in appendPQExpBuffer (str=0x616e746f,
fmt=0x3d20656d <Address 0x3d20656d out of bounds>) at pqexpbuffer.c:197
#3 0x6c732065 in ?? ()
% tail foo
end if;
return new;
end;
' LANGUAGE 'plpgsql';
CREATE FUNCTION "tg_iface_biu" ( ) RETURNS opaque AS '
declare
sname text;
sysrec record;
begin
select into sysrec * from
ie., it stops in mid flight, the line is
select into sysrec * from system where name = new.sysname;
so it seems that the PQExpBuffer may well be to full ?
-s means dumpSchema(), getFuncs(), dumpFuncs(), dumpOneFunc()
pg_dump.c:dumpOneFunc():2346:
appendPQExpBuffer(q, " ) RETURNS %s%s AS '%s' LANGUAGE '%s';\n",
(finfo[i].retset) ? " SETOF " : "",
fmtId(findTypeByOid(tinfo, numTypes, finfo[i].prorettype), false),
func_def, func_lang);
so it cored while printing func_def ?! which is only 487 bytes long..
Rather confused.. Are any of you seeing this?
Cheers,
Patrick
From bouncefilter Thu Jan 6 18:22:36 2000
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA43745
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 18:22:27 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <ZW4G65AB>; Fri, 7 Jan 2000 01:19:25 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C3FE@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
Reply-To: prlw1@cam.ac.uk
To: "'Patrick Welche,SCC,ext.35710, '" <prlw1@newn.cam.ac.uk>,
"'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] pg_dump problem
Date: Fri, 7 Jan 2000 01:14:06 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"
This looks like a place where the sprintf is being caught with too long a
string. Although 487 bytes shouldn't be too long; perhaps the rest of
what's in there is causing sprintf to hooch. The limit is supposed to be
around 1kB. I'll try changing the fmt style string to a series of appends.
It's less efficient, but may work.
Thanks...
MikeA
-----Original Message-----
From: Patrick Welche,SCC,ext.35710,
To: pgsql-hackers@postgreSQL.org
Sent: 00/01/07 12:56
Subject: [HACKERS] pg_dump problem
% pg_dump -sv regression > foo
...
-- dumping out user-defined procedural languages
-- dumping out user-defined functions
Segmentation fault (core dumped)
#0 0x4810dc02 in vfprintf ()
#1 0x480c4963 in vsprintf ()
#2 0x48078e8a in appendPQExpBuffer (str=0x616e746f,
fmt=0x3d20656d <Address 0x3d20656d out of bounds>) at
pqexpbuffer.c:197
#3 0x6c732065 in ?? ()
% tail foo
end if;
return new;
end;
' LANGUAGE 'plpgsql';
CREATE FUNCTION "tg_iface_biu" ( ) RETURNS opaque AS '
declare
sname text;
sysrec record;
begin
select into sysrec * from
ie., it stops in mid flight, the line is
select into sysrec * from system where name = new.sysname;
so it seems that the PQExpBuffer may well be to full ?
-s means dumpSchema(), getFuncs(), dumpFuncs(), dumpOneFunc()
pg_dump.c:dumpOneFunc():2346:
appendPQExpBuffer(q, " ) RETURNS %s%s AS '%s' LANGUAGE '%s';\n",
(finfo[i].retset) ? " SETOF " : "",
fmtId(findTypeByOid(tinfo, numTypes,
finfo[i].prorettype), false),
func_def, func_lang);
so it cored while printing func_def ?! which is only 487 bytes long..
Rather confused.. Are any of you seeing this?
Cheers,
Patrick
************
From bouncefilter Thu Jan 6 18:30:36 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA44700
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 18:30:00 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id SAA00513
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 18:29:59 -0500
Message-ID: <38752575.FBCD36B1@wgcr.org>
Date: Thu, 06 Jan 2000 18:29:57 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: [Fwd: Re: First Major Open Source Database]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
[Ok, I've been in touch with the author of the 'First Major Open Source
Database' article. Here's what he wants to do. Let me know what you
think, and correct any misinformation I may have fed him.]
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
-------- Original Message --------
From: Doc Searls <doc@searls.com>
Subject: Re: First Major Open Source Database
To: Jason Kroll <hyena@ssc.com>
CC: mlr@ssc.com, lamar.owen@wgcr.org
To move this along quickly, I suggest this as a sidebar we can run as
a table in the piece at
http://www2.linuxjournal.com/articles/conversations/010.html ...
----------------
Credit where due
Since this interview went up, the response has been overwhelmingly
positive. Some readers, however, have urged us to give full credit to
the other open source databases that are already out there and have
prior claims to the "major" label. The strongest urgings have come
from PostgreSQL developers, who have provided us with some points and
links that we are happy to pass along here.
The points:
- University Ingres, developed starting in 1977, qualifies for the
'First Major Open Source Database' honor. Ingres is the direct
ancestor of PostgreSQL.
- PostgreSQL is at version 6.5.3, and has been open source since the
beginning. "The development is very open, the developers friendly,
and the code is improving by leaps and bounds," writes Lamar Owen,
RPM Package Maintainer with the PostgreSQL Global Development Group.
He says "PostgreSQL has shipped with RedHat Linux as part of the
'Official Boxed Set' since RedHat 5.0." He also recommends comparing
RDBMSes by the "ACID criteria." These are: "Atomicity, Consistency,
Isolation, Durability."
- Hacking database code is not lightweight work. "Kernel hacking is
not a walk in the park, nor is GUI hacking, library hacking, or any
other tool hacking," Owen says, "But, database hacking is a league
unto itself....The learning curve for doing back-end database
development is the steepest of any project of which I am aware."
Here are two useful links:
- The freshmeat.net appindex entry for databases
<http://www.freshmeat.net/appindex/daemons/database.html>
- PostgreSQL.org's comparison chart <http://www.postgresql.org>
Alert us to more and we'll put them here.
-- Doc Searls
-------------
Here is the same thing, in HTML:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
<head>
<title>Credit Where Due</title>
</head>
<body>
<h2>Credit where due</h2>
<p>Since this interview went up, the response has
been overwhelmingly positive. Some readers, however, have urged us to
give full credit to the other open source databases that are already
out there and have prior claims to the "major" label. The
strongest urgings have come from PostgreSQL developers, who have
provided us with some points and links that we are happy to pass
along here.</p>
<p>The points:</p>
<p>— University Ingres, developed starting in
1977, qualifies for the 'First Major Open Source Database' honor.
Ingres is the direct ancestor of PostgreSQL.</p>
<p>— PostgreSQL is at version 6.5.3, and has
been open source since the beginning. "The development is very
open, the developers friendly, and the code is improving by leaps and
bounds," writes Lamar Owen, RPM Package Maintainer with the
PostgreSQL Global Development Group. He says "PostgreSQL has
shipped with RedHat Linux as part of the 'Official Boxed Set' since
RedHat 5.0." He also recommends comparing RDBMSes by the
"ACID criteria." These are: "Atomicity, Consistency,
Isolation, Durability."</p>
<p>— Hacking database code is not lightweight
work. "Kernel hacking is not a walk in the park, nor is GUI
hacking, library hacking, or any other tool hacking," Owen says,
"But, database hacking is a league unto itself....The learning
curve for doing back-end database development is the steepest of any
project of which I am aware."</p>
<p>Here are two useful links:</p>
<ul>
<li><a
href="http:/www.freshmeat.net/ppindex/aemons/atabase.html">The
freshmeat.net appindex entry for databases</a>
<li><a
href="http:/www.postgresql.org">PostgreSQL.org's comparison chart</a>
</ul>
<p>Alert us to more and we'll put them here.</p>
<p>— Doc Searls
</body>
</html>
----------
Does that work? If so, let's get it up.
Doc, in the basement of Moscone, in the surreal Macworld where Apple
still, amazingly, lives.
----------
Doc Searls
Senior Editor, Linux Journal
doc@ssc.com
http://www.linuxjournal.com
Office: 544 Oak Park Way, Emerald Hills, CA 94062-4038
Phone: (650) 361-1324 Cell: (206) 849-9586 Fax: (650) 361-1348
----------
From bouncefilter Thu Jan 6 18:42:37 2000
Received: from hu.tm.ee (isdn-54.uninet.ee [194.204.0.118])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA49170
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 18:42:36 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 6AC1713064; Fri, 7 Jan 2000 01:47:06 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <3875297A.A2F1DF1E@tm.ee>
Date: Fri, 07 Jan 2000 01:47:06 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>
Cc: "'The Hermit Hacker '" <scrappy@hub.org>,
"'Bruce Momjian '" <pgman@candle.pha.pa.us>,
"'Don Baccus '" <dhogaza@pacifier.com>,
"'Rod Chamberlin '" <rod@querix.com>,
"'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
References: <1BF7C7482189D211B03F00805F8527F748C3FC@S-NATH-EXCH2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"Ansley, Michael" wrote:
Yes, OUTER is an Informix-ism. Oracle uses *=. I think the first is
easier to add and makes more sense for us. *= could be defined by
someone as an operator, and overloading our already complex operator
code to do *= for OUTER may be too complex for people to understand.It would be:
SELECT *
FROM tab1, OUTER tab2
WHERE tab1.col1 = tab2.col2What about >2 table joins? Wish I had my book here, but I though tyou
could do multiple OUTER joins, no?Oracle uses a syntax which I quite like. The query above would become:
SELECT *
FROM tab, tab2
WHERE tab1.col1 = tab2.col2 (+)I've actually used queries something like this:
SELECT blah, blah, blah
FROM t1, t2, t3, t4
WHERE t1.start_date BETWEEN t2.start_date (+) AND t2.end_date (+)
AND t1.y = t2.y (+)
AND t3.x (+) = t1.x
AND t3.y (+) = t1.y
AND t4.x = t1.x;For example...
I realise that this is not standard, but it's easy to read, and easy to
develop.
I completely agree that Oracle has got it in a very clear, readable and
understandable way.
When I used MS Access (supposedly ANSI) I always created the outer join
queries
using the graphical tool and also had to examine it using said tool, because
all
these LEFT OUTER JOIN ON .... introduced too much line noise for me to be able
to understand what was actually meant.
OTOH, just marking the "outer" side with (+) was easy both to to read and
write.
So I would very much like to have the Oracle syntax for outer joins as well.
IMHO the ANSI standard (as anything designed by a committee) is not always the
best
way to do things.
--------------
Hannu
From bouncefilter Thu Jan 6 19:05:37 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA55200
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 19:04:45 -0500 (EST)
(envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id JAA00451; Fri, 07 Jan 2000 09:04:34 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Proposed cleanup of index-related planner estimation
procedures
Date: Fri, 7 Jan 2000 09:09:58 +0900
Message-ID: <000501bf58a3$88a213a0$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <20065.947132708@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom LaneI am thinking about redefining and simplifying the planner's interface
to index-type-dependent estimation routines.Currently, each defined index type is supposed to supply two routines:
an "amopselect" routine and an "amopnpages" routine. (The existing
actual routines of this kind are btreesel, btreenpages, etc in
src/backend/utils/adt/selfuncs.c.) These things are called by
index_selectivity() in src/backend/optimizer/util/plancat.c. amopselect
tries to determine the selectivity of an indexqual (the fraction of
main-table tuples it will select) and amopnpages tries to determine
the number of index pages that will be read to do it.Now, this collection of code is largely redundant with
optimizer/path/clausesel.c, which also tries to estimate the selectivity
of qualification conditions. Furthermore, the interface to these
routines is fundamentally misdesigned, because there is no way to deal
with interrelated qualification conditions --- for example, if we have
a range query like "... WHERE x > 10 AND x < 20", the code estimates
the selectivity as the product of the selectivities of the two terms
independently, but the actual selectivity is very different from that.
I am working on fixing clausesel.c to be smarter about correlated
conditions, but it won't do much good to fix that code without fixing
the index-related code.What I'm thinking about doing is replacing these two per-index-type
routines with a single routine, which is called once per proposed
indexscan rather than once per qual clause. It would receive the
whole indexqual list as a parameter, instead of just one qual.
A typical implementation would just call clausesel.c's general-purpose
code to estimate the selectivity, and then do a little bit of extra
work to derive the estimated number of index pages from that number.
Seems good to me.
I have also been suspicious about per qual selectivity and have
another exmaple.
For the following query
select * from .. where col1=val1 and col2=val2;
the selectivity is selectivity of (col1=val1) * selectivity of (col2=val2)
currently. But it's not right in many cases.
Though it's almost impossible to hold disbursions for all combination
of columns,it may be possible to hold multi-column disbursions for
multi-columns indexes,
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Thu Jan 6 19:24:37 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA58029
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 19:24:27 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id UAA98663;
Thu, 6 Jan 2000 20:24:35 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 6 Jan 2000 20:24:35 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Lamar Owen <lamar.owen@wgcr.org>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [Fwd: Re: First Major Open Source Database]
In-Reply-To: <38752575.FBCD36B1@wgcr.org>
Message-ID: <Pine.BSF.4.21.0001062024180.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sounds good to me ...
On Thu, 6 Jan 2000, Lamar Owen wrote:
[Ok, I've been in touch with the author of the 'First Major Open Source
Database' article. Here's what he wants to do. Let me know what you
think, and correct any misinformation I may have fed him.]--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11-------- Original Message --------
From: Doc Searls <doc@searls.com>
Subject: Re: First Major Open Source Database
To: Jason Kroll <hyena@ssc.com>
CC: mlr@ssc.com, lamar.owen@wgcr.orgTo move this along quickly, I suggest this as a sidebar we can run as
a table in the piece at
http://www2.linuxjournal.com/articles/conversations/010.html ...----------------
Credit where due
Since this interview went up, the response has been overwhelmingly
positive. Some readers, however, have urged us to give full credit to
the other open source databases that are already out there and have
prior claims to the "major" label. The strongest urgings have come
from PostgreSQL developers, who have provided us with some points and
links that we are happy to pass along here.The points:
- University Ingres, developed starting in 1977, qualifies for the
'First Major Open Source Database' honor. Ingres is the direct
ancestor of PostgreSQL.- PostgreSQL is at version 6.5.3, and has been open source since the
beginning. "The development is very open, the developers friendly,
and the code is improving by leaps and bounds," writes Lamar Owen,
RPM Package Maintainer with the PostgreSQL Global Development Group.
He says "PostgreSQL has shipped with RedHat Linux as part of the
'Official Boxed Set' since RedHat 5.0." He also recommends comparing
RDBMSes by the "ACID criteria." These are: "Atomicity, Consistency,
Isolation, Durability."- Hacking database code is not lightweight work. "Kernel hacking is
not a walk in the park, nor is GUI hacking, library hacking, or any
other tool hacking," Owen says, "But, database hacking is a league
unto itself....The learning curve for doing back-end database
development is the steepest of any project of which I am aware."Here are two useful links:
- The freshmeat.net appindex entry for databases
<http://www.freshmeat.net/appindex/daemons/database.html>- PostgreSQL.org's comparison chart <http://www.postgresql.org>
Alert us to more and we'll put them here.
-- Doc Searls
-------------
Here is the same thing, in HTML:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html><head>
<title>Credit Where Due</title>
</head><body>
<h2>Credit where due</h2>
<p>Since this interview went up, the response has
been overwhelmingly positive. Some readers, however, have urged us to
give full credit to the other open source databases that are already
out there and have prior claims to the "major" label. The
strongest urgings have come from PostgreSQL developers, who have
provided us with some points and links that we are happy to pass
along here.</p>
<p>The points:</p>
<p>— University Ingres, developed starting in
1977, qualifies for the 'First Major Open Source Database' honor.
Ingres is the direct ancestor of PostgreSQL.</p>
<p>— PostgreSQL is at version 6.5.3, and has
been open source since the beginning. "The development is very
open, the developers friendly, and the code is improving by leaps and
bounds," writes Lamar Owen, RPM Package Maintainer with the
PostgreSQL Global Development Group. He says "PostgreSQL has
shipped with RedHat Linux as part of the 'Official Boxed Set' since
RedHat 5.0." He also recommends comparing RDBMSes by the
"ACID criteria." These are: "Atomicity, Consistency,
Isolation, Durability."</p>
<p>— Hacking database code is not lightweight
work. "Kernel hacking is not a walk in the park, nor is GUI
hacking, library hacking, or any other tool hacking," Owen says,
"But, database hacking is a league unto itself....The learning
curve for doing back-end database development is the steepest of any
project of which I am aware."</p>
<p>Here are two useful links:</p>
<ul>
<li><a
href="http:/www.freshmeat.net/ppindex/aemons/atabase.html">The
freshmeat.net appindex entry for databases</a>
<li><a
href="http:/www.postgresql.org">PostgreSQL.org's comparison chart</a>
</ul>
<p>Alert us to more and we'll put them here.</p>
<p>— Doc Searls
</body></html>
----------
Does that work? If so, let's get it up.
Doc, in the basement of Moscone, in the surreal Macworld where Apple
still, amazingly, lives.----------
Doc Searls
Senior Editor, Linux Journal
doc@ssc.com
http://www.linuxjournal.com
Office: 544 Oak Park Way, Emerald Hills, CA 94062-4038
Phone: (650) 361-1324 Cell: (206) 849-9586 Fax: (650) 361-1348
----------************
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Thu Jan 6 19:47:37 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA64321
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 19:47:19 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id TAA00720;
Thu, 6 Jan 2000 19:47:17 -0500
Message-ID: <38753793.961B6822@wgcr.org>
Date: Thu, 06 Jan 2000 19:47:15 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
CC: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [Fwd: Re: First Major Open Source Database]
References: <Pine.BSF.4.21.0001062024180.18498-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The Hermit Hacker wrote:
Sounds good to me ...
On Thu, 6 Jan 2000, Lamar Owen wrote:
[Ok, I've been in touch with the author of the 'First Major Open Source
Database' article. Here's what he wants to do. Let me know what you
think, and correct any misinformation I may have fed him.]
Ok, I'm replying to him with a 'go'.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Thu Jan 6 19:12:37 2000
Received: from mx02.gis.net ([208.218.130.7])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA56066
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 19:11:57 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from laptop.pacifier.com (nas-2-15.boston.navinet.net [216.67.2.15])
by mx02.gis.net (8.8.8/8.8.8+pyrd) with SMTP id TAA26708;
Thu, 6 Jan 2000 19:08:01 -0500 (EST)
Message-Id: <3.0.1.32.20000106185200.00ed4834@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 06 Jan 2000 18:52:00 -0800
To: The Hermit Hacker <scrappy@hub.org>,
Bruce Momjian <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix
SQL
Cc: Rod Chamberlin <rod@querix.com>, pgsql-hackers@postgresql.org
In-Reply-To: <Pine.BSF.4.21.0001061436550.18498-100000@thelab.hub.org>
References: <200001061820.NAA15983@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 02:39 PM 1/6/00 -0400, The Hermit Hacker wrote:
Just to clarify..."A simple OUTER added before the column" would be a
PostgreSQL-ism?
Sounds like an Informix-ism if I read the thread correctly.
Sort of like Oracle and all the rest have their own
special traits?
Though I'm familiar with the Oracle syntax (far too familiar at the
moment, as I'm porting literally thousands of lines of queries many
of which do Oracle outer joins!), the style described by Bruce seems
nicer.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Thu Jan 6 19:12:39 2000
Received: from mx02.gis.net ([208.218.130.7])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA56080
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 19:12:09 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from laptop.pacifier.com (nas-2-15.boston.navinet.net [216.67.2.15])
by mx02.gis.net (8.8.8/8.8.8+pyrd) with SMTP id TAA26716;
Thu, 6 Jan 2000 19:08:06 -0500 (EST)
Message-Id: <3.0.1.32.20000106185741.00ed7b6c@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 06 Jan 2000 18:57:41 -0800
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with InformixSQL
Cc: Bruce Momjian <pgman@candle.pha.pa.us>, Rod Chamberlin <rod@querix.com>,
pgsql-hackers@postgresql.org
In-Reply-To: <3874E810.4762A42@alumni.caltech.edu>
References: <Pine.LNX.4.10.10001061220560.14942-100000@shiela.querix.co.uk>
<3.0.1.32.20000106124001.00ed6310@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 07:08 PM 1/6/00 +0000, Thomas Lockhart wrote:
I've been wanting outer joins, but in my porting efforts have managed
to work around them without too much difficulty, even though 6.5's
limitations on subselects (not in target lists) requires that I
create PL/pgSQL functions in some cases.
I certainly can't speak for the majority of users, but as one data
point I'd personally rather see outer joins done right (SQL 92
syntax) and wait a bit.A bit of a misunderstanding here: we are using SQL92 syntax but will
try to implement the outer join operation using *internal* data
structures similar to what we have now.
Yes, I've seen the existing code, in particular regarding inner
joins.
Any alternate syntaxes are just a diversion which slow us down on the
road to world domination ;)
That's my first feeling, too, as I hope I made clear.
If you don't mind my asking, just what are the difficulties? Bruce
mentioned the optimizer. I noticed the executor code that does
merge joins has conditionalized stuff in it to insert the nulls
required by outer join. And the parser has conditionalized stuff
to deal with them.
So, is it ("just", he says :) the optimizer, or more?
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Thu Jan 6 19:12:39 2000
Received: from mx02.gis.net ([208.218.130.7])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA56088
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 19:12:21 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from laptop.pacifier.com (nas-2-15.boston.navinet.net [216.67.2.15])
by mx02.gis.net (8.8.8/8.8.8+pyrd) with SMTP id TAA26720;
Thu, 6 Jan 2000 19:08:09 -0500 (EST)
Message-Id: <3.0.1.32.20000106191842.00ee4ccc@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 06 Jan 2000 19:18:42 -0800
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'The Hermit Hacker '" <scrappy@hub.org>,
"'Bruce Momjian '" <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: RE: [HACKERS] Enhancing PGSQL to be compatible with Informix
SQL
Cc: "'Rod Chamberlin '" <rod@querix.com>,
"'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
In-Reply-To: <1BF7C7482189D211B03F00805F8527F748C3FC@S-NATH-EXCH2>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 11:08 PM 1/6/00 +0200, Ansley, Michael wrote:
What about >2 table joins? Wish I had my book here, but I though tyou
could do multiple OUTER joins, no?Oracle uses a syntax which I quite like. The query above would become:
SELECT *
FROM tab, tab2
WHERE tab1.col1 = tab2.col2 (+)I've actually used queries something like this:
SELECT blah, blah, blah
FROM t1, t2, t3, t4
WHERE t1.start_date BETWEEN t2.start_date (+) AND t2.end_date (+)
AND t1.y = t2.y (+)
AND t3.x (+) = t1.x
AND t3.y (+) = t1.y
AND t4.x = t1.x;
Good...you saved me the trouble of digging out some examples from the
code I'm porting, which occasionally due similar things :)
I think the ANSI SQL 92 equivalent is something like:
select ...
from t1 inner join t4 on t1.x=t4.x,
t2 left outer join t1
on t2.y=t1.y and
(t1.start_date between t2.start_date and t1.start_date),
t3 left outer join t1 on t3.x=t1.x and t3.y = t1.y;
I've never used an ANSI SQL 92 compliant RDBMS, I'm not sure
if t2/t1 become ambiguous and need to be given different names
using "as foo" in each case, etc. Actually, you would in
order to build the target list unambiguously I guess...
But that's the general gist. I think - Thomas, am I at all
close?
Of course, you can continue to write the inner join in the
old way:
select ...
from t1 inner join t2 on t1.x=t2.x;
and
select ...
from t1,t2 where t1.x=t2.x;
where the last form of the inner join might be considered an
optimization of a cross-join restricted by a boolean expression
in the where clause rather than a proper inner join. In other
words, the two queries return the same rows and one would be
very disappointed if the second form formed the cartesian product
of t1 and t2 and then filtered the resulting rows rather than do
an inner join!
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Thu Jan 6 22:23:38 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA95889
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 22:23:15 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA27180;
Thu, 6 Jan 2000 22:22:26 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001070322.WAA27180@candle.pha.pa.us>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with InformixSQL
In-Reply-To: <3.0.1.32.20000106185741.00ed7b6c@mail.pacifier.com> from Don
Baccus at "Jan 6, 2000 06:57:41 pm"
To: Don Baccus <dhogaza@pacifier.com>
Date: Thu, 6 Jan 2000 22:22:26 -0500 (EST)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Rod Chamberlin <rod@querix.com>, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
A bit of a misunderstanding here: we are using SQL92 syntax but will
try to implement the outer join operation using *internal* data
structures similar to what we have now.Yes, I've seen the existing code, in particular regarding inner
joins.Any alternate syntaxes are just a diversion which slow us down on the
road to world domination ;)That's my first feeling, too, as I hope I made clear.
If you don't mind my asking, just what are the difficulties? Bruce
mentioned the optimizer. I noticed the executor code that does
merge joins has conditionalized stuff in it to insert the nulls
required by outer join. And the parser has conditionalized stuff
to deal with them.So, is it ("just", he says :) the optimizer, or more?
OK, let me summarize where we are. Thomas is the man on this.
Thomas is doing the ANSI syntax in gram.y and passing information around
in the parser. We then need code in the executor for Merge/Hash/Nested
Loop joins to do outer joins.
The requirement in the optimizer is to have the _outer_ column always in
the left/outer position in hash/nested loop joins. Mergejoin can have
it either place. The ANSI syntax also specifies the exact join that
gets the outer, and I am not sure how to get that information/control
into the optimizer.
Thomas is now redesigning the parser _outer_ code to pass around the
outer information in a better way than his first cut at the code.
That is where we are. There are many people ready to get involved when
there is a need. I know many want this in 7.0.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 6 22:26:38 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA96338
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 22:26:30 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA27210;
Thu, 6 Jan 2000 22:25:34 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001070325.WAA27210@candle.pha.pa.us>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
In-Reply-To: <3.0.1.32.20000106191842.00ee4ccc@mail.pacifier.com> from Don
Baccus at "Jan 6, 2000 07:18:42 pm"
To: Don Baccus <dhogaza@pacifier.com>
Date: Thu, 6 Jan 2000 22:25:34 -0500 (EST)
CC: "Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'The Hermit Hacker '" <scrappy@hub.org>,
"'Rod Chamberlin '" <rod@querix.com>,
"'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
select ...
from t1 inner join t4 on t1.x=t4.x,
t2 left outer join t1
on t2.y=t1.y and
(t1.start_date between t2.start_date and t1.start_date),
t3 left outer join t1 on t3.x=t1.x and t3.y = t1.y;
Let's be honest, folks. This is almost unreadable. I think we will
need some simpler way to access _outer_ in addition to the ANSI way.
I can't imagine how I would answer a question: "How do I do an ANSI
outer join". It would need its own FAQ page.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 6 19:25:36 2000
Received: from mx02.gis.net ([208.218.130.7])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA58184
for <pgsql-hackers@postgreSQL.org>; Thu, 6 Jan 2000 19:25:08 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from laptop.pacifier.com (nas-2-15.boston.navinet.net [216.67.2.15])
by mx02.gis.net (8.8.8/8.8.8+pyrd) with SMTP id TAA27893;
Thu, 6 Jan 2000 19:20:59 -0500 (EST)
Message-Id: <3.0.1.32.20000106193232.00ee3eb0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 06 Jan 2000 19:32:32 -0800
To: Hannu Krosing <hannu@tm.ee>, "Ansley,
Michael" <Michael.Ansley@intec.co.za>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix
SQL
Cc: "'The Hermit Hacker '" <scrappy@hub.org>,
"'Bruce Momjian '" <pgman@candle.pha.pa.us>,
"'Rod Chamberlin '" <rod@querix.com>,
"'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
In-Reply-To: <3875297A.A2F1DF1E@tm.ee>
References: <1BF7C7482189D211B03F00805F8527F748C3FC@S-NATH-EXCH2>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 01:47 AM 1/7/00 +0200, Hannu Krosing wrote:
IMHO the ANSI standard (as anything designed by a committee) is not always
the
best
way to do things.
Well, generally standards committees don't design features. They're
usually designed by one or two people, then submitted to the committee
for discussion and eventual adoption or rejection.
My understanding from reading Date is that one reason for not adopting
the common vendor hacks for outer joins is that outer joins aren't
associative and the result of complicated expressions in some cases
will depend on the order in which the RDBMS' optimizer chooses to
execute them.
Putting on my compiler-writer hat, I can see where having joins
explicitly declared in the "from" clauses rather than derived from
an analysis of the "from" and "where" clauses might well simplify
the development of a new SQL 92 RDBMS if one were to start from
scratch. It's cleaner, IMO. This doesn't apply to Postgres,
since the outer joins are being shoe-horned into existing data
structures.
Of course, I speak as someone without
a lot of experience writing Oracle or Informix SQL. If you're used
to Oracle, then it's not surprising you find its means of specifying
an outer join the most natural and easiest to understand...
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Thu Jan 6 23:03:22 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA04087
for <pgsql-hackers@postgresql.org>; Thu, 6 Jan 2000 23:01:37 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id AAA00451;
Fri, 7 Jan 2000 00:00:41 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Fri, 7 Jan 2000 00:00:41 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Don Baccus <dhogaza@pacifier.com>,
"Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'Rod Chamberlin '" <rod@querix.com>,
"'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
In-Reply-To: <200001070325.WAA27210@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001070000100.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 6 Jan 2000, Bruce Momjian wrote:
select ...
from t1 inner join t4 on t1.x=t4.x,
t2 left outer join t1
on t2.y=t1.y and
(t1.start_date between t2.start_date and t1.start_date),
t3 left outer join t1 on t3.x=t1.x and t3.y = t1.y;Let's be honest, folks. This is almost unreadable. I think we will
need some simpler way to access _outer_ in addition to the ANSI way.I can't imagine how I would answer a question: "How do I do an ANSI
outer join". It would need its own FAQ page.
How do the "books" talk about JOINs? What is the semi-standard syntax
that is generally used in samples?
From bouncefilter Fri Jan 7 01:39:40 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA38522
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 01:39:30 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id GAA22831;
Fri, 7 Jan 2000 06:47:46 GMT
Sender: lockhart@hub.org
Message-ID: <38758C12.DCD8DAAC@alumni.caltech.edu>
Date: Fri, 07 Jan 2000 06:47:46 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
CC: Bruce Momjian <pgman@candle.pha.pa.us>, Rod Chamberlin <rod@querix.com>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with InformixSQL
References: <Pine.LNX.4.10.10001061220560.14942-100000@shiela.querix.co.uk>
<3.0.1.32.20000106124001.00ed6310@mail.pacifier.com>
<3.0.1.32.20000106185741.00ed7b6c@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
If you don't mind my asking, just what are the difficulties? Bruce
mentioned the optimizer. I noticed the executor code that does
merge joins has conditionalized stuff in it to insert the nulls
required by outer join. And the parser has conditionalized stuff
to deal with them.
The conditional stuff is from my poking at it over the last few
months. OK, the difficulties are (I'll probably leave something out):
1) The parser is written to handle the traditional inner join syntax,
which separates the FROM and WHERE clauses into two distinct pieces.
The outer join syntax (which of course can also do inner joins) has
qualifiers and table and column "aliases" buried down in the FROM
clause, and it is a pain to percolate that back up as it is
transformed by the parser backend.
2) The optimizer usually feels free to try every combination of inner
joins, since they are completely transitive. But outer joins are not:
they need to be done in a specific order since the *absence* of a
match is significant.
3) The executor needs to understand how to expand a left- or
right-side tuple into a null-filled result. I've played with the
mergejoin code and have taught it to walk the tables correctly, but it
needs code added which actually generates the result tuple. And the
other join methods don't know anything about outer joins yet.
Enough?
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Jan 7 01:49:40 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA39542
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 01:48:46 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id GAA22840;
Fri, 7 Jan 2000 06:56:40 GMT
Sender: lockhart@hub.org
Message-ID: <38758E28.D2806B32@alumni.caltech.edu>
Date: Fri, 07 Jan 2000 06:56:40 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
CC: "Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'The Hermit Hacker '" <scrappy@hub.org>,
"'Bruce Momjian '" <pgman@candle.pha.pa.us>,
"'Rod Chamberlin '" <rod@querix.com>,
"'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
References: <3.0.1.32.20000106191842.00ee4ccc@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
SELECT blah, blah, blah
FROM t1, t2, t3, t4
WHERE t1.start_date BETWEEN t2.start_date (+) AND t2.end_date (+)
AND t1.y = t2.y (+)
AND t3.x (+) = t1.x
AND t3.y (+) = t1.y
AND t4.x = t1.x;I think the ANSI SQL 92 equivalent is something like:
select ...
from t1 inner join t4 on t1.x=t4.x,
t2 left outer join t1
on t2.y=t1.y and
(t1.start_date between t2.start_date and t1.start_date),
t3 left outer join t1 on t3.x=t1.x and t3.y = t1.y;
Hmm. I'm not sure what the Oracle example actually gives as a result,
and I find the syntax as confusing as others find SQL92 syntax ;)
I've never used an ANSI SQL 92 compliant RDBMS, I'm not sure
if t2/t1 become ambiguous and need to be given different names
using "as foo" in each case, etc. Actually, you would in
order to build the target list unambiguously I guess...
Once two tables are mentioned in an "outer join", then individual
columns can no longer be qualified by the original table names.
Instead, you are allowed to put table and column aliases on the join
expression:
select a, b, c, z
from (t1 left join t2 using (x)) as j1 (a, b, c)
right join t3 on (j1.a = t3.y);
(I think I have this right; I'm doing it from memory and have been
away from it for a little while).
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Jan 7 02:22:41 2000
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id CAA48926
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 02:22:18 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <ZW4G65KB>; Fri, 7 Jan 2000 09:19:14 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C3FF@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Don Baccus '" <dhogaza@pacifier.com>, "'Hannu Krosing '" <hannu@tm.ee>,
"Ansley, Michael" <Michael.Ansley@intec.co.za>
Cc: "''The Hermit Hacker ' '" <scrappy@hub.org>, "''Bruce Momjian ' '"
<pgman@candle.pha.pa.us>, "''Rod Chamberlin ' '" <rod@querix.com>,
"''pgsql-hackers@postgreSQL.org ' '" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
Date: Fri, 7 Jan 2000 09:06:23 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"
IMHO the ANSI standard (as anything designed by a committee) is not
always
thebest
way to do things.
Hmmm, quite frequently, yes.
< clip >
My understanding from reading Date is that one reason for not adopting
the common vendor hacks for outer joins is that outer joins aren't
associative and the result of complicated expressions in some cases
will depend on the order in which the RDBMS' optimizer chooses to
execute them.
Yes, that was what I thought as well. I'm not sure what the ANSI standard
specifies, but if it's the style used below (which is what Access uses),
then it's not overly complicated, but can be a little difficult to read
sometimes.
Putting on my compiler-writer hat, I can see where having joins
explicitly declared in the "from" clauses rather than derived from
an analysis of the "from" and "where" clauses might well simplify
the development of a new SQL 92 RDBMS if one were to start from
scratch. It's cleaner, IMO. This doesn't apply to Postgres,
since the outer joins are being shoe-horned into existing data
structures.
Does that make any difference?
Of course, I speak as someone without
a lot of experience writing Oracle or Informix SQL. If you're used
to Oracle, then it's not surprising you find its means of specifying
an outer join the most natural and easiest to understand...
Yes, you're probably right. Although, I learnt SQL using Access and SQL
Server, doing the 'A INNER JOIN B ON A.x = B.x' syntax, and I still prefer
Oracle's way of doing it. From the developers point of view, it's pretty
easy to read (mainly because it doesn't clutter your FROM clause). Perhaps
the best would be to implement ANSI outer joins, and then use the rewriter
to allow for the Oracle syntax, or something similar, just to add
readability to the SQL.
MikeA
From bouncefilter Fri Jan 7 02:16:41 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA48368
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 02:15:58 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id HAA22917;
Fri, 7 Jan 2000 07:24:01 GMT
Sender: lockhart@hub.org
Message-ID: <38759491.FD69EE66@alumni.caltech.edu>
Date: Fri, 07 Jan 2000 07:24:01 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: Don Baccus <dhogaza@pacifier.com>,
"Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'The Hermit Hacker '" <scrappy@hub.org>,
"'Rod Chamberlin '" <rod@querix.com>,
"'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
References: <200001070325.WAA27210@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
select ...
from t1 inner join t4 on t1.x=t4.x,
t2 left outer join t1
on t2.y=t1.y and
(t1.start_date between t2.start_date and t1.start_date),
t3 left outer join t1 on t3.x=t1.x and t3.y = t1.y;Let's be honest, folks. This is almost unreadable. I think we will
need some simpler way to access _outer_ in addition to the ANSI way.
Nonsense! Especially since this isn't quite SQL92. Here is an SQL92
query (I think ;) :
select a, b, c
from (t1 left join t2 using (x)) as j1 (a, b)
right join t3 on (j1.a = t3.y);
So you do a left join with t1 and t2, name the resulting intermediate
table and columns, and then do a right join of the result with t3. I
can't see other syntaxes being very much more obvious, particularly
wrt predicting the actual result. Just because a query looks simpler
doesn't necessarily mean that the syntax alway produces a more robust
query.
I can't imagine how I would answer a question: "How do I do an ANSI
outer join". It would need its own FAQ page.
Well, *you're* the one writing the book :))
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Jan 7 02:27:41 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA49486
for <hackers@postgresql.org>; Fri, 7 Jan 2000 02:27:26 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id HAA22990
for <hackers@postgresql.org>; Fri, 7 Jan 2000 07:35:57 GMT
Sender: lockhart@hub.org
Message-ID: <3875975D.9FD6B3C3@alumni.caltech.edu>
Date: Fri, 07 Jan 2000 07:35:57 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgresql.org>
Subject: (OT) Linux limits
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sorry for the off-topic question, but...
I've got a (laptop) system running Mandrake 6.1 which is configured
out of the box to disallow core dumps from users. root is allowed to
increase the size limit (from tcsh, use "limit coredumpsize
unlimited") but users are not allowed to do this for themselves.
Where does one specify this parameter on a system-wide basis? My older
RedHat boxes all have a non-zero limit for this parameter, and allow
setting the limit to infinity by users. Don't know if Mandrake is
configured differently from RH6.1, but until I get this adjusted it
doesn't make a reasonable development machine...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Jan 7 03:13:41 2000
Received: from toa.toasia.co.jp ([210.227.134.242])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA64442
for <pgsql-hackers@postgresql.org>; Fri, 7 Jan 2000 03:13:13 -0500 (EST)
(envelope-from S.Rao@toa.toasia.co.jp)
Received: from Branch1 ([210.227.134.250])
by toa.toasia.co.jp (8.9.1b+Sun/8.9.1) with SMTP id RAA10549
for <pgsql-hackers@postgresql.org>; Fri, 7 Jan 2000 17:07:07 +0900 (JST)
Message-ID: <00fa01bf58e7$a75f6600$9900a8c0@toasia.co.jp>
From: "Shanthala Rao" <S.Rao@toa.toasia.co.jp>
To: <pgsql-hackers@postgresql.org>
Subject: please help
Date: Fri, 7 Jan 2000 17:17:35 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_00F6_01BF5933.16FC4960"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
This is a multi-part message in MIME format.
------=_NextPart_000_00F6_01BF5933.16FC4960
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
I had written a pgm in Java on a Windows m/c
which accesses data from a linux m/c.The database
is stored in the linux m/c.I added postgresql.jar file(from Linux m/c)
for my proj.But when I run the pgm,the following Exception
is displayed.
The postgresql.jar file does not contain the correct
JDBC classes for this JVM.
Try rebuilding.
Exception thrown
java.lang.ClassNotFound Exception.
I want to know is there any JDBC driver for Windows
in postgresql??
If so,would u please let me know where is it available??
Thanking you,
Shanthala.
------=_NextPart_000_00F6_01BF5933.16FC4960
Content-Type: text/html;
charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-2022-jp" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2722.2800" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV>I had written a pgm in Java on a Windows m/c</DIV>
<DIV>which accesses data from a linux m/c.The database</DIV>
<DIV>is stored in the linux m/c.I added postgresql.jar file(from Linux=20
m/c)</DIV>
<DIV>for my proj.But when I run the pgm,the following Exception </DIV>
<DIV>is displayed.</DIV>
<DIV> The postgresql.jar file does not contain the correct</DIV>
<DIV>JDBC classes for this JVM.</DIV>
<DIV>Try rebuilding.</DIV>
<DIV>Exception thrown </DIV>
<DIV> java.lang.ClassNotFound Exception.</DIV>
<DIV>I want to know is there any JDBC driver for Windows</DIV>
<DIV>in postgresql??</DIV>
<DIV> If so,would u please let me know where is it =
available??</DIV>
<DIV> </DIV>
<DIV>Thanking you,</DIV>
<DIV>Shanthala.</DIV>
<DIV> </DIV></DIV></BODY></HTML>
------=_NextPart_000_00F6_01BF5933.16FC4960--
From bouncefilter Fri Jan 7 04:15:43 2000
Received: from cap-ferrat.albourne.com (cap-ferrat.albourne.com
[195.89.178.227]) by hub.org (8.9.3/8.9.3) with ESMTP id EAA84418
for <pgsql-hackers@postgresql.org>; Fri, 7 Jan 2000 04:15:12 -0500 (EST)
(envelope-from a.joubert@albourne.com)
Received: from albourne.com (bishop-rock.albourne.com [195.89.178.230])
by cap-ferrat.albourne.com (8.9.3/8.9.3/Albourne/UKS/2.9/MAPS) with
ESMTP id JAA03510
for <pgsql-hackers@postgresql.org>; Fri, 7 Jan 2000 09:15:06 GMT
Sender: a.joubert@albourne.com
Message-ID: <3875B070.5218EDA4@albourne.com>
Date: Fri, 07 Jan 2000 11:22:56 +0200
From: Adriaan Joubert <a.joubert@albourne.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.38 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] New Search Engine ... UdmSearch
References: <Pine.BSF.4.21.0001061154090.18498-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The Hermit Hacker wrote:
Well, we've finally gotten what seems to be a working version of this
going, and, so far, I'm quite impressed...If you go to http://www.postgresql.org/cgi/search.cgi (URL to change), you
can see it in action.
So I search the hackers mailing list for 'outer join' and get no results. I
search the hackers mailing list for 'join' and still get
Sorry, but search returned no
results.
Try to produce less restrictive
search query.
Am I missing something?
Adriaan
From bouncefilter Fri Jan 7 06:01:43 2000
Received: from shiela.querix.co.uk (sheila.querix.co.uk [212.158.91.227])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA07696
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 06:01:17 -0500 (EST)
(envelope-from rod@querix.com)
Received: from localhost (rod@localhost)
by shiela.querix.co.uk (8.9.3/8.8.7) with ESMTP id KAA30864;
Fri, 7 Jan 2000 10:59:24 GMT
Date: Fri, 7 Jan 2000 10:59:23 +0000 (GMT)
From: Rod Chamberlin <rod@querix.com>
X-Sender: rod@shiela.querix.co.uk
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, Don Baccus <dhogaza@pacifier.com>,
"Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'The Hermit Hacker '" <scrappy@hub.org>,
"'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] SQL outer join syntax
In-Reply-To: <38759491.FD69EE66@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.10.10001071025310.14942-100000@shiela.querix.co.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 7 Jan 2000, Thomas Lockhart wrote:
select ...
from t1 inner join t4 on t1.x=t4.x,
t2 left outer join t1
on t2.y=t1.y and
(t1.start_date between t2.start_date and t1.start_date),
t3 left outer join t1 on t3.x=t1.x and t3.y = t1.y;Let's be honest, folks. This is almost unreadable. I think we will
need some simpler way to access _outer_ in addition to the ANSI way.Nonsense! Especially since this isn't quite SQL92. Here is an SQL92
query (I think ;) :select a, b, c
from (t1 left join t2 using (x)) as j1 (a, b)
right join t3 on (j1.a = t3.y);So you do a left join with t1 and t2, name the resulting intermediate
table and columns, and then do a right join of the result with t3. I
can't see other syntaxes being very much more obvious, particularly
wrt predicting the actual result. Just because a query looks simpler
doesn't necessarily mean that the syntax alway produces a more robust
query.
This always strikes me as very much an each-to-his-own situation. I
generally prefer the oracle syntax myself; whilst there are potential
ambiguities (which oracle gets around by not executing ambiguous queries),
it's cleaner to write.
That said I don't particularly like SQL itself; if I wanted to program
COBOL I'd get a COBOL compiler:). The SQL92 syntax is more of an SQLism
than anything else, and the extra "english" words actually tend to obscure
the details of the join.
It certainly makes sense to use the SQL92 syntax; it is most important to
be compatible with the standards that anything else, but I would still
argue that a more straightforward syntax in parallel is
probably worthwhile.
I can't imagine how I would answer a question: "How do I do an ANSI
outer join". It would need its own FAQ page.Well, *you're* the one writing the book :))
I'd have thought this gave him justtification to complain about your
horrible syntax then:)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
.............................Rod
+-----------------------------------------------------------------------------+
| Rod Chamberlin | rod@querix.com Tel +44 1703 232345 |
| Software Engineer | Mob +44 7803 295406 |
| QueriX | Fax +44 1703 399685 |
+-----------------------------------------------------------------------------+
| The views expressed in this document do not necessarily represent those of |
| the management of QueriX (UK) Ltd. |
+-----------------------------------------------------------------------------+From bouncefilter Fri Jan 7 06:19:51 2000
Received: from shiela.querix.co.uk (sheila.querix.co.uk [212.158.91.227])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA12146
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 06:19:29 -0500 (EST)
(envelope-from rod@querix.com)
Received: from localhost (rod@localhost)
by shiela.querix.co.uk (8.9.3/8.8.7) with ESMTP id LAA31033;
Fri, 7 Jan 2000 11:19:24 GMT
Date: Fri, 7 Jan 2000 11:19:24 +0000 (GMT)
From: Rod Chamberlin <rod@querix.com>
X-Sender: rod@shiela.querix.co.uk
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
In-Reply-To: <200001061812.NAA15830@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.10.10001071101150.14942-100000@shiela.querix.co.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 6 Jan 2000, Bruce Momjian wrote:
[snip]
The move to make MONEY use decimal would add precision.
5/ serial data type
o Serial type must return inserted key valueHow does Informix return the value?
From a user standpoint it mystically appears in sqlca just after the
insert statement is executed. Actually the informix engine recognises
it's just done a serial insert, and sends it back in addition to the
standard status packets.Yes, we have currval() which allows such retrieval _inside_ the
database, as well as in the application.
Yes, but the interface cannot tell what it's operating on, so it doesn't
know to fetch curval; consider the following statement:
insert into mytable values('Hello',0,0,23,17.0,0.0);
Are any of the inserted values insert into serial columns?
You have no way of knowing. In fact any one of the last 5 columsn could
potentially be serial values being inserted (although if it's the third
or forth column we don't need to do any extra processing (*)). In the same
way the interface layer can see the SQL statement and not know if it has
to do any extra work for informix compatibility in terms of fetching the
extra values back from the sequence which Postgres has created for us.
(*) Actually we probably do, since we need to ensure that the sequence
value has passed the inserted value if we do a non-null insert on a serial
column, otherwise we may later regenerate the same serial number.
The above example is a relatively simple one to parse and analyze. A more
complicated case that we'd also probably have to recognise would be
something like
select x,y,z,p+1 from base_table insert into mytable
short of having an SQL parser how are you supposed to determine the
required behaviour?
There are other issues with serial which suggest that better processing is
probably required; they are currently completely useful in the context of
temporary tables, since the underlying sequence is never dropped.
I can understand the situation here (one of the main reasons I raised the
thread in the first place). Above all else the difficulty I have with
serial at the moment is the impossibility of differentiating a serial with
an int4 after creation (after all the database treats them identically).
The catalog tables don't contain any information. The only way you can
work out you created a serial column is by looking for an appropriately
named sequence in the database on every int4 column that exists (or am I
wrong?). This is not exactly something that appeals to meYes, the SERIAL gets lost once it is created. This can cause confusion
because doing a \dt on the table shows it as an INT4 with DEFAULT, and
not a serial. This can confuse people. I remember someone saying we
would need to keep the SERIAL understanding around so we would use it
for pg_dump, but I don't remember why we needed to do that.
This is odd actually. I can't see why you'd need to do it either, since
you must already have the information you need to recreate the thing.
The confusion though is not that I can't work out it's a serial, but
that a program can't work out it's a serial.
.............................Rod
+-----------------------------------------------------------------------------+
| Rod Chamberlin | rod@querix.com Tel +44 1703 232345 |
| Software Engineer | Mob +44 7803 295406 |
| QueriX | Fax +44 1703 399685 |
+-----------------------------------------------------------------------------+
| The views expressed in this document do not necessarily represent those of |
| the management of QueriX (UK) Ltd. |
+-----------------------------------------------------------------------------+From bouncefilter Fri Jan 7 06:22:43 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id GAA12468
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 06:22:01 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 9801 invoked by uid 1001); 7 Jan 2000 11:22:01 -0000
Date: Fri, 7 Jan 2000 06:22:00 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: Adriaan Joubert <a.joubert@albourne.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] New Search Engine ... UdmSearch
In-Reply-To: <3875B070.5218EDA4@albourne.com>
Message-ID: <Pine.BSF.4.05.10001070620470.9662-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 7 Jan 2000, Adriaan Joubert wrote:
The Hermit Hacker wrote:
Well, we've finally gotten what seems to be a working version of this
going, and, so far, I'm quite impressed...If you go to http://www.postgresql.org/cgi/search.cgi (URL to change), you
can see it in action.So I search the hackers mailing list for 'outer join' and get no results. I
search the hackers mailing list for 'join' and still getSorry, but search returned no
results.Try to produce less restrictive
search query.Am I missing something?
No, the database just isn't fully populated yet. Due to the amount of
data that has to go in, it takes a long time to parse.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
From bouncefilter Fri Jan 7 07:56:45 2000
Received: from vulcan.ifnet.com.br (vulcan.ifnet.com.br [200.203.210.18])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA29609
for <pgsql-hackers@postgresql.org>; Fri, 7 Jan 2000 07:55:56 -0500 (EST)
(envelope-from mateus@ifnet.com.br)
Received: from ifnet.com.br (IDENT:root@async-49.56k-ppp-gw-01.ifnet.com.br
[200.203.210.176])
by vulcan.ifnet.com.br (8.9.3/8.9.3) with ESMTP id KAA23093
for <pgsql-hackers@postgresql.org>; Fri, 7 Jan 2000 10:56:15 -0200
Received: (from mateus@localhost) by ifnet.com.br (8.9.3/8.9.3) id KAA04874;
Fri, 7 Jan 2000 10:55:43 -0200
From: Mateus Cordeiro Inssa <mateus@ifnet.com.br>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14453.57935.576229.252586@Blaublau.home.br>
Date: Fri, 7 Jan 2000 10:55:43 -0200 (EDT)
To: pgsql-hackers@postgresql.org
Subject: Inheritance
X-Mailer: VM 6.71 under 21.1 (patch 4) "Arches" XEmacs Lucid
X-Face: "|YUb*(O#,z=WN#Ez3~WeW{ZQ2w<Y/?6t>t-lKh/"d:#gq~!Bl&q+_,z+|KAB1C'oqyF_;
P O=40^mm!nklMDs:aXGjL4C1EcM\yMJsA8:F[9
Hi,
Besides the docs says I can do an "update table*" or "delete table*"
it doesn't work.
Is it intended to work soon ?
I'm in a project with six levels of inheritance and would be easier
if it worked.
[]'s
Mateus Cordeiro Inssa
---------------------
Linux User: 76186 Kernel: 2.3.36
ICQ (Licq): 15243895
---------------------
mateus@ifnet.com.br
mateus@cwb.fnn.net
Fri Jan 7 10:55:42 EDT 2000
From bouncefilter Fri Jan 7 08:00:45 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA29994
for <pgsql-hackers@postgresql.org>; Fri, 7 Jan 2000 07:59:49 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id IAA03865;
Fri, 7 Jan 2000 08:59:54 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Fri, 7 Jan 2000 08:59:53 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Adriaan Joubert <a.joubert@albourne.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] New Search Engine ... UdmSearch
In-Reply-To: <3875B070.5218EDA4@albourne.com>
Message-ID: <Pine.BSF.4.21.0001070858390.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 7 Jan 2000, Adriaan Joubert wrote:
The Hermit Hacker wrote:
Well, we've finally gotten what seems to be a working version of this
going, and, so far, I'm quite impressed...If you go to http://www.postgresql.org/cgi/search.cgi (URL to change), you
can see it in action.So I search the hackers mailing list for 'outer join' and get no results. I
search the hackers mailing list for 'join' and still getSorry, but search returned no
results.Try to produce less restrictive
search query.Am I missing something?
Ya, the note right at the bottom of my announcement that stats that the
database is currently being populated :) Its currently up to 8500+
documents indexed, and pgsql-sql and docs are the ones currently
done...-hackers is next ...
From bouncefilter Fri Jan 7 09:25:46 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA47255
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 09:25:27 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id OAA23532;
Fri, 7 Jan 2000 14:32:59 GMT
Sender: lockhart@hub.org
Message-ID: <3875F91B.F55CA0BA@alumni.caltech.edu>
Date: Fri, 07 Jan 2000 14:32:59 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>
CC: "'Don Baccus '" <dhogaza@pacifier.com>, "'Hannu Krosing '" <hannu@tm.ee>,
"''The Hermit Hacker ' '" <scrappy@hub.org>,
"''Bruce Momjian ' '" <pgman@candle.pha.pa.us>,
"''Rod Chamberlin ' '" <rod@querix.com>,
"''pgsql-hackers@postgreSQL.org ' '" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
References: <1BF7C7482189D211B03F00805F8527F748C3FF@S-NATH-EXCH2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
the best would be to implement ANSI outer joins, and then use the
rewriter to allow for the Oracle syntax, or something similar, just to
add readability to the SQL.
When I tried adding the syntax to gram.y a while ago it gave
shift/reduce errors on the "(+)" fields. I would guess that we would
need to have this become a token in the lexer :((
I'll have the code in gram.y (commented out) when I commit my next
changes for this; someone can play with it if they want.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Jan 7 09:35:46 2000
Received: from druid.net (root@druid.net [216.126.72.98])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA51577
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 09:35:00 -0500 (EST)
(envelope-from darcy@druid.net)
Received: from localhost (1332 bytes) by druid.net
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
(sender: <darcy>) (ident <darcy> using unix)
id <m126aTi-000AVfC@druid.net>
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 09:34:58 -0500 (EST)
(Smail-3.2.0.109 1999-Oct-27 #1 built 1999-Dec-25)
Message-Id: <m126aTi-000AVfC@druid.net>
From: darcy@druid.net (D'Arcy J.M. Cain)
Subject: Re: [HACKERS] [Fwd: Re: First Major Open Source Database]
In-Reply-To: <38752575.FBCD36B1@wgcr.org> from Lamar Owen at "Jan 6,
2000 06:29:57 pm"
To: lamar.owen@wgcr.org (Lamar Owen)
Date: Fri, 7 Jan 2000 09:34:58 -0500 (EST)
Cc: pgsql-hackers@postgreSQL.org
Reply-To: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Thus spake Lamar Owen
[Ok, I've been in touch with the author of the 'First Major Open Source
Database' article. Here's what he wants to do. Let me know what you
think, and correct any misinformation I may have fed him.]
[...]
- University Ingres, developed starting in 1977, qualifies for the
'First Major Open Source Database' honor. Ingres is the direct
ancestor of PostgreSQL.
Not that it is so important but I think that Postgres was a different
project by the same person (Dr. Micheal Stonebraker) so it is probably
more accurate to call them siblings.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.From bouncefilter Fri Jan 7 09:47:47 2000
Received: from shiela.querix.co.uk (sheila.querix.co.uk [212.158.91.227])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA53062
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 09:46:55 -0500 (EST)
(envelope-from rod@querix.com)
Received: from localhost (rod@localhost)
by shiela.querix.co.uk (8.9.3/8.8.7) with ESMTP id OAA32423;
Fri, 7 Jan 2000 14:44:58 GMT
Date: Fri, 7 Jan 2000 14:44:57 +0000 (GMT)
From: Rod Chamberlin <rod@querix.com>
X-Sender: rod@shiela.querix.co.uk
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: "Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'Don Baccus '" <dhogaza@pacifier.com>, "'Hannu Krosing '" <hannu@tm.ee>,
"''The Hermit Hacker ' '" <scrappy@hub.org>,
"''Bruce Momjian ' '" <pgman@candle.pha.pa.us>,
"''pgsql-hackers@postgreSQL.org ' '" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
In-Reply-To: <3875F91B.F55CA0BA@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.10.10001071433520.14942-100000@shiela.querix.co.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 7 Jan 2000, Thomas Lockhart wrote:
the best would be to implement ANSI outer joins, and then use the
rewriter to allow for the Oracle syntax, or something similar, just to
add readability to the SQL.When I tried adding the syntax to gram.y a while ago it gave
shift/reduce errors on the "(+)" fields. I would guess that we would
need to have this become a token in the lexer :((
I'd actually expect a potential reduce/reduce conflict between:
a_expr:
func_name '(' ... ')'
and a_expr '(' '+' ')'
since func_name is a ColID as is a_expr potentially, so the system must
work out whether the ColID reduces to an a_expr when it sees then '('
which it can't do (it needs another token to work that out).
So yes, you probably need a new lexer token.
I'll have the code in gram.y (commented out) when I commit my next
changes for this; someone can play with it if they want.- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
.............................Rod
+-----------------------------------------------------------------------------+
| Rod Chamberlin | rod@querix.com Tel +44 1703 232345 |
| Software Engineer | Mob +44 7803 295406 |
| QueriX | Fax +44 1703 399685 |
+-----------------------------------------------------------------------------+
| The views expressed in this document do not necessarily represent those of |
| the management of QueriX (UK) Ltd. |
+-----------------------------------------------------------------------------+From bouncefilter Fri Jan 7 09:56:46 2000
Received: from cap-ferrat.albourne.com (cap-ferrat.albourne.com
[195.89.178.227]) by hub.org (8.9.3/8.9.3) with ESMTP id JAA54355
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 09:55:56 -0500 (EST)
(envelope-from a.joubert@albourne.com)
Received: from albourne.com (bishop-rock.albourne.com [195.89.178.230])
by cap-ferrat.albourne.com (8.9.3/8.9.3/Albourne/UKS/2.9/MAPS) with
ESMTP id OAA28620; Fri, 7 Jan 2000 14:55:49 GMT
Sender: a.joubert@albourne.com
Message-ID: <38760052.19A00A61@albourne.com>
Date: Fri, 07 Jan 2000 17:03:47 +0200
From: Adriaan Joubert <a.joubert@albourne.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.38 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] New Search Engine ... UdmSearch
References: <Pine.BSF.4.21.0001070858390.18498-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Ya, the note right at the bottom of my announcement that stats that the
database is currently being populated :) Its currently up to 8500+
documents indexed, and pgsql-sql and docs are the ones currently
done...-hackers is next ...
Ooops, sorry, feel a right idiot now.... Let us know when it is all there and I'll
have another look.
Adriaan
From bouncefilter Fri Jan 7 10:24:47 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA61136
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 10:23:56 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id KAA01686
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 10:24:00 -0500
Message-ID: <3876050B.A295141A@wgcr.org>
Date: Fri, 07 Jan 2000 10:23:55 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] [Fwd: Re: First Major Open Source Database]
References: <m126aTi-000AVfC@druid.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"D'Arcy J.M. Cain" wrote:
Thus spake Lamar Owen
[Ok, I've been in touch with the author of the 'First Major Open Source
Database' article. Here's what he wants to do. Let me know what you
think, and correct any misinformation I may have fed him.]
[...]
- University Ingres, developed starting in 1977, qualifies for the
'First Major Open Source Database' honor. Ingres is the direct
ancestor of PostgreSQL.Not that it is so important but I think that Postgres was a different
project by the same person (Dr. Micheal Stonebraker) so it is probably
more accurate to call them siblings.
Hmmmm... You may be right -- I wasn't there (in 1987 I was still a
sophomore in college, and was still hacking my old Z80-based computer).
I was quoting Bruce's History of PostgreSQL document, which states:
"PostgreSQL began as Ingres, developed at the University of California
at
Berkeley(1977-1985). The Ingres code was taken and enhanced by
Relational Technologies/Ingres Corporation, which produced one of the
first commercially successful relational database servers. (Ingres
Corp. was later purchased by Computer Associates.) Also at Berkeley,
Michael Stonebraker lead a team to develop an object-relational database
server
called Postgres(1986-1994). "
Hmmm... On second read, that seems ambiguous. Does anyone know if the
first Postgres codebase included any Ingres code (the criterion for
'ancestry')? Or was Postgres (a play on words anyway -- Ingres used the
QUEL language, others started using SEQUEL (later SQL), Postgres, being
different, used POSTQUEL) a complete rewrite from the ground up?
Not that it is terribly important, but I am interested in accuracy.
The Official Documentation doesn't even mention Ingres in its Short
History chapter.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Fri Jan 7 10:31:46 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA62333
for <hackers@postgresql.org>; Fri, 7 Jan 2000 10:31:02 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA23639;
Fri, 7 Jan 2000 15:39:37 GMT
Sender: lockhart@hub.org
Message-ID: <387608B9.9857EBDB@alumni.caltech.edu>
Date: Fri, 07 Jan 2000 15:39:37 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Oliver Mueschke <o@mueschke.de>
CC: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] (OT) Linux limits
References: <3875975D.9FD6B3C3@alumni.caltech.edu>
<3875A3E8.7D5B0CD6@mueschke.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I've got a (laptop) system running Mandrake 6.1 which is configured
out of the box to disallow core dumps from users. root is allowed to
increase the size limit (from tcsh, use "limit coredumpsize
unlimited") but users are not allowed to do this for themselves.are you looking for /etc/security/limits.conf ?
Thanks for the tip, and it looks like the right thing, but adding
entries for core and rebooting does not help. I then tried upping a
brute-force limit of zero imposed in the daemon startup function in
/etc/rc.d/init.d/functions thinking that inetd or loginout or somesuch
process might need to be higher (since all children inherit these
limits apparently), but that does not seem to help.
It is set to zero in /etc/profile, and commented out in
/etc/csh.cshrc, but afaik anything set at that point should be able to
be set higher later. There is a cryptic comment in /etc/profile saying
that "for bash2 it can't be set higher for user processes", but I
don't know what that's about.
Can someone running a Mandrake6.1 or RH6.1 system take a look at their
system limits (for csh use "limit", for bash use "ulimit -a"). Are
they greater than zero for the coredumpsize??
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Jan 7 10:40:46 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA66671
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 10:40:11 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA02580;
Fri, 7 Jan 2000 10:39:54 -0500 (EST)
To: Mateus Cordeiro Inssa <mateus@ifnet.com.br>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Inheritance
In-reply-to: <14453.57935.576229.252586@Blaublau.home.br>
References: <14453.57935.576229.252586@Blaublau.home.br>
Comments: In-reply-to Mateus Cordeiro Inssa <mateus@ifnet.com.br>
message dated "Fri, 07 Jan 2000 10:55:43 -0200"
Date: Fri, 07 Jan 2000 10:39:54 -0500
Message-ID: <2577.947259594@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Mateus Cordeiro Inssa <mateus@ifnet.com.br> writes:
Besides the docs says I can do an "update table*" or "delete table*"
it doesn't work.
Is it intended to work soon ?
It's on the to-do list, but I don't think anyone is planning to get
around to it for this release. Hard to say when it might happen.
Usually the way these kinds of things work is that someone who
really needs the feature goes in and writes the code for it...
regards, tom lane
From bouncefilter Fri Jan 7 10:42:46 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA67007
for <hackers@postgreSQL.org>; Fri, 7 Jan 2000 10:42:25 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id KAA01745;
Fri, 7 Jan 2000 10:42:14 -0500
Message-ID: <38760951.F7D2C8E4@wgcr.org>
Date: Fri, 07 Jan 2000 10:42:09 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] (OT) Linux limits
References: <3875975D.9FD6B3C3@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas Lockhart wrote:
setting the limit to infinity by users. Don't know if Mandrake is
configured differently from RH6.1, but until I get this adjusted it
doesn't make a reasonable development machine...
My experience has been that starting with version 6.0 Mandrake is
diverging from RedHat. Mandrake 5.3 can properly be called 'RedHat
5.2+KDE+enhancements' -- Mandrake 6.0 and 6.1, being released before
their RedHat counterparts, are not nearly as close.
I tried using Mandrake 6.0 to build RPMs, and quickly replaced it with
RedHat 6.0 -- Mandrake 6.0 used pgcc instead of egcs, for one. Caused
me all manner of grief. Mandrake 6.1 may be better in this regard, but
I am sticking with RedHat for the time being, as it is the current
baseline target of the RPM distribution. From what I understand, the
RedHat binary RPM's still work with Mandrake.
Mandrake is now a full-fledged distribution, not just another RedHat
knock-off.
I'm going to have to get my home machine into a multidevelopment mode,
with RedHat, Caldera, SuSE, and Mandrake multibooting, as each of these
RPM-based distributions is different, although Mandrake and RedHat are
more alike than SuSE and Caldera. Or, you can help me with Mandrake
issues in both the source and binary RPM's, just as I am getting
assistance from others with the Alpha patches, building/installing the
RPM's under SuSE and Caldera, and other architecture (ARM and MIPS come
to mind) issues.
Portability amongst Linux distributions is becoming nearly as big of
issue as portability amongst different Unices.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Fri Jan 7 10:41:46 2000
Received: from hu.tm.ee (isdn-54.uninet.ee [194.204.0.118])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA66781
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 10:40:54 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 0D4F772E4; Fri, 7 Jan 2000 17:45:25 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38760A15.E29A0C8A@tm.ee>
Date: Fri, 07 Jan 2000 17:45:25 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Cc: Lamar Owen <lamar.owen@wgcr.org>
Subject: Re: [HACKERS] [Fwd: Re: First Major Open Source Database]
References: <m126aTi-000AVfC@druid.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"D'Arcy J.M. Cain" wrote:
Thus spake Lamar Owen
[Ok, I've been in touch with the author of the 'First Major Open Source
Database' article. Here's what he wants to do. Let me know what you
think, and correct any misinformation I may have fed him.]
[...]
- University Ingres, developed starting in 1977, qualifies for the
'First Major Open Source Database' honor. Ingres is the direct
ancestor of PostgreSQL.Not that it is so important but I think that Postgres was a different
project by the same person (Dr. Micheal Stonebraker) so it is probably
more accurate to call them siblings.
AFAIK it was a different project that built heavily on Ingres (and Postgres's
query language PostQUEL was an extended version of (University)Ingres' QUEL.
Both were later commercially extended
+ -UniversityIngres(with QUEL) --> Ingres(withSQL)
|
\- Postgres(PostQuel) -+-> Illustra(SQL) -> InformixUDB(SQL)
\-> Postgres95(SQL) -> PostgreSQL(SQL)
So I think that Ancestor is more accurate than Sibling.
------------
Hannu
From bouncefilter Fri Jan 7 10:47:59 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA67767
for <hackers@postgresql.org>; Fri, 7 Jan 2000 10:47:02 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id KAA01774;
Fri, 7 Jan 2000 10:46:59 -0500
Message-ID: <38760A6D.D3F03C31@wgcr.org>
Date: Fri, 07 Jan 2000 10:46:54 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: Oliver Mueschke <o@mueschke.de>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] (OT) Linux limits
References: <3875975D.9FD6B3C3@alumni.caltech.edu>
<3875A3E8.7D5B0CD6@mueschke.de>
<387608B9.9857EBDB@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas Lockhart wrote:
Can someone running a Mandrake6.1 or RH6.1 system take a look at their
system limits (for csh use "limit", for bash use "ulimit -a"). Are
they greater than zero for the coredumpsize??
Mandrake 5.3:
[lowen@www lowen]$ ulimit -a
core file size (blocks) 1000000
data seg size (kbytes) unlimited
file size (blocks) unlimited
max memory size (kbytes) unlimited
stack size (kbytes) 8192
cpu time (seconds) unlimited
max user processes 256
pipe size (512 bytes) 8
open files 256
virtual memory (kbytes) 2105343
[lowen@www lowen]$
RedHat 6.0:
[lowen@backup lowen]$ ulimit -a
core file size (blocks) 1000000
data seg size (kbytes) unlimited
file size (blocks) unlimited
max memory size (kbytes) unlimited
stack size (kbytes) 8192
cpu time (seconds) unlimited
max user processes 256
pipe size (512 bytes) 8
open files 1024
virtual memory (kbytes) 2105343
[lowen@backup lowen]$
RedHat 6.1:
[lowen@utility lowen]$ ulimit -a
core file size (blocks) 1000000
data seg size (kbytes) unlimited
file size (blocks) unlimited
max memory size (kbytes) unlimited
stack size (kbytes) 8192
cpu time (seconds) unlimited
max user processes 2048
pipe size (512 bytes) 8
open files 1024
virtual memory (kbytes) 2105343
[lowen@utility lowen]$
Don't have a Mandrake 6.1 system up.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Fri Jan 7 10:49:47 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA68165
for <hackers@postgresql.org>; Fri, 7 Jan 2000 10:49:42 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id LAA05160;
Fri, 7 Jan 2000 11:49:25 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Fri, 7 Jan 2000 11:49:24 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Oliver Mueschke <o@mueschke.de>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] (OT) Linux limits
In-Reply-To: <387608B9.9857EBDB@alumni.caltech.edu>
Message-ID: <Pine.BSF.4.21.0001071148430.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 7 Jan 2000, Thomas Lockhart wrote:
I've got a (laptop) system running Mandrake 6.1 which is configured
out of the box to disallow core dumps from users. root is allowed to
increase the size limit (from tcsh, use "limit coredumpsize
unlimited") but users are not allowed to do this for themselves.are you looking for /etc/security/limits.conf ?
Thanks for the tip, and it looks like the right thing, but adding
entries for core and rebooting does not help. I then tried upping a
brute-force limit of zero imposed in the daemon startup function in
/etc/rc.d/init.d/functions thinking that inetd or loginout or somesuch
process might need to be higher (since all children inherit these
limits apparently), but that does not seem to help.
Under FreeBSD, we have a similar file: login.conf ... after modifying it,
though, you have to run a command to "compile" it ... do you have
something similar?
From bouncefilter Fri Jan 7 03:08:43 2000
Received: from miranda.herrera.iphil.net
(IDENT:postfix@ip132.herrera.iphil.net [203.176.28.132])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA63259
for <hackers@postgresql.org>; Fri, 7 Jan 2000 03:08:41 -0500 (EST)
(envelope-from nquiogue@ieee.org)
Received: from VPENG (fc-mac.emc.com.ph [203.176.3.11])
by miranda.herrera.iphil.net (Postfix) with SMTP
id 127EF6A; Fri, 7 Jan 2000 16:08:33 +0800 (PHT)
From: "neil d. quiogue" <nquiogue@ieee.org>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Fri, 7 Jan 2000 16:08:29 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: [HACKERS] (OT) Linux limits
Cc: hackers@postgresql.org
Priority: normal
In-reply-to: <3875975D.9FD6B3C3@alumni.caltech.edu>
Message-Id: <20000107080833.127EF6A@miranda.herrera.iphil.net>
Hello Thomas,
Where does one specify this parameter on a system-wide basis? My older
RedHat boxes all have a non-zero limit for this parameter, and allow
setting the limit to infinity by users. Don't know if Mandrake is
configured differently from RH6.1, but until I get this adjusted it
doesn't make a reasonable development machine...
I have Mandrake 6.0 though I think I know your problem. In
/etc/profile, there's an entry there where it limits core dumps to
100000 I think for root. You might want to remove that or make it
unlimited.
Regards,
Neil D. Quiogue
STO - dotPH, Inc.
"Nothing great was ever achieved without enthusiasm."
- Ralph Waldo Emerson
From bouncefilter Fri Jan 7 03:12:41 2000
Received: from miranda.herrera.iphil.net
(IDENT:postfix@ip132.herrera.iphil.net [203.176.28.132])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA64092
for <hackers@postgresql.org>; Fri, 7 Jan 2000 03:11:59 -0500 (EST)
(envelope-from nquiogue@ieee.org)
Received: from VPENG (fc-mac.emc.com.ph [203.176.3.11])
by miranda.herrera.iphil.net (Postfix) with SMTP
id 2D52790; Fri, 7 Jan 2000 16:11:33 +0800 (PHT)
From: "neil d. quiogue" <nquiogue@ieee.org>
To: lockhart@alumni.caltech.edu
Date: Fri, 7 Jan 2000 16:11:22 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: [HACKERS] (OT) Linux limits
Cc: hackers@postgresql.org
Priority: normal
Message-Id: <20000107081133.2D52790@miranda.herrera.iphil.net>
Hello,
I have Mandrake 6.0 though I think I know your problem. In
/etc/profile, there's an entry there where it limits core dumps to
100000 I think for root. You might want to remove that or make it
unlimited.
I forgot.... it's ulimit -c 100000 that's limiting the core dumps.
Regards,
Neil D. Quiogue
STO - dotPH, Inc.
"Nothing great was ever achieved without enthusiasm."
- Ralph Waldo Emerson
From bouncefilter Fri Jan 7 11:33:58 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA80443
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 11:33:28 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA21905;
Fri, 7 Jan 2000 11:23:39 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001071623.LAA21905@candle.pha.pa.us>
Subject: Re: [HACKERS] SQL outer join syntax
In-Reply-To: <Pine.LNX.4.10.10001071025310.14942-100000@shiela.querix.co.uk>
from Rod Chamberlin at "Jan 7, 2000 10:59:23 am"
To: Rod Chamberlin <rod@querix.com>
Date: Fri, 7 Jan 2000 11:23:39 -0500 (EST)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Don Baccus <dhogaza@pacifier.com>,
"Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'The Hermit Hacker '" <scrappy@hub.org>,
"'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I can't imagine how I would answer a question: "How do I do an ANSI
outer join". It would need its own FAQ page.Well, *you're* the one writing the book :))
I'd have thought this gave him justtification to complain about your
horrible syntax then:)
The big problem is that is no Thomas's syntax, but the ANSI syntax, and
there doesn't seem to be any vendor-neutral solution for outer joins
other than the ANSI one.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Jan 7 11:31:47 2000
Received: from clio.trends.ca (root@clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA78599
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 11:31:10 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: from candle.pha.pa.us (s5-03.ppp.op.net [209.152.195.67])
by clio.trends.ca (8.9.3+Sun/8.9.3) with ESMTP id LAA19493
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 11:31:03 -0500 (EST)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA21936;
Fri, 7 Jan 2000 11:29:43 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001071629.LAA21936@candle.pha.pa.us>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
In-Reply-To: <Pine.LNX.4.10.10001071101150.14942-100000@shiela.querix.co.uk>
from Rod Chamberlin at "Jan 7, 2000 11:19:24 am"
To: Rod Chamberlin <rod@querix.com>
Date: Fri, 7 Jan 2000 11:29:43 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Yes, we have currval() which allows such retrieval _inside_ the
database, as well as in the application.Yes, but the interface cannot tell what it's operating on, so it doesn't
know to fetch curval; consider the following statement:insert into mytable values('Hello',0,0,23,17.0,0.0);
Are any of the inserted values insert into serial columns?
You have no way of knowing. In fact any one of the last 5 columsn could
potentially be serial values being inserted (although if it's the third
or forth column we don't need to do any extra processing (*)). In the same
way the interface layer can see the SQL statement and not know if it has
to do any extra work for informix compatibility in terms of fetching the
extra values back from the sequence which Postgres has created for us.(*) Actually we probably do, since we need to ensure that the sequence
value has passed the inserted value if we do a non-null insert on a serial
column, otherwise we may later regenerate the same serial number.
Yes, I see your point, and the fault is that Informix is doing some
special things when 0 is inserted into the SERIAL column type. By doing
defaults and using that, we are being more constent. With the Informix
solution, we are losing information.
It is probably a good argument _not_ to implement the informix
slight-of-hand.
However, I also see your huge problem because we don't document the
SERIAL, and we don't allow zero to trigger a nextval(). Very tough.
Yes, the SERIAL gets lost once it is created. This can cause confusion
because doing a \dt on the table shows it as an INT4 with DEFAULT, and
not a serial. This can confuse people. I remember someone saying we
would need to keep the SERIAL understanding around so we would use it
for pg_dump, but I don't remember why we needed to do that.This is odd actually. I can't see why you'd need to do it either, since
you must already have the information you need to recreate the thing.The confusion though is not that I can't work out it's a serial, but
that a program can't work out it's a serial.
SERIAL was implemented as a nice workaround to prevent people from
defining a sequance and defining a default nextval(). I think I may
have suggested it because of my Informix background.
The issue is that SERIAL is just a shortcut. It doesn't have any
internal representation. It would need one only for pg_dump and for
your use, and I am not sure that is warranted. Other people would have
to agree that keeping the SERIAL as its own type is good.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Jan 7 12:01:04 2000
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA85616
for <pgsql-hackers@postgresql.org>; Fri, 7 Jan 2000 12:00:29 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id LAA39852
for pgsql-hackers@postgresql.org; Fri, 7 Jan 2000 11:39:06 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
Message-ID: <43115C94892D.fwnnur@ppmsb.mil>
From: WalterChristler@ypvwuactgu.gov.tht.net
Subject: .,.IF AOL WAS A CAR..,,
X-Newsgroups: comp.databases.postgresql.hackers
Organization: Associates of WalterChristler@ypvwuactgu.gov
X-No-Archive: yes
Lines: 66
X-Trace: tw12.nn.bcandid.com 947263144 209.246.82.235 (Fri,
07 Jan 2000 09:39:04 MST)
Date: Fri, 07 Jan 2000 16:39:05 GMT
To: pgsql-hackers@postgreSQL.org
1. The AOL car would have a TOP speed of 40 MPH yet have a 200 MPH Speedometer.
2. The AOL car would come equipped with a NEW and fantastic 8-Track tape player.
3. The car would often refuse to start and owners would just expect this and try again later.
4. The windshield would have an extra dark tint to protect the driver from seeing better cars.
5. AOL would sell the same model car year after year and claim it's the NEW model.
6. Every now and then the brakes on the AOL car would just "lock-up" for no apparent reason.
7. The AOL car would have a very plain body style but would have lots'a of pretty colors and lights.
8. The AOL car would have only one door but it would have 5 extra seats for family members.
9. AOL car mechanics would have no experience whatsoever in car repair.
10. If an AOL car owner received 3 parking tickets AOL would take the car off of them.
11. The AOL car would have an AOL Cell phone that can only place calls to other AOL car cell phones.
12. AOL would pass a new car law forbidding AOL car owners from driving near other car dealerships.
13. Younger AOL car drivers would be able to make other peoples AOL cars stall just for fun.
14. It would not be possible to upgrade your AOL car stereo.
15. AOL cars would be forced to use AOL gas that cost 20% more and gave worse mileage.
16. Anytime an AOL car owner saw another AOL car owner he would wonder, M/F/age?
17. It would be common for AOL car owners to divorce just to marry another AOL car owner.
18. AOL car owners would always claim to be older or younger than they really are.
19. AOL cars would come with a steering wheel and AOL would claim no other cars have them.
20. Every time you close the door on the AOL car it would say,"Good-Bye."
A ofr pr ke fk
llea o pzzs kbt yusf
uso etp mqy zeo
lem kjeefv mmdrhm fbwzes oeru kwiof?
Kele slfeei eifp efybmo szrtev pb!
Gdju aii smeucue osbeua lnpep
puai gmsoz nml lxq
fed qs efz pmc kam byhs
bffkw bue pprbde edif naxpb?
O bnlaayn sd ukuunic mlmu ekkfu
pabuf epkue eyi o nfki
lsys xsbn okzbo ucfnu fu
kxf nqsc eab bpb mnps
mmyevp aoeba pyeikh nmk ibmmx zw
sp izkkz mlmb psml iifm!
Llmfgp iqb dlrb fphmr cdm jnk
fn bg ljea qlu jlalb
cdi eelnkle syk uez i olsi
cauiic mwki xsvus jpgm
efqi ceef iabar jyees slr jas?
From bouncefilter Fri Jan 7 11:43:47 2000
Received: from server1.ppc.pims.org (ptr4.skynet.be [194.78.114.4] (may be
forged)) by hub.org (8.9.3/8.9.3) with ESMTP id LAA82906
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 11:43:33 -0500 (EST)
(envelope-from huffmana@ppc.pims.org)
Received: from ppc.pims.org ([207.176.11.63]) by server1.ppc.pims.org
(Netscape Messaging Server 3.6) with ESMTP id AAA139E
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 17:42:08 +0100
Message-ID: <38761703.EC7A4581@ppc.pims.org>
Date: Fri, 07 Jan 2000 17:40:36 +0100
From: "Allan Huffman" <huffmana@ppc.pims.org>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] make JDBC postgresql.jar error
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I'm trying to compile the src/interfaces/jdbc postgresql.jar file but I
get a syntax error (pg 6.5.2):
/bin/sh: syntax error at line 1: '(' unexpected
make: *** [all] Error 2
Funny thing is that I'm under the C shell.....using gcc, Solaris 7 on a
Sparc.
I tried to replace $( ) with ' ' per the instructions but there is some
syntax that I am not familiar with: $$($(JAVA) makeVersion). How should
this look after the replacement?
Really appreciate help. I've developed 3k SLOC under Visual Cafe
(managed to rewrite out all Symantec classes). It's running fine in the
Visual Cafe environment. Now I need to field it under the Netscape
Suitespot server.
Thanks
Allan in Belgium
From bouncefilter Fri Jan 7 11:45:47 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA83113
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 11:44:57 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA22785;
Fri, 7 Jan 2000 11:44:09 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001071644.LAA22785@candle.pha.pa.us>
Subject: Re: [HACKERS] [Fwd: Re: First Major Open Source Database]
In-Reply-To: <m126aTi-000AVfC@druid.net> from "D'Arcy J.M. Cain" at "Jan 7,
2000 09:34:58 am"
To: pgsql-hackers@postgreSQL.org
Date: Fri, 7 Jan 2000 11:44:09 -0500 (EST)
CC: Lamar Owen <lamar.owen@wgcr.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Thus spake Lamar Owen
[Ok, I've been in touch with the author of the 'First Major Open Source
Database' article. Here's what he wants to do. Let me know what you
think, and correct any misinformation I may have fed him.]
[...]
- University Ingres, developed starting in 1977, qualifies for the
'First Major Open Source Database' honor. Ingres is the direct
ancestor of PostgreSQL.Not that it is so important but I think that Postgres was a different
project by the same person (Dr. Micheal Stonebraker) so it is probably
more accurate to call them siblings.
I am told _no_ Ingres code went into Postgres. It was a complete
rewrite.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Jan 7 12:16:48 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA91222
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 12:16:05 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA23509;
Fri, 7 Jan 2000 12:15:31 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001071715.MAA23509@candle.pha.pa.us>
Subject: Re: [HACKERS] [Fwd: Re: First Major Open Source Database]
In-Reply-To: <3876050B.A295141A@wgcr.org> from Lamar Owen at "Jan 7,
2000 10:23:55 am"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Fri, 7 Jan 2000 12:15:31 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
"D'Arcy J.M. Cain" wrote:
Thus spake Lamar Owen
[Ok, I've been in touch with the author of the 'First Major Open Source
Database' article. Here's what he wants to do. Let me know what you
think, and correct any misinformation I may have fed him.]
[...]
- University Ingres, developed starting in 1977, qualifies for the
'First Major Open Source Database' honor. Ingres is the direct
ancestor of PostgreSQL.Not that it is so important but I think that Postgres was a different
project by the same person (Dr. Micheal Stonebraker) so it is probably
more accurate to call them siblings.Hmmmm... You may be right -- I wasn't there (in 1987 I was still a
sophomore in college, and was still hacking my old Z80-based computer).
I was quoting Bruce's History of PostgreSQL document, which states:
"PostgreSQL began as Ingres, developed at the University of California
at
Berkeley(1977-1985). The Ingres code was taken and enhanced by
Relational Technologies/Ingres Corporation, which produced one of the
first commercially successful relational database servers. (Ingres
Corp. was later purchased by Computer Associates.) Also at Berkeley,
Michael Stonebraker lead a team to develop an object-relational database
server
called Postgres(1986-1994). "
Hmmm... On second read, that seems ambiguous. Does anyone know if the
first Postgres codebase included any Ingres code (the criterion for
'ancestry')? Or was Postgres (a play on words anyway -- Ingres used the
QUEL language, others started using SEQUEL (later SQL), Postgres, being
different, used POSTQUEL) a complete rewrite from the ground up?
It was purposely ambiguous.
It did not use any Ingres code, as told to me by Jolly, I think. My
book has Ingres mentioned as an "ancestor" of Postgres.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Jan 7 12:18:54 2000
Received: from carrier.ec-group.com (mail.ec-group.com [206.187.28.242])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA91469
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 12:17:55 -0500 (EST)
(envelope-from bpm@mail.ec-group.com)
Received: from ec-group.com (vlad.ec-group.com [192.168.250.70])
by carrier.ec-group.com (8.8.8+Sun/8.8.8) with ESMTP id LAA08565;
Fri, 7 Jan 2000 11:18:03 -0600 (CST)
Sender: bpm@mail.ec-group.com
Message-ID: <38761F91.8E3A60BD@ec-group.com>
Date: Fri, 07 Jan 2000 11:17:05 -0600
From: Brian P Millett <bpm@mail.ec-group.com>
Organization: Enterprise Consulting Group
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Allan Huffman <huffmana@ppc.pims.org>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] make JDBC postgresql.jar error
References: <38761703.EC7A4581@ppc.pims.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Allan Huffman wrote:
I'm trying to compile the src/interfaces/jdbc postgresql.jar file but I
get a syntax error (pg 6.5.2):
/bin/sh: syntax error at line 1: '(' unexpected
make: *** [all] Error 2
This has bitten me also. I'm using a sparc, solaris 7, bash , gcc version
2.95.2. This is a KLUDGE, but here is a patch that works for BASH:
vlad: diff -w3c Makefile /opt/java/pgsql/Makefile
*** Makefile Wed Jun 23 00:56:17 1999
--- /opt/java/pgsql/Makefile Tue Oct 5 09:20:17 1999
***************
*** 16,21 ****
--- 16,22 ----
JAVADOC = javadoc
RM = rm -f
TOUCH = touch
+ SHELL = /bin/bash # This defines how to compile a java class
.java.class:
--
Brian Millett
Enterprise Consulting Group "Heaven can not exist,
(314) 205-9030 If the family is not eternal"
bpm@ec-group.com F. Ballard Washburn
From bouncefilter Fri Jan 7 13:46:49 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA09392
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 13:46:35 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id NAA02143;
Fri, 7 Jan 2000 13:44:57 -0500
Message-ID: <38763421.6FA59322@wgcr.org>
Date: Fri, 07 Jan 2000 13:44:49 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] [Fwd: Re: First Major Open Source Database]
References: <200001071715.MAA23509@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Hmmm... On second read, that seems ambiguous.
It was purposely ambiguous.
I was afraid of that.
It did not use any Ingres code, as told to me by Jolly, I think. My
book has Ingres mentioned as an "ancestor" of Postgres.
I have e-mailed Doc again, asking him to remove the 'direct' in the line
'Ingres was the direct ancestor of PostgreSQL' -- direct implies, IMO,
shared code. Thanks for clarifying, Bruce...
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Fri Jan 7 15:44:51 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA36252
for <pgsql-hackers@postgresql.org>; Fri, 7 Jan 2000 15:44:12 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA07970
for <pgsql-hackers@postgresql.org>; Fri, 7 Jan 2000 16:44:16 -0400 (AST)
(envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Fri, 7 Jan 2000 16:44:16 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: Table drop that fails ... "No such file or directory"
Message-ID: <Pine.BSF.4.21.0001071640510.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Just has a support call where the client couldn't drop a table, giving him
a 'No such file or directory' error...yet a \d showed him that the table
existed...
To "fix" the problem, we got him to shutdown his server, touch the file
that it says is missing, bring the server back up and then drop
it...which, of course, succeeded...
But...does it make sense to error-out in this case? The user wants to get
rid of the table, the table is already gone physically, just not
virtually...so why not just get rid of the virtual entries also?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Fri Jan 7 16:03:51 2000
Received: from druid.net (root@druid.net [216.126.72.98])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA41874
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 16:03:34 -0500 (EST)
(envelope-from darcy@druid.net)
Received: from localhost (1382 bytes) by druid.net
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
(sender: <darcy>) (ident <darcy> using unix)
id <m126gXb-000AVgC@druid.net>
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 16:03:23 -0500 (EST)
(Smail-3.2.0.109 1999-Oct-27 #1 built 1999-Dec-25)
Message-Id: <m126gXb-000AVgC@druid.net>
From: darcy@druid.net (D'Arcy J.M. Cain)
Subject: Re: [HACKERS] [Fwd: Re: First Major Open Source Database]
In-Reply-To: <38763421.6FA59322@wgcr.org> from Lamar Owen at "Jan 7,
2000 01:44:49 pm"
To: lamar.owen@wgcr.org (Lamar Owen)
Date: Fri, 7 Jan 2000 16:03:23 -0500 (EST)
Cc: pgman@candle.pha.pa.us (Bruce Momjian), pgsql-hackers@postgreSQL.org
Reply-To: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Thus spake Lamar Owen
Bruce Momjian wrote:
It did not use any Ingres code, as told to me by Jolly, I think. My
book has Ingres mentioned as an "ancestor" of Postgres.I have e-mailed Doc again, asking him to remove the 'direct' in the line
'Ingres was the direct ancestor of PostgreSQL' -- direct implies, IMO,
shared code. Thanks for clarifying, Bruce...
I still think that since there is no shared code you can't say that
Ingres was the parent to Postgres, more like an older brother. Guess
that makes Ingres PostgreSQL's great uncle. :-)
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.From bouncefilter Fri Jan 7 16:06:51 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA42191
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 16:06:17 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
QAA02790;
Fri, 7 Jan 2000 16:05:36 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001072105.QAA02790@candle.pha.pa.us>
Subject: Re: [HACKERS] Table drop that fails ... "No such file or directory"
In-Reply-To: <Pine.BSF.4.21.0001071640510.18498-100000@thelab.hub.org> from
The
Hermit Hacker at "Jan 7, 2000 04:44:16 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Fri, 7 Jan 2000 16:05:36 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Just has a support call where the client couldn't drop a table, giving him
a 'No such file or directory' error...yet a \d showed him that the table
existed...To "fix" the problem, we got him to shutdown his server, touch the file
that it says is missing, bring the server back up and then drop
it...which, of course, succeeded...But...does it make sense to error-out in this case? The user wants to get
rid of the table, the table is already gone physically, just not
virtually...so why not just get rid of the virtual entries also?
It shows something very strange happened to him. We don't want this
kind of thing to just happen.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Jan 7 16:14:53 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA43347
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 16:14:10 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA08228;
Fri, 7 Jan 2000 17:13:50 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Fri, 7 Jan 2000 17:13:50 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Table drop that fails ... "No such file or directory"
In-Reply-To: <200001072105.QAA02790@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001071711000.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 7 Jan 2000, Bruce Momjian wrote:
But...does it make sense to error-out in this case? The user wants to get
rid of the table, the table is already gone physically, just not
virtually...so why not just get rid of the virtual entries also?It shows something very strange happened to him. We don't want this
kind of thing to just happen.
Okay...what should be done? How do you trace something like this back?
The scenario for this particular table, as it was explained to me, was
that its the result of a join of two other tables...they find that its
easier to do teh join into one table periodically and use that for
selects, then doing SELECT/JOINS on the fly ... my thought was that what
may have happened is they ran out of disk space on the JOIN, the file was
removed, but not the traces in the systems files, is this a possibility?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Fri Jan 7 16:31:51 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA46326
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 16:31:13 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
QAA03204;
Fri, 7 Jan 2000 16:16:26 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001072116.QAA03204@candle.pha.pa.us>
Subject: Re: [HACKERS] Table drop that fails ... "No such file or directory"
In-Reply-To: <Pine.BSF.4.21.0001071711000.18498-100000@thelab.hub.org> from
The
Hermit Hacker at "Jan 7, 2000 05:13:50 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Fri, 7 Jan 2000 16:16:26 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Fri, 7 Jan 2000, Bruce Momjian wrote:
But...does it make sense to error-out in this case? The user wants to get
rid of the table, the table is already gone physically, just not
virtually...so why not just get rid of the virtual entries also?It shows something very strange happened to him. We don't want this
kind of thing to just happen.Okay...what should be done? How do you trace something like this back?
That is the big question. We need to hear about these problems, because
the represent something very strange happening. Somehow, the physical
table was deleted, but it still existed in the system tables.
The scenario for this particular table, as it was explained to me, was
that its the result of a join of two other tables...they find that its
easier to do teh join into one table periodically and use that for
selects, then doing SELECT/JOINS on the fly ... my thought was that what
may have happened is they ran out of disk space on the JOIN, the file was
removed, but not the traces in the systems files, is this a possibility?
Maybe a SELECT INTO failed. You would think it could delete the entries
too, or at least the transaction that created the table would be marked
as aborted.
Not sure how to debug that one.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Jan 7 16:17:51 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA43997
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 16:17:42 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA08314;
Fri, 7 Jan 2000 17:17:52 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Fri, 7 Jan 2000 17:17:52 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgreSQL.org
cc: Lamar Owen <lamar.owen@wgcr.org>, Bruce Momjian <pgman@candle.pha.pa.us>
Subject: Re: [HACKERS] [Fwd: Re: First Major Open Source Database]
In-Reply-To: <m126gXb-000AVgC@druid.net>
Message-ID: <Pine.BSF.4.21.0001071717081.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 7 Jan 2000, D'Arcy J.M. Cain wrote:
I still think that since there is no shared code you can't say that
Ingres was the parent to Postgres, more like an older brother. Guess
that makes Ingres PostgreSQL's great uncle. :-)
Stupid question...does it *really* matter? :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Fri Jan 7 16:21:51 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA44588
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 16:21:16 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id QAA02586;
Fri, 7 Jan 2000 16:21:23 -0500
Message-ID: <387658C9.81ED5DCE@wgcr.org>
Date: Fri, 07 Jan 2000 16:21:13 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
CC: Bruce Momjian <pgman@candle.pha.pa.us>
Subject: Re: [HACKERS] [Fwd: Re: First Major Open Source Database]
References: <m126gXb-000AVgC@druid.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"D'Arcy J.M. Cain" wrote:
I have e-mailed Doc again, asking him to remove the 'direct' in the line
'Ingres was the direct ancestor of PostgreSQL' -- direct implies, IMO,
shared code. Thanks for clarifying, Bruce...
I still think that since there is no shared code you can't say that
Ingres was the parent to Postgres, more like an older brother. Guess
that makes Ingres PostgreSQL's great uncle. :-)
ROTFL
The guys at Linux Journal are very apologetic that they overlooked
PostgreSQL -- if the consensus is to change from 'ancestor' to some
other usage (maybe step-ancestor??), then they can do it -- it's not set
in stone.
I personally am comfortable with 'ancestor' in this usage -- there are
instances of where a program was completely rewritten and only a version
number change happened, even with no shared codebase (the webserver
logfile analyzer 'analog' has had this happen more than once -- in
particular, the code was completely rewritten from scratch between
version 2.11 and 3.0. Analog 3.0 shares no code at all with analog 2.11
-- not necessarily the best software design, but, it's Steven's codebase
to play with.).
It's like the relationship between the CERN, NCSA, and Apache
webservers.
They will be at least giving credit where credit is due (like you said,
it's not a major point).
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Fri Jan 7 13:51:49 2000
Received: from mx01.gis.net ([208.218.130.25])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA10142
for <pgsql-hackers@postgresql.org>; Fri, 7 Jan 2000 13:51:41 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from laptop.pacifier.com (nas-45-147.boston.navinet.net
[216.67.45.147]) by mx01.gis.net (8.8.8/8.8.8+pyrd) with SMTP
id NAA20364; Fri, 7 Jan 2000 13:46:42 -0500 (EST)
Message-Id: <3.0.1.32.20000107133552.00ee2b44@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 07 Jan 2000 13:35:52 -0800
To: The Hermit Hacker <scrappy@hub.org>,
Bruce Momjian <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix
SQL
Cc: "Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'Rod Chamberlin '" <rod@querix.com>,
"'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgresql.org>
In-Reply-To: <Pine.BSF.4.21.0001070000100.18498-100000@thelab.hub.org>
References: <200001070325.WAA27210@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 12:00 AM 1/7/00 -0400, The Hermit Hacker wrote:
On Thu, 6 Jan 2000, Bruce Momjian wrote:
select ...
from t1 inner join t4 on t1.x=t4.x,
t2 left outer join t1
on t2.y=t1.y and
(t1.start_date between t2.start_date and t1.start_date),
t3 left outer join t1 on t3.x=t1.x and t3.y = t1.y;Let's be honest, folks. This is almost unreadable. I think we will
need some simpler way to access _outer_ in addition to the ANSI way.
Well...it took a minute to digest the Oracle version, too. Most joins
are far simpler than the example.
How do the "books" talk about JOINs? What is the semi-standard syntax
that is generally used in samples?
"SQL for smarties" gives examples of vendor-specific syntax then talks
about outer joins more abstractly. It also points out that the existing
vendor solutions have weaknesses.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Fri Jan 7 13:51:51 2000
Received: from mx01.gis.net ([208.218.130.25])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA10155
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 13:51:49 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from laptop.pacifier.com (nas-45-147.boston.navinet.net
[216.67.45.147]) by mx01.gis.net (8.8.8/8.8.8+pyrd) with SMTP
id NAA20383; Fri, 7 Jan 2000 13:47:03 -0500 (EST)
Message-Id: <3.0.1.32.20000107134558.00eda13c@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 07 Jan 2000 13:45:58 -0800
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix
SQL
Cc: "Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'The Hermit Hacker '" <scrappy@hub.org>,
"'Bruce Momjian '" <pgman@candle.pha.pa.us>,
"'Rod Chamberlin '" <rod@querix.com>,
"'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
In-Reply-To: <38758E28.D2806B32@alumni.caltech.edu>
References: <3.0.1.32.20000106191842.00ee4ccc@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 06:56 AM 1/7/00 +0000, Thomas Lockhart wrote:
Hmm. I'm not sure what the Oracle example actually gives as a result,
and I find the syntax as confusing as others find SQL92 syntax ;)
Me too :) As I pointed out in an earlier message, fortunately most
of the outer join examples I've seen are simpler, and more readable
in either style.
Thanks, BTW, for the status update, it's about what I gathered from
looking at the code.
Once two tables are mentioned in an "outer join", then individual
columns can no longer be qualified by the original table names.
Instead, you are allowed to put table and column aliases on the join
expression:select a, b, c, z
from (t1 left join t2 using (x)) as j1 (a, b, c)
right join t3 on (j1.a = t3.y);(I think I have this right; I'm doing it from memory and have been
away from it for a little while).
Yeah, I think this is right, I'd seen in the syntax where a general
table reference can be a join and hadn't thought about being able
to table alias the entire result. This is useful, actually. Without
the column aliases something like:
select j1.a, j1.b, j2.foo ...
makes it clear as to which join a column comes from. This clarity's
often lacking in the Oracle-style queries, as I've noticed when I
decipher them during my port-to-Postgres work. You need to unwind
what comes from where, and often have to look at the data model to
figure it out if the names are unique to the different tables and
not fully qualified as "table_name.column_name".
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Fri Jan 7 16:59:52 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA52353
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 16:59:28 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA08772;
Fri, 7 Jan 2000 17:59:25 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Fri, 7 Jan 2000 17:59:25 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Table drop that fails ... "No such file or directory"
In-Reply-To: <200001072116.QAA03204@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001071756010.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 7 Jan 2000, Bruce Momjian wrote:
On Fri, 7 Jan 2000, Bruce Momjian wrote:
But...does it make sense to error-out in this case? The user wants to get
rid of the table, the table is already gone physically, just not
virtually...so why not just get rid of the virtual entries also?It shows something very strange happened to him. We don't want this
kind of thing to just happen.Okay...what should be done? How do you trace something like this back?
That is the big question. We need to hear about these problems, because
the represent something very strange happening. Somehow, the physical
table was deleted, but it still existed in the system tables.
Hmmm...problem is, I would think, in most cases it wouldn't be noticed
until a later time, this case as an example...
The scenario for this particular table, as it was explained to me, was
that its the result of a join of two other tables...they find that its
easier to do teh join into one table periodically and use that for
selects, then doing SELECT/JOINS on the fly ... my thought was that what
may have happened is they ran out of disk space on the JOIN, the file was
removed, but not the traces in the systems files, is this a possibility?Maybe a SELECT INTO failed. You would think it could delete the entries
too, or at least the transaction that created the table would be marked
as aborted.
Or it could be nothing more then a hard crash of the server :(
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Fri Jan 7 17:02:54 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA53278
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 17:02:09 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
RAA04687;
Fri, 7 Jan 2000 17:01:32 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001072201.RAA04687@candle.pha.pa.us>
Subject: Re: [HACKERS] Table drop that fails ... "No such file or directory"
In-Reply-To: <Pine.BSF.4.21.0001071756010.18498-100000@thelab.hub.org> from
The
Hermit Hacker at "Jan 7, 2000 05:59:25 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Fri, 7 Jan 2000 17:01:32 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
The scenario for this particular table, as it was explained to me, was
that its the result of a join of two other tables...they find that its
easier to do teh join into one table periodically and use that for
selects, then doing SELECT/JOINS on the fly ... my thought was that what
may have happened is they ran out of disk space on the JOIN, the file was
removed, but not the traces in the systems files, is this a possibility?Maybe a SELECT INTO failed. You would think it could delete the entries
too, or at least the transaction that created the table would be marked
as aborted.Or it could be nothing more then a hard crash of the server :(
That could not mark the transaction that completed the table as
committed.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Jan 7 17:22:54 2000
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA58206
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 17:22:37 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <ZW4G659C>; Sat, 8 Jan 2000 00:19:24 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C40D@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Bruce Momjian '" <pgman@candle.pha.pa.us>, "'Rod Chamberlin '"
<rod@querix.com>
Cc: "'Thomas Lockhart '" <lockhart@alumni.caltech.edu>, "'Don Baccus '"
<dhogaza@pacifier.com>, "Ansley, Michael" <Michael.Ansley@intec.co.za>,
"''The Hermit Hacker ' '" <scrappy@hub.org>,
"''pgsql-hackers@postgreSQL.org ' '" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] SQL outer join syntax
Date: Sat, 8 Jan 2000 00:08:53 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"
I don't think there is any question about implementing ANSI syntax for outer
joins. There are two compelling reasons for this:
a) it is a stated goal of the PostgreSQL project to be ANSI compliant, and
to be a testbed for new ANSI features (this implies adherence to ANSI before
you can go extending it with new features)
b) it seems to be the most accurate (if not the prettiest) way of specifying
an outer join
For these reasons, ANSI should be used for the implementation. If, however,
we manage to provide a second, short-cut method for getting the same result,
so be it. However, this then begs the question: which short method to use.
Well, I propose that once outer joins have been implemented (using ANSI
syntax, many thanks to Bruce and Thomas) we have a quick vote to see what
people like, and whoever feels like implementing it can go for it. I would
also suggest that only one short method is used, because otherwise we'll
land up having to support n different syntaxes, each of which is not widely
enough used to justify the work.
MikeA
-----Original Message-----
From: Bruce Momjian
To: Rod Chamberlin
Cc: Thomas Lockhart; Don Baccus; Ansley, Michael; 'The Hermit Hacker ';
'pgsql-hackers@postgreSQL.org '
Sent: 1/7/00 6:23 PM
Subject: Re: [HACKERS] SQL outer join syntax
I can't imagine how I would answer a question: "How do I do an
ANSI
outer join". It would need its own FAQ page.
Well, *you're* the one writing the book :))
I'd have thought this gave him justtification to complain about your
horrible syntax then:)
The big problem is that is no Thomas's syntax, but the ANSI syntax, and
there doesn't seem to be any vendor-neutral solution for outer joins
other than the ANSI one.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania
19026From bouncefilter Fri Jan 7 18:36:55 2000
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA78391
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 18:36:36 -0500 (EST)
(envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id IAA00960; Sat, 08 Jan 2000 08:36:22 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "The Hermit Hacker" <scrappy@hub.org>,
"Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Table drop that fails ... "No such file or directory"
Date: Sat, 8 Jan 2000 08:41:47 +0900
Message-ID: <000001bf5968$c2fb8e80$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <Pine.BSF.4.21.0001071756010.18498-100000@thelab.hub.org>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of The Hermit
HackerOn Fri, 7 Jan 2000, Bruce Momjian wrote:
On Fri, 7 Jan 2000, Bruce Momjian wrote:
But...does it make sense to error-out in this case? The
user wants to get
rid of the table, the table is already gone physically, just not
virtually...so why not just get rid of the virtual entries also?It shows something very strange happened to him. We don't want this
kind of thing to just happen.Okay...what should be done? How do you trace something like
this back?
That is the big question. We need to hear about these problems, because
the represent something very strange happening. Somehow, the physical
table was deleted, but it still existed in the system tables.Hmmm...problem is, I would think, in most cases it wouldn't be noticed
until a later time, this case as an example...
Isn't it the result of a DROP TABLE failure ?
mdunlink() removes the base file of a relation immediately and
the file couldn't be rollbacked in case of abort.
I have already made it possible to DROP TABLE even though there
aren't base files of relation/indexes in current tree 2 months ago.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Fri Jan 7 20:14:55 2000
Received: from corvette.mascari.com (dhcp26131045.columbus.rr.com
[24.26.131.45]) by hub.org (8.9.3/8.9.3) with ESMTP id UAA99081
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 20:14:42 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.9.3/8.9.3) with ESMTP id UAA05340;
Fri, 7 Jan 2000 20:12:00 -0500
Message-ID: <38768EAA.BA03AA85@mascari.com>
Date: Fri, 07 Jan 2000 20:11:06 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Hiroshi Inoue <Inoue@tpf.co.jp>
CC: The Hermit Hacker <scrappy@hub.org>,
Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Table drop that fails ... "No such file or directory"
References: <000001bf5968$c2fb8e80$2801007e@tpf.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hiroshi Inoue wrote:
That is the big question. We need to hear about these problems, because
the represent something very strange happening. Somehow, the physical
table was deleted, but it still existed in the system tables.Hmmm...problem is, I would think, in most cases it wouldn't be noticed
until a later time, this case as an example...Isn't it the result of a DROP TABLE failure ?
mdunlink() removes the base file of a relation immediately and
the file couldn't be rollbacked in case of abort.I have already made it possible to DROP TABLE even though there
aren't base files of relation/indexes in current tree 2 months ago.Regards.
Hiroshi Inoue
Sounds like it was caused by DDL statements in aborted
transactions to me....
Mike (implicit commit, again) Mascari
From bouncefilter Fri Jan 7 21:51:56 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA18386
for <pgsql-hackers@postgreSQL.org>; Fri, 7 Jan 2000 21:51:50 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id DAA28137;
Sat, 8 Jan 2000 03:00:00 GMT
Sender: lockhart@hub.org
Message-ID: <3876A830.872791DF@alumni.caltech.edu>
Date: Sat, 08 Jan 2000 03:00:00 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: Lamar Owen <lamar.owen@wgcr.org>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] [Fwd: Re: First Major Open Source Database]
References: <200001071715.MAA23509@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
It did not use any Ingres code, as told to me by Jolly, I think. My
book has Ingres mentioned as an "ancestor" of Postgres.
I suppose we could have figured this out ourselves, since Postgres was
originally written in Lisp, and afaik Ingres was always C or somesuch
traditional compiled-only code. We still see evidence of this in our
code tree with the way lists and parser nodes are handled.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Sat Jan 8 00:38:02 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA60632
for <pgsql-hackers@postgreSQL.org>; Sat, 8 Jan 2000 00:37:59 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA05355;
Sat, 8 Jan 2000 00:37:30 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Historical trivia (was Re: First Major Open Source Database)
In-reply-to: <3876A830.872791DF@alumni.caltech.edu>
References: <200001071715.MAA23509@candle.pha.pa.us>
<3876A830.872791DF@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Sat, 08 Jan 2000 03:00:00 +0000"
Date: Sat, 08 Jan 2000 00:37:30 -0500
Message-ID: <5352.947309850@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
It did not use any Ingres code, as told to me by Jolly, I think. My
book has Ingres mentioned as an "ancestor" of Postgres.
I suppose we could have figured this out ourselves, since Postgres was
originally written in Lisp, and afaik Ingres was always C or somesuch
traditional compiled-only code. We still see evidence of this in our
code tree with the way lists and parser nodes are handled.
It's clear from both the comments and remnants of coding conventions
that the planner/optimizer was originally Lisp code, and was hand-
translated to C at some point in the dim mists of prehistory (early
1990s, possibly ;-)). That Lisp heritage is responsible for some of
the better things about the code, and also some of the worse things.
But I'm not sure I believe that *all* of the code was originally
Lisp. I've never heard of a Lisp interface for yacc-generated
parsers, for example. The parts of the executor I've looked at
don't seem nearly as Lispy as the parser/planner/optimizer, either.
So it seems possible that parts of Postgres were written afresh in
Lisp while other parts were lifted from an older C implementation.
</idle speculation>
Does anyone here still recall the origins of Postgres? I'm curious
to know more about the history of this beast.
regards, tom lane