Problems compiling latest CVS sources.
============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================
Your name : Billy G. Allie
Your email address : Bill.Allie@mug.org
System Configuration
---------------------
Architecture (example: Intel Pentium) : Intel Pentium
Operating System (example: Linux 2.0.26 ELF) : UnixWare 7.0.1
PostgreSQL version (example: PostgreSQL-6.5.1): PostgreSQL-6.6
Compiler used (example: gcc 2.8.0) : SCO UDK
Please enter a FULL description of your problem:
------------------------------------------------
1. ecpg fails to link. The error message is:
Undefined first referenced
symbol in file
nocachegetattr pgc.o
2. trigger.c fails to compile due to a syntax error. It contains
a switch statement that has an empty default label. A label of a
switch statement must be followed by a statement (or a label which
is followed by a statement (or a label which ...)).
3. Files include stringinfo.h failed to compile. The macro,
'appendStringInfoCharMacro' is implemented with a '?:' operation
that returns a void expression for the true part and a char expresion
for the false part. Both the true and false parts of the '?:' oper-
ator must return the same type.
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
----------------------------------------------------------------------
1. Compile ecpg.
2. Compile with a ANSI C compiler that enforces the standard :->
3. Compile with an ANSI C compiler that enforces the standard :->
If you know how this problem might be fixed, list the solution below:
---------------------------------------------------------------------
1. Don't know.
2. Apply the attached patch.
3. Apply the attached patch.
Attachments:
uw720000213.patchapplication/x-patch; name=uw720000213.patchDownload
*** src/backend/commands/trigger.c.orig Tue Feb 8 23:12:45 2000
--- src/backend/commands/trigger.c Tue Feb 8 23:12:51 2000
***************
*** 1201,1208 ****
SaveTriggerData.tg_trigger =
rel->trigdesc->tg_after_row[TRIGGER_EVENT_DELETE][itemno];
break;
-
- default:
}
/* ----------
--- 1201,1206 ----
*** src/include/lib/stringinfo.h.orig Tue Feb 8 23:11:15 2000
--- src/include/lib/stringinfo.h Tue Feb 8 23:11:33 2000
***************
*** 98,104 ****
#define appendStringInfoCharMacro(str,ch) \
(((str)->len + 1 >= (str)->maxlen) ? \
appendStringInfoChar(str, ch) : \
! ((str)->data[(str)->len] = (ch), (str)->data[++(str)->len] = '\0'))
/*------------------------
* appendBinaryStringInfo
--- 98,104 ----
#define appendStringInfoCharMacro(str,ch) \
(((str)->len + 1 >= (str)->maxlen) ? \
appendStringInfoChar(str, ch) : \
! (void)((str)->data[(str)->len] = (ch), (str)->data[++(str)->len] = '\0'))
/*------------------------
* appendBinaryStringInfo
Applied.
-- Start of PGP signed section.
============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================Your name : Billy G. Allie
Your email address : Bill.Allie@mug.orgSystem Configuration
---------------------
Architecture (example: Intel Pentium) : Intel PentiumOperating System (example: Linux 2.0.26 ELF) : UnixWare 7.0.1
PostgreSQL version (example: PostgreSQL-6.5.1): PostgreSQL-6.6
Compiler used (example: gcc 2.8.0) : SCO UDK
Please enter a FULL description of your problem:
------------------------------------------------
1. ecpg fails to link. The error message is:Undefined first referenced
symbol in file
nocachegetattr pgc.o2. trigger.c fails to compile due to a syntax error. It contains
a switch statement that has an empty default label. A label of a
switch statement must be followed by a statement (or a label which
is followed by a statement (or a label which ...)).3. Files include stringinfo.h failed to compile. The macro,
'appendStringInfoCharMacro' is implemented with a '?:' operation
that returns a void expression for the true part and a char expresion
for the false part. Both the true and false parts of the '?:' oper-
ator must return the same type.Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
----------------------------------------------------------------------
1. Compile ecpg.2. Compile with a ANSI C compiler that enforces the standard :->
3. Compile with an ANSI C compiler that enforces the standard :->
If you know how this problem might be fixed, list the solution below:
---------------------------------------------------------------------
1. Don't know.2. Apply the attached patch.
3. Apply the attached patch.
Content-Description: uw720000213.patch
[Attachment, skipping...]
____ | Billy G. Allie | Domain....: Bill.Allie@mug.org
| /| | 7436 Hartwell | Compuserve: 76337,2061
|-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
|/ |LLIE | (313) 582-1540 |
-- End of PGP section, PGP failed!
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Sun Feb 13 10:04:30 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA66682
for <pgsql-hackers@postgreSQL.org>;
Sun, 13 Feb 2000 10:03:49 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA21295;
Sun, 13 Feb 2000 07:02:55 -0800 (PST)
Message-Id: <3.0.1.32.20000213065137.010c8060@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 13 Feb 2000 06:51:37 -0800
To: Chris <chris@bitmead.com>, pgsql-hackers@postgreSQL.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
In-Reply-To: <38A69E67.AB2944D0@bitmead.com>
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.5.32.20000211163810.035e1aa0@mail.rhyme.com.au>
<38A3A8FB.5A9C556D@nimrod.itg.telecom.com.au>
<19423.950281199@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 11:07 PM 2/13/00 +1100, Chris wrote:
Tom Lane wrote:
SELECT * FROM table WHERE x > 100 ORDER BY x LIMIT 1;
Could it _ever_ be faster to sort the tuples when there is already an
index that can provide them in sorted order?
That's yet another optimization. Working on optimizing the execution
of language constructs, whether statement oriented like C or set
oriented like SQL, is largely a matter of accretion. Just because
you can make the case with index run fast doesn't mean you don't
want to consider the case where an index isn't available.
I think you're on the losing end of this one, Chris. In essence
you're asking that the optimizer not take advantage of the
set-oriented, non-ordered nature of SQL queries in order to make
your non-portable code easier to right.
Tom's example is only one instance where fully exploiting the
fact that values returned by queries are unordered. I don't think
we can really live with the restriction that queries must always
return tuples in the same order.
- 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 Sun Feb 13 11:17:31 2000
Received: from hu.tm.ee (ppp820.tele2.ee [212.107.37.120])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA76443
for <pgsql-hackers@postgresql.org>;
Sun, 13 Feb 2000 11:17:13 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 895DD3B49; Sun, 13 Feb 2000 18:24:59 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38A6DADB.D355E3C9@tm.ee>
Date: Sun, 13 Feb 2000 18:24:59 +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: Chris <chris@bitmead.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.5.32.20000211163810.035e1aa0@mail.rhyme.com.au>
<38A3A8FB.5A9C556D@nimrod.itg.telecom.com.au>
<19423.950281199@sss.pgh.pa.us> <38A69E67.AB2944D0@bitmead.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Chris wrote:
Tom Lane wrote:
SELECT * FROM table WHERE x > 100 ORDER BY x LIMIT 1;
Could it _ever_ be faster to sort the tuples when there is already an
index that can provide them in sorted order?
This has been discussed on this list several times, and it appears that
select+sort is quite often faster than index scan, mainly due to the fact
that tables live on disk and disk accesses are expensive, and when doing
index scans:
1- you have to scan two files (index and data), when they are on the same
disk it is much more 2 times slower than sacnning a single file even
when doing it sequentially
2- scans on the both files are random access, so seek and latency times
come into play and readahead is useless
3- you often read the same data page many times
-------------
Hannu
From bouncefilter Sun Feb 13 11:54:32 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 LAA81692
for <pgsql-hackers@postgreSQL.org>;
Sun, 13 Feb 2000 11:54:14 -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 LAA05422;
Sun, 13 Feb 2000 11:53:49 -0500 (EST)
To: Chris <chris@bitmead.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
In-reply-to: <38A69E67.AB2944D0@bitmead.com>
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.5.32.20000211163810.035e1aa0@mail.rhyme.com.au>
<38A3A8FB.5A9C556D@nimrod.itg.telecom.com.au>
<19423.950281199@sss.pgh.pa.us> <38A69E67.AB2944D0@bitmead.com>
Comments: In-reply-to Chris <chris@bitmead.com>
message dated "Sun, 13 Feb 2000 23:07:03 +1100"
Date: Sun, 13 Feb 2000 11:53:49 -0500
Message-ID: <5419.950460829@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Chris <chris@bitmead.com> writes:
Could it _ever_ be faster to sort the tuples when there is already an
index that can provide them in sorted order?
Yes --- in fact usually, for large tables. Once your table gets too
big for the disk cache to be effective, indexscan performance approaches
one random-access page fetch per tuple. Sort performance behaves more
or less as p*log(p) accesses for p pages; and a far larger proportion
of those accesses are sequential than in the indexscan case. So the
sort will win if you have more than log(p) tuples per page. Do the
arithmetic...
The optimizer's job would be far simpler if no-brainer rules like
"indexscan is always better" worked.
regards, tom lane
From bouncefilter Sun Feb 13 12:13:32 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 MAA84705
for <pgsql-hackers@postgreSQL.org>;
Sun, 13 Feb 2000 12:13:17 -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 MAA05519;
Sun, 13 Feb 2000 12:13:01 -0500 (EST)
To: chris@bitmead.com
cc: Don Baccus <dhogaza@pacifier.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
In-reply-to: <38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au>
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au>
Comments: In-reply-to Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
message dated "Fri, 11 Feb 2000 17:57:59 +1100"
Date: Sun, 13 Feb 2000 12:13:00 -0500
Message-ID: <5516.950461980@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
Don Baccus wrote:
But ... that doesn't mean that some folks might not want to use
it differently. What if LIMIT 2 were more efficient that COUNT(*)
in order to determine if more than one row satisfies a condition?
select count(*) > 1 from a;
And if that's not efficient, why not optimise _that_, since it
expresses directly what you want?
Practicality, mostly. To do it that way, the optimizer would have
to have extremely specific hard-wired knowledge about the behavior
of count() (which flies in the face of Postgres' open-ended approach
to aggregate functions); furthermore it would have to examine every
query to see if there is a count() - inequality operator - constant
clause placed in such a way that no other result need be delivered
by the query. That's a lot of mechanism and overhead to extract the
same information that is provided directly by LIMIT; and it doesn't
eliminate the need for LIMIT, since this is only one application
for LIMIT (not even the primary one IMHO).
I have currently got it working (I think; not too well tested yet)
using the proposal I offered before of "pay attention to the size
of LIMIT, but ignore OFFSET", so that the same query plan will be
derived from similar queries with different OFFSETs. Does anyone
have a substantial gripe with that compromise?
regards, tom lane
From bouncefilter Sun Feb 13 12:44:33 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 MAA88808
for <hackers@postgreSQL.org>; Sun, 13 Feb 2000 12:43:40 -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 MAA05645;
Sun, 13 Feb 2000 12:43:31 -0500 (EST)
To: Chris <chris@bitmead.com>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] libpq
In-reply-to: <38A6A3AE.CAF01A62@bitmead.com>
References: <38A2AE00.9EB1BE9B@bitmead.com> <15283.950196239@sss.pgh.pa.us>
<38A396B0.BF0509A5@nimrod.itg.telecom.com.au>
<18587.950249454@sss.pgh.pa.us>
<38A3ADE3.AAE1FC7D@nimrod.itg.telecom.com.au>
<19512.950281813@sss.pgh.pa.us> <38A6A3AE.CAF01A62@bitmead.com>
Comments: In-reply-to Chris <chris@bitmead.com>
message dated "Sun, 13 Feb 2000 23:29:34 +1100"
Date: Sun, 13 Feb 2000 12:43:31 -0500
Message-ID: <5642.950463811@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Chris <chris@bitmead.com> writes:
All I mean to say is that it is often desirable to have control over
when each individual object is destroyed, rather than having to destroy
each batch at once.
Right, so if you really want to destroy retrieved tuples one at a time,
you request only one per retrieved PGresult. I claim that the other
case where you want them in small batches (but not necessarily only one
at a time) is at least as interesting; therefore the mechanism should
not be limited to the exactly-one-at-a-time case. Once you allow for
the other requirements, you have something that looks enough like a
PGresult that it might as well just *be* a PGresult.
The result status and query status is only temporarily interesting. Once
I know the tuple arrived safely I don't care much about the state of
affairs at that moment, and don't care to waste memory on a structure
that has space for all these error fields.
Let's see (examines PGresult declaration). Four bytes for the
resultStatus, four for the errMsg pointer, 40 for cmdStatus,
out of a struct that is going to occupy close to 100 bytes on
typical hardware --- and that's not counting the tuple descriptor
data and the tuple(s) proper. You could easily reduce the cmdStatus
overhead by making it a pointer to an allocated string instead of
an in-line array, if the 40 bytes were really bothering you. So the
above seems a pretty weak argument for introducing a whole new datatype
and a whole new set of access functions for it. Besides which, you
haven't explained how it is that you are going to avoid the need to
be able to represent error status in a PGObject. The function that
fetches the next tuple(s) in a query has to be able to return an
error status, and that has to be distinguishable from "successful
end of query" and from "no more data available yet".
The other thing about PGobject idea is that when I do a real OO database
idea, is that getNextObject will optionally populate user-supplied data
instead.
And that can't be done from a PGresult because?
So far, the *only* valid reason you've given for inventing a new
datatype, rather than just using PGresult for the purpose, is to save a
few bytes by eliminating unnecessary fields. That seems a pretty weak
argument (even assuming that the fields are unnecessary, which I doubt).
Having to support and document a whole set of essentially-identical
access functions for both PGresult and PGObject is the overhead that
we ought to be worried about, ISTM. Don't forget that it's not just
libpq we are talking about, either; this additional API will also have
to propagate into libpq++, libpgtcl, the perl5 and python modules,
etc etc etc.
regards, tom lane
From bouncefilter Sun Feb 13 14:25:34 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA04787
for <pgsql-hackers@postgreSQL.org>;
Sun, 13 Feb 2000 14:25:03 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id LAA22587;
Sun, 13 Feb 2000 11:24:29 -0800 (PST)
Message-Id: <3.0.1.32.20000213110934.010cd260@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 13 Feb 2000 11:09:34 -0800
To: Hannu Krosing <hannu@tm.ee>, Chris <chris@bitmead.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <38A6DADB.D355E3C9@tm.ee>
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.5.32.20000211163810.035e1aa0@mail.rhyme.com.au>
<38A3A8FB.5A9C556D@nimrod.itg.telecom.com.au>
<19423.950281199@sss.pgh.pa.us> <38A69E67.AB2944D0@bitmead.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 06:24 PM 2/13/00 +0200, Hannu Krosing wrote:
Chris wrote:
Tom Lane wrote:
SELECT * FROM table WHERE x > 100 ORDER BY x LIMIT 1;
Could it _ever_ be faster to sort the tuples when there is already an
index that can provide them in sorted order?
This has been discussed on this list several times, and it appears that
select+sort is quite often faster than index scan, mainly due to the fact
that tables live on disk and disk accesses are expensive, and when doing
index scans:1- you have to scan two files (index and data), when they are on the same
disk it is much more 2 times slower than sacnning a single file even
when doing it sequentially2- scans on the both files are random access, so seek and latency times
come into play and readahead is useless3- you often read the same data page many times
Hmmm...yet any studly Oracle type knows that despite whatever veracity
this analysis has, in reality Oracle will utilize the index in the
manner suggested by Chris and the difference in execution time is,
well, astonishing. Even without the limit.
We just had a discussion regarding this a few days ago over on
Philip Greenspun's web/db forum, where someone ran into a situation
where Oracle didn't recognize that the index could be used (involving
function calls, where presently Oracle doesn't dig into the parameter
list and to look to see if the referenced columns are indexed when
doing its optimization). After tricking Oracle into using the index
by adding an additional column reference, he got a speedup of well
over an order of magnitude.
Again, with no limit clause (which Oracle doesn't implement anyway).
- 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 Sun Feb 13 14:26:33 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA04915
for <pgsql-hackers@postgresql.org>;
Sun, 13 Feb 2000 14:25:35 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id LAA22596;
Sun, 13 Feb 2000 11:24:30 -0800 (PST)
Message-Id: <3.0.1.32.20000213111427.010ce3b0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 13 Feb 2000 11:14:27 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, Chris <chris@bitmead.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Cc: pgsql-hackers@postgresql.org
In-Reply-To: <5419.950460829@sss.pgh.pa.us>
References: <38A69E67.AB2944D0@bitmead.com>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.5.32.20000211163810.035e1aa0@mail.rhyme.com.au>
<38A3A8FB.5A9C556D@nimrod.itg.telecom.com.au>
<19423.950281199@sss.pgh.pa.us> <38A69E67.AB2944D0@bitmead.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 11:53 AM 2/13/00 -0500, Tom Lane wrote:
Chris <chris@bitmead.com> writes:
Could it _ever_ be faster to sort the tuples when there is already an
index that can provide them in sorted order?Yes --- in fact usually, for large tables. Once your table gets too
big for the disk cache to be effective, indexscan performance approaches
one random-access page fetch per tuple. Sort performance behaves more
or less as p*log(p) accesses for p pages; and a far larger proportion
of those accesses are sequential than in the indexscan case. So the
sort will win if you have more than log(p) tuples per page. Do the
arithmetic...The optimizer's job would be far simpler if no-brainer rules like
"indexscan is always better" worked.
Yet the optimizer currently takes the no-brainer point-of-view that
"indexscan is slow for tables much larger than the disk cache, therefore
treat all tables as though they're much larger than the disk cache".
The name of the game in the production database world is to do
everything possible to avoid a RAM bottleneck, while the point
of view PG is taking seems to be that RAM is always a bottleneck.
This presumption is far too pessimistic.
- 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 Sun Feb 13 14:25:33 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA04791
for <pgsql-hackers@postgreSQL.org>;
Sun, 13 Feb 2000 14:25:06 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id LAA22599;
Sun, 13 Feb 2000 11:24:31 -0800 (PST)
Message-Id: <3.0.1.32.20000213111930.010cdde0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 13 Feb 2000 11:19:30 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, chris@bitmead.com
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <5516.950461980@sss.pgh.pa.us>
References: <38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 12:13 PM 2/13/00 -0500, Tom Lane wrote:
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
Don Baccus wrote:
But ... that doesn't mean that some folks might not want to use
it differently. What if LIMIT 2 were more efficient that COUNT(*)
in order to determine if more than one row satisfies a condition?select count(*) > 1 from a;
And if that's not efficient, why not optimise _that_, since it
expresses directly what you want?Practicality, mostly. To do it that way, the optimizer would have
to have extremely specific hard-wired knowledge about the behavior
of count() (which flies in the face of Postgres' open-ended approach
to aggregate functions);
Actually, the aggregate interface could pass in a predicate test that
the aggregate function could use to say "stop" once it knows that
the result of the predicate will be true at the end of the query.
Of the standard aggregates, "count()" is probably the only one that
could make use of it. And of course only rarely is count() used
in such a way.
As someone who has long made his living implementing optimizing
compilers, I don't think that optimizing expressions such as the
one Chris mentions is all that difficult a task.
But there are far more important things to think about implementing
in Postgres.
I have currently got it working (I think; not too well tested yet)
using the proposal I offered before of "pay attention to the size
of LIMIT, but ignore OFFSET", so that the same query plan will be
derived from similar queries with different OFFSETs. Does anyone
have a substantial gripe with that compromise?
Not me, that's for sure.
- 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 Sun Feb 13 16:42:35 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA29122
for <pgsql-hackers@postgresql.org>;
Sun, 13 Feb 2000 16:42:28 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63325 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S170055AbQBMVlc>;
Sun, 13 Feb 2000 22:41:32 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12K6nU-0002WY-00; Sun, 13 Feb 2000 22:43:16 +0100
Date: Sun, 13 Feb 2000 22:43:15 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: chris@bitmead.com, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
In-Reply-To: <18098.950241132@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0002121844190.456-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-02-10, Tom Lane mentioned:
4. Fascist variant of #3: make LIMIT without ORDER BY be an error.
Got my vote for that. At least make it a notice: "NOTICE: LIMIT without
ORDER BY results in random data being returned" -- That'll teach 'em. ;)
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sun Feb 13 18:16:37 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA58509
for <pgsql-hackers@postgreSQL.org>;
Sun, 13 Feb 2000 18:15:58 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA16783 for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 10:15:19 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0ZQNeQ;
Mon Feb 14 10:14:38 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA14323 for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 10:14:37 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0mUajS; Mon Feb 14 10:13:13 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA28431
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 10:13:12 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
KAA05486 for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 10:12:33 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A73A28.75252064@nimrod.itg.telecom.com.au>
Date: Mon, 14 Feb 2000 10:11:36 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
References: <38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au>
<3.0.1.32.20000213111930.010cdde0@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Don Baccus wrote:
select count(*) > 1 from a;
And if that's not efficient, why not optimise _that_, since it
expresses directly what you want?Practicality, mostly. To do it that way, the optimizer would have
to have extremely specific hard-wired knowledge about the behavior
of count() (which flies in the face of Postgres' open-ended approach
to aggregate functions);Actually, the aggregate interface could pass in a predicate test that
the aggregate function could use to say "stop" once it knows that
the result of the predicate will be true at the end of the query.
That's the kind of thing I had in mind.
Of the standard aggregates, "count()" is probably the only one that
could make use of it. And of course only rarely is count() used
in such a way.
I think a lot of the agregates could make use of it. For example, tell
me all the departments who have spent more than $1000,000 this year...
select deptid, sum(amount) > 1000000 from purchases group by deptid;
As someone who has long made his living implementing optimizing
compilers, I don't think that optimizing expressions such as the
one Chris mentions is all that difficult a task.But there are far more important things to think about implementing
in Postgres.
Yep.
I have currently got it working (I think; not too well tested yet)
using the proposal I offered before of "pay attention to the size
of LIMIT, but ignore OFFSET", so that the same query plan will be
derived from similar queries with different OFFSETs. Does anyone
have a substantial gripe with that compromise?Not me, that's for sure.
- 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 Sun Feb 13 18:20:36 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA59654
for <pgsql-hackers@postgreSQL.org>;
Sun, 13 Feb 2000 18:20:23 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA21417 for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 10:19:51 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdOWfVd_;
Mon Feb 14 10:19:36 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA21675 for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 10:19:35 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0VF7Ci; Mon Feb 14 10:18:37 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA03500
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 10:18:36 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
KAA05608 for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 10:17:57 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A73B6C.74D38DB5@nimrod.itg.telecom.com.au>
Date: Mon, 14 Feb 2000 10:17:00 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
I have currently got it working (I think; not too well tested yet)
using the proposal I offered before of "pay attention to the size
of LIMIT, but ignore OFFSET", so that the same query plan will be
derived from similar queries with different OFFSETs. Does anyone
have a substantial gripe with that compromise?
Would offset be any use if you did make use of it?
From bouncefilter Sun Feb 13 18:32:43 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA62346
for <pgsql-hackers@postgreSQL.org>;
Sun, 13 Feb 2000 18:32:17 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id PAA27123;
Sun, 13 Feb 2000 15:31:43 -0800 (PST)
Message-Id: <3.0.1.32.20000213152912.010daa30@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 13 Feb 2000 15:29:12 -0800
To: chris@bitmead.com, pgsql-hackers@postgreSQL.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
In-Reply-To: <38A73A28.75252064@nimrod.itg.telecom.com.au>
References: <38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au>
<3.0.1.32.20000213111930.010cdde0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 10:11 AM 2/14/00 +1100, Chris Bitmead wrote:
Of the standard aggregates, "count()" is probably the only one that
could make use of it. And of course only rarely is count() used
in such a way.I think a lot of the agregates could make use of it. For example, tell
me all the departments who have spent more than $1000,000 this year...select deptid, sum(amount) > 1000000 from purchases group by deptid;
This would be harder, because you could only guarantee that sum is
of all positive or negative numbers if the user provides a constraint.
As someone who has long made his living implementing optimizing
compilers, I don't think that optimizing expressions such as the
one Chris mentions is all that difficult a task.But there are far more important things to think about implementing
in Postgres.Yep.
Good, because I was about to repeat myself :)
- 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 Sun Feb 13 18:44: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 SAA64549
for <pgsql-hackers@postgresql.org>;
Sun, 13 Feb 2000 18:44:04 -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 SAA09414;
Sun, 13 Feb 2000 18:43:31 -0500 (EST)
To: Don Baccus <dhogaza@pacifier.com>
cc: Chris <chris@bitmead.com>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
In-reply-to: <3.0.1.32.20000213111427.010ce3b0@mail.pacifier.com>
References: <38A69E67.AB2944D0@bitmead.com>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.5.32.20000211163810.035e1aa0@mail.rhyme.com.au>
<38A3A8FB.5A9C556D@nimrod.itg.telecom.com.au>
<19423.950281199@sss.pgh.pa.us> <38A69E67.AB2944D0@bitmead.com>
<3.0.1.32.20000213111427.010ce3b0@mail.pacifier.com>
Comments: In-reply-to Don Baccus <dhogaza@pacifier.com>
message dated "Sun, 13 Feb 2000 11:14:27 -0800"
Date: Sun, 13 Feb 2000 18:43:31 -0500
Message-ID: <9411.950485411@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Don Baccus <dhogaza@pacifier.com> writes:
The optimizer's job would be far simpler if no-brainer rules like
"indexscan is always better" worked.
Yet the optimizer currently takes the no-brainer point-of-view that
"indexscan is slow for tables much larger than the disk cache, therefore
treat all tables as though they're much larger than the disk cache".
Ah, you haven't seen the (as-yet-uncommitted) optimizer changes I'm
working on ;-)
What I still lack is a believable approximation curve for cache hit
ratio vs. table-size-divided-by-cache-size. Anybody seen any papers
about that? I made up a plausible-shaped function but it'd be nice to
have something with some actual theory or measurement behind it...
(Of course the cache size is only a magic number in the absence of any
hard info about what the kernel is doing --- but at least it will
optimize big tables differently than small ones now.)
regards, tom lane
From bouncefilter Sun Feb 13 19:09:37 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA69180
for <pgsql-hackers@postgresql.org>;
Sun, 13 Feb 2000 19:09:35 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id QAA06947;
Sun, 13 Feb 2000 16:08:32 -0800 (PST)
Message-Id: <3.0.1.32.20000213160613.010da280@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 13 Feb 2000 16:06:13 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Cc: Chris <chris@bitmead.com>, pgsql-hackers@postgresql.org
In-Reply-To: <9411.950485411@sss.pgh.pa.us>
References: <3.0.1.32.20000213111427.010ce3b0@mail.pacifier.com>
<38A69E67.AB2944D0@bitmead.com>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.5.32.20000211163810.035e1aa0@mail.rhyme.com.au>
<38A3A8FB.5A9C556D@nimrod.itg.telecom.com.au>
<19423.950281199@sss.pgh.pa.us> <38A69E67.AB2944D0@bitmead.com>
<3.0.1.32.20000213111427.010ce3b0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 06:43 PM 2/13/00 -0500, Tom Lane wrote:
Ah, you haven't seen the (as-yet-uncommitted) optimizer changes I'm
working on ;-)
Very good!
What I still lack is a believable approximation curve for cache hit
ratio vs. table-size-divided-by-cache-size. Anybody seen any papers
about that? I made up a plausible-shaped function but it'd be nice to
have something with some actual theory or measurement behind it...(Of course the cache size is only a magic number in the absence of any
hard info about what the kernel is doing --- but at least it will
optimize big tables differently than small ones now.)
If you've got the memory and allocate sufficient space to shared
buffers and still have plenty of kernel cache space left over, the
optimizer can hardly be over optimistic - things will fly! :)
- 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 Sun Feb 13 19:28:38 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA72522
for <hackers@postgreSQL.org>; Sun, 13 Feb 2000 19:28:09 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
LAA23937; Mon, 14 Feb 2000 11:27:37 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0tj4np;
Mon Feb 14 11:27:16 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
LAA24333; Mon, 14 Feb 2000 11:27:15 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd8izAY_; Mon Feb 14 11:26:12 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA06565;
Mon, 14 Feb 2000 11:26:11 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
LAA07531; Mon, 14 Feb 2000 11:25:32 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A74B43.2F753D32@nimrod.itg.telecom.com.au>
Date: Mon, 14 Feb 2000 11:24:35 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Chris <chris@bitmead.com>, Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] libpq
References: <38A2AE00.9EB1BE9B@bitmead.com> <15283.950196239@sss.pgh.pa.us>
<38A396B0.BF0509A5@nimrod.itg.telecom.com.au>
<18587.950249454@sss.pgh.pa.us>
<38A3ADE3.AAE1FC7D@nimrod.itg.telecom.com.au>
<19512.950281813@sss.pgh.pa.us> <38A6A3AE.CAF01A62@bitm
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
100 bytes, or even 50 bytes seems like a huge price to pay. If I'm
retrieving 10 byte tuples that's a 500% or 1000% overhead.
There are other issues too. Like if I want to be able to populate
a C++ object without the overhead of copying, I need to know
in advance the type of tuple I'm getting back. So I need something
like a nextClass() API.
Here is what I'm imagining (in very rough terms with details glossed
over).
How would you do this with the PGresult idea?...
class Base {
int c;
}
class Sub1 : Base {
int b;
}
class Sub2 : Base {
int c;
}
#define OFFSET (class, field) (&((class *)NULL)->field)
struct FieldPositions f1[] = { { "a", OFFSET(Sub1,a) }, { "b",
OFFSET(Sub1,b)} };
struct FieldPositions f2[] = { { "a", OFFSET(Sub1, c) }, { "c",
OFFSET(Sub2, c) } };
PGresult *q = PQexecStream("SELECT ** from Base");
List<Base> results;
for (;;) {
PGClass *class = PQnextClass(q);
if (PQresultStatus(q) == ERROR)
processError(q);
else if (PQresultStatus(q) == NO_MORE)
break;
if (strcmp(class->name) == "Sub1") {
results.add(PQnextObject(q, new Sub1, FieldPositions(f1)));
else if (strcmp(class->name) == "Sub2") {
results.add(PQnextObject(q, new Sub2, FieldPositions(f2)));
}
Of course in a full ODBMS front end, some of the above code would
be generated or something.
In this case PQnextObject is populating memory supplied by the
programmer.
There is no overhead whatsoever, nor can there be because we are
supplying
memory for the fields we care about.
In this case we don't even need to store tuple descriptors because
the C++ object has it's vtbl which is enough. If we cared about
tuple descriptors though we could hang onto the PGClass and do
something like PQgetValue(class, object, "fieldname"), which
would be useful for some language interfaces no doubt.
A basic C example would look like this...
PGresult *q = PQexecStream("SELECT ** from Base");
for (;;) {
PGClass *class = PQnextClass(q);
if (PQresultStatus(q) == ERROR)
processError(q);
else if (PQresultStatus(q) == NO_MORE)
break;
PGobject *obj = PQnextObject(q, NULL, NULL);
for (int c = 0; c < PQnColumns(class); c++) {
printf("%s: %s, ", PQcolumnName(class, c), PQcolumnValue(class, c,
obj));
printf("\n");
}
The points to note here are:
(1) Yes, the error message stuff comes from PGresult as it does now.
(2) You don't have a wasteful new PGresult for every time you get
the next result.
(3) You are certainly not required to store a whole lot of PGresults
just because you want to cache tuples.
(4) Because the tuple descriptor is explicit (PGClass*) you can
keep it or not as you please. If you are doing pure relational
with fixed number of columns, there is ZERO overhead per tuple
because you only need keep one pointer to the PGClass. This is
even though you retrieve results one at a time.
(5) Because of (4) I can't see the need for any API to support
getting multiple tuples at a time since it is trivially implemented
in terms of nextObject with no overhead.
While a PGresult interface like you described could be built, I can't
see that
it fulfills all the requirements that I would have. It could be
trivially
built on top of the above building blocks, but it doesn't sound fine
enough
grained for me. If you disagree, tell me how you'd do it.
Tom Lane wrote:
Chris <chris@bitmead.com> writes:
All I mean to say is that it is often desirable to have control over
when each individual object is destroyed, rather than having to destroy
each batch at once.Right, so if you really want to destroy retrieved tuples one at a time,
you request only one per retrieved PGresult. I claim that the other
case where you want them in small batches (but not necessarily only one
at a time) is at least as interesting; therefore the mechanism should
not be limited to the exactly-one-at-a-time case. Once you allow for
the other requirements, you have something that looks enough like a
PGresult that it might as well just *be* a PGresult.The result status and query status is only temporarily interesting. Once
I know the tuple arrived safely I don't care much about the state of
affairs at that moment, and don't care to waste memory on a structure
that has space for all these error fields.Let's see (examines PGresult declaration). Four bytes for the
resultStatus, four for the errMsg pointer, 40 for cmdStatus,
out of a struct that is going to occupy close to 100 bytes on
typical hardware --- and that's not counting the tuple descriptor
data and the tuple(s) proper. You could easily reduce the cmdStatus
overhead by making it a pointer to an allocated string instead of
an in-line array, if the 40 bytes were really bothering you. So the
above seems a pretty weak argument for introducing a whole new datatype
and a whole new set of access functions for it. Besides which, you
haven't explained how it is that you are going to avoid the need to
be able to represent error status in a PGObject. The function that
fetches the next tuple(s) in a query has to be able to return an
error status, and that has to be distinguishable from "successful
end of query" and from "no more data available yet".The other thing about PGobject idea is that when I do a real OO database
idea, is that getNextObject will optionally populate user-supplied data
instead.And that can't be done from a PGresult because?
So far, the *only* valid reason you've given for inventing a new
datatype, rather than just using PGresult for the purpose, is to save a
few bytes by eliminating unnecessary fields. That seems a pretty weak
argument (even assuming that the fields are unnecessary, which I doubt).
Having to support and document a whole set of essentially-identical
access functions for both PGresult and PGObject is the overhead that
we ought to be worried about, ISTM. Don't forget that it's not just
libpq we are talking about, either; this additional API will also have
to propagate into libpq++, libpgtcl, the perl5 and python modules,
etc etc etc.regards, tom lane
From bouncefilter Sun Feb 13 21:49:40 2000
Received: from ns1.prima.net.id ([202.57.0.8])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA01128
for <pgsql-hackers@postgreSQL.org>;
Sun, 13 Feb 2000 21:49:28 -0500 (EST)
(envelope-from chai@prima.net.id)
Received: from prima.net.id (chai@[202.57.0.52]) by ns1.prima.net.id
(8.8.4/8.7.2) with ESMTP id CAA09542 for
<pgsql-hackers@postgreSQL.org>; Mon, 14 Feb 2000 02:51:05 +0700 (GMT)
Sender: chai@ns1.prima.net.id
Message-ID: <38A76CC6.5615C8D4@prima.net.id>
Date: Mon, 14 Feb 2000 09:47:34 +0700
From: Chairudin Sentosa <chai@prima.net.id>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Suggestion to split /data/base directory
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.5.32.20000211163810.035e1aa0@mail.rhyme.com.au>
<38A3A8FB.5A9C556D@nimrod.itg.telecom.com.au>
<19423.950281199@sss.pgh.pa.us> <38A69E67.AB2944D0@bitmead.com>
<3.0.1.32.20000213110934.010cd260@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi postgresql hackers,
I have a suggestion that might improve the performance of
postgresql.
This is regarding the directory structure of /data/base.
The current situation is that every database has one
directory, ie. "mydb", so you will have /data/base/mydb directory.
All the data files, index files, etc are in the same
/data/base/mydb directory.
If I want to split data files and index files to different hardisk, it
is not possible right now.
The only solution right now to improve the performance is to use RAID
method.
My suggestion is to split files into 4 different directories:
/data/base/mydb/data
/data/base/mydb/index
/data/base/mydb/dictionary
/data/base/mydb/tmp
So I can put each directory on different hardisk, so I can
have 4 hardisks for 'mydb' database.
Is it doable and a good idea?
Regards,
Chai
From bouncefilter Sun Feb 13 23:22:40 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA20924
for <pgsql-hackers@postgresql.org>;
Sun, 13 Feb 2000 23:22:19 -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 AAA19714
for <pgsql-hackers@postgresql.org>;
Mon, 14 Feb 2000 00:22:13 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 14 Feb 2000 00:22:13 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: pgsql-support 'distribution' ...
Message-ID: <Pine.BSF.4.21.0002140011320.74045-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Morning all ...
I tried to jump into this a little while back, and fell flat on my
face (tried to do too much simultaneously), so tonight I started again
just trying to address one 'piece' at a time, and the end results look
promising ...
Available at ftp://ftp.postgresql.org/pub is a tar file called
pgsql-support.tar.gz that, right now, just contains a
"self-contained" libpq distribution (I'm going to be converting things
over one at a time)...
The idea is that there are alot of sites out there that don't need
the whole backend sources, they only need the bin/interfaces stuff, so why
download a 7+meg file. Its also giving me a chance to play with
libtool/automake :)
Right now, if you download the above file, untar it and type:
./configure
cd interfaces/libpq
gmake
It will build both static and shared libraries for libpq ... or,
rather, it does on both a FreeBSD 4.0-CURRENT and Solaris 2.6 machine,
both running gcc ...
The Solaris 2.6 machine I tried it on doesn't have libtool
installed on it, so everything *appears* to be packaged properly ...
There are no 'template' files, or 'Makefile.port' files or
anything like that ...
Note that the source code included in the above is not up to date
with the regular source tree, this is as much a test of a concept as
anything else.
What I'm curious about right now is how well the above works on
the various architectures ... and whether it even works on non-gcc
environments ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Feb 13 23:25:40 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 XAA21545
for <pgsql-hackers@postgreSQL.org>;
Sun, 13 Feb 2000 23:25: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 XAA13441;
Sun, 13 Feb 2000 23:24:35 -0500 (EST)
To: chris@bitmead.com
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
In-reply-to: <38A73B6C.74D38DB5@nimrod.itg.telecom.com.au>
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.
<38A73B6C.74D38DB5@nimrod.itg.telecom.com.au>
Comments: In-reply-to Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
message dated "Mon, 14 Feb 2000 10:17:00 +1100"
Date: Sun, 13 Feb 2000 23:24:35 -0500
Message-ID: <13438.950502275@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
Tom Lane wrote:
I have currently got it working (I think; not too well tested yet)
using the proposal I offered before of "pay attention to the size
of LIMIT, but ignore OFFSET", so that the same query plan will be
derived from similar queries with different OFFSETs. Does anyone
have a substantial gripe with that compromise?
Would offset be any use if you did make use of it?
Yes, because the number of tuples that will *actually* get fetched
is offset+limit. If you had a large offset so that the tuples
getting returned were from somewhere near the end of the query,
then choosing a fast-start algorithm would be a Bad Idea; you'd
really want a plan that optimizes on the basis of total cost
rather than startup cost.
Hmm, I'm on the verge of talking myself out of the compromise ;-).
I'm not sure how many people will really use large offsets, but
anyone who does might be a pretty unhappy camper. If you're asking
for OFFSET 1000000 LIMIT 1, the thing might pick a nested loop
which is exceedingly fast-start ... but also exceedingly expensive
when you go ahead and fetch many tuples anyway.
Perhaps we should stick to two alternatives:
1. If LIMIT is present, optimize on an assumption that X% of the
tuples are fetched, where X does *not* depend on the specific
values given for OFFSET or LIMIT. (But we could make X a settable
parameter...)
2. Optimize using OFFSET+LIMIT as the expected number of tuples to
fetch. Document that varying OFFSET or LIMIT will not necessarily
generate consistent results unless you specify ORDER BY to force a
consistent tuple order.
I don't really like #1, but I can see where #2 might cause some
unhappiness as well. Comments, opinions?
regards, tom lane
From bouncefilter Sun Feb 13 23:36:40 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id XAA24194
for <pgsql-hackers@postgreSQL.org>;
Sun, 13 Feb 2000 23:36:00 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
PAA26668 for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 15:35:17 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdDt5rT_;
Mon Feb 14 15:35:09 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
PAA12305 for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 15:35:09 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0d_36B; Mon Feb 14 15:34:11 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id PAA10609
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 15:34:10 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
PAA12932 for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 15:33:29 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A7855F.DB3EF2CD@nimrod.itg.telecom.com.au>
Date: Mon, 14 Feb 2000 15:32:31 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
Tom Lane wrote:
I have currently got it working (I think; not too well tested yet)
using the proposal I offered before of "pay attention to the size
of LIMIT, but ignore OFFSET", so that the same query plan will be
derived from similar queries with different OFFSETs. Does anyone
have a substantial gripe with that compromise?Would offset be any use if you did make use of it?
Yes, because the number of tuples that will *actually* get fetched
is offset+limit. If you had a large offset so that the tuples
getting returned were from somewhere near the end of the query,
then choosing a fast-start algorithm would be a Bad Idea; you'd
really want a plan that optimizes on the basis of total cost
rather than startup cost.
Hmm, I'm on the verge of talking myself out of the compromise ;-).
I'm not sure how many people will really use large offsets, but
anyone who does might be a pretty unhappy camper. If you're asking
for OFFSET 1000000 LIMIT 1, the thing might pick a nested loop
which is exceedingly fast-start ... but also exceedingly expensive
when you go ahead and fetch many tuples anyway.Perhaps we should stick to two alternatives:
1. If LIMIT is present, optimize on an assumption that X% of the
tuples are fetched, where X does *not* depend on the specific
values given for OFFSET or LIMIT. (But we could make X a settable
parameter...)2. Optimize using OFFSET+LIMIT as the expected number of tuples to
fetch. Document that varying OFFSET or LIMIT will not necessarily
generate consistent results unless you specify ORDER BY to force a
consistent tuple order.I don't really like #1, but I can see where #2 might cause some
unhappiness as well. Comments, opinions?
I agree you should probably go the whole hog one way or the other. I
think
ignoring offset+limit is a useful option, but like I said at the
beginning, it doesn't bother me _that_ much.
From bouncefilter Sun Feb 13 23:53:40 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA27477
for <pgsql-hackers@postgreSQL.org>;
Sun, 13 Feb 2000 23:53:19 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id UAA04734;
Sun, 13 Feb 2000 20:52:29 -0800 (PST)
Message-Id: <3.0.1.32.20000213204135.01704ec0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 13 Feb 2000 20:41:35 -0800
To: Chairudin Sentosa <chai@prima.net.id>, pgsql-hackers@postgreSQL.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Suggestion to split /data/base directory
In-Reply-To: <38A76CC6.5615C8D4@prima.net.id>
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.5.32.20000211163810.035e1aa0@mail.rhyme.com.au>
<38A3A8FB.5A9C556D@nimrod.itg.telecom.com.au>
<19423.950281199@sss.pgh.pa.us> <38A69E67.AB2944D0@bitmead.com>
<3.0.1.32.20000213110934.010cd260@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 09:47 AM 2/14/00 +0700, Chairudin Sentosa wrote:
My suggestion is to split files into 4 different directories:
/data/base/mydb/data
/data/base/mydb/index
/data/base/mydb/dictionary
/data/base/mydb/tmp
My preference would be for a simplistic "create tablespace" construct,
so location information could be captured within the database itself.
We've had discussions about this in the past and there seems to be
some recognition that the ability to spread stuff around disk drives
might be useful. I mean, all those commercial sites that do it after
measuring their bottlenecks can't ALL be wrong, right?
So I can put each directory on different hardisk, so I can
have 4 hardisks for 'mydb' database.
You can already do this in an ugly fashion, by moving individual
files via links (ln -s). ls *idx*, that kind of thing to find
your index tables (if you suffix them with "idx", then move and
ln to them.
Is it doable and a good idea?
Doable, but IMO a bad idea because it lowers the motivation for doing
a relatively simple CREATE TABLESPACE hack that gives even more
flexibility, and allows the db user to query where their tables
are stored within the db rather than depend on "ls".
- 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 Feb 14 00:07:40 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA30357
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 00:06:44 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id VAA09022;
Sun, 13 Feb 2000 21:05:35 -0800 (PST)
Message-Id: <3.0.1.32.20000213205711.01702800@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 13 Feb 2000 20:57:11 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, chris@bitmead.com
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <13438.950502275@sss.pgh.pa.us>
References: <38A73B6C.74D38DB5@nimrod.itg.telecom.com.au>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au>
<5516.950461980@sss. <38A73B6C.74D38DB5@nimrod.itg.telecom.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 11:24 PM 2/13/00 -0500, Tom Lane wrote:
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
Tom Lane wrote:
I have currently got it working (I think; not too well tested yet)
using the proposal I offered before of "pay attention to the size
of LIMIT, but ignore OFFSET", so that the same query plan will be
derived from similar queries with different OFFSETs. Does anyone
have a substantial gripe with that compromise?Would offset be any use if you did make use of it?
Yes, because the number of tuples that will *actually* get fetched
is offset+limit.
Bravo, you're on it! I resisted responding...so far this thread
is your's, baby.
2. Optimize using OFFSET+LIMIT as the expected number of tuples to
fetch. Document that varying OFFSET or LIMIT will not necessarily
generate consistent results unless you specify ORDER BY to force a
consistent tuple order.I don't really like #1, but I can see where #2 might cause some
unhappiness as well. Comments, opinions?
Anyone unhappy about #2 doesn't really understand the SQL model.
My suggestion's pretty simple - the database world is full of folks
who are professionals and who understand the SQL model.
We shouldn't penalize them for their professionalism.
Those who don't understand the SQL model should read the docmentation
you mention, of course, but the very fact that SQL doesn't impose
an ordering on the returned tuples is so basic to the language that
if they don't understand it, the doc should also recommend them to
"set theory for dummies" and "SQL for dummies" (unless the latter
was actually written by a dummy).
In my narrow-minded compiler-writer space, it is not MY PROBLEM if
people don't bother learning the language they use. I may or may
not choose to become one who teaches the language, but whether or not
I do has nothing to do with the implementation of the language.
It is perfectly fair to presume people understand the language. It
is their job to learn it.
If they're surprised by how the language works, then they should've
considered buying an SQL book, all of which that I've seen EMPHASIZE
the set orientation, and non-orderedness of queries.
- 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 Feb 14 00:06:42 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA30307
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 00:06:15 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id VAA09065;
Sun, 13 Feb 2000 21:05:41 -0800 (PST)
Message-Id: <3.0.1.32.20000213205901.01706710@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 13 Feb 2000 20:59:01 -0800
To: chris@bitmead.com, pgsql-hackers@postgreSQL.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
In-Reply-To: <38A7855F.DB3EF2CD@nimrod.itg.telecom.com.au>
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 03:32 PM 2/14/00 +1100, Chris Bitmead wrote:
I agree you should probably go the whole hog one way or the other. I
think
ignoring offset+limit is a useful option, but like I said at the
beginning, it doesn't bother me _that_ much.
It should bother you that folks who understand how SQL works might
be penalized in order to insulate the fact that those who don't know
how SQL works from an understanding of their own ignorance...
Shouldn't we be more concerned with folks who bother to read an
SQL primer? Or Oracle or Informix docs on SQL?
- 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 Feb 14 00:32:40 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA35872
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 00:31:51 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
QAA14546 for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 16:31:19 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdf1Mdq_;
Mon Feb 14 16:30:49 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
QAA23803 for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 16:30:48 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0LNi3v; Mon Feb 14 16:30:35 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id QAA28919
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 16:30:29 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
QAA14195 for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 16:29:51 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A79295.BF844BE7@nimrod.itg.telecom.com.au>
Date: Mon, 14 Feb 2000 16:28:53 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.>
<3.0.1.32.20000213205901.01706710@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Don Baccus wrote:
At 03:32 PM 2/14/00 +1100, Chris Bitmead wrote:
I agree you should probably go the whole hog one way or the other. I
think
ignoring offset+limit is a useful option, but like I said at the
beginning, it doesn't bother me _that_ much.It should bother you that folks who understand how SQL works might
be penalized in order to insulate the fact that those who don't know
how SQL works from an understanding of their own ignorance...Shouldn't we be more concerned with folks who bother to read an
SQL primer? Or Oracle or Informix docs on SQL?
LIMIT is not SQL, both as a technical fact, and philosophically
because it reaches outside of set theory. What LIMIT does without
ORDER BY is non-deterministic, and therefore a subjective matter of
what is the most useful: a faster answer, or a more consistant answer.
My predudices are caused by what I use PostgreSQL for, which is
more favourable to the latter.
From bouncefilter Mon Feb 14 00:41:40 2000
Received: from acheron.rime.com.au (root@albatr.lnk.telstra.net
[139.130.54.222]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA37670
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 00:41:09 -0500 (EST)
(envelope-from pjw@rhyme.com.au)
Received: from oberon (Oberon.rime.com.au [203.8.195.100])
by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id QAA22469;
Mon, 14 Feb 2000 16:40:23 +1100
Message-Id: <3.0.5.32.20000214164123.0339da10@mail.rhyme.com.au>
X-Sender: pjw@mail.rhyme.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 14 Feb 2000 16:41:23 +1100
To: Tom Lane <tgl@sss.pgh.pa.us>, chris@bitmead.com
From: Philip Warner <pjw@rhyme.com.au>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <13438.950502275@sss.pgh.pa.us>
References: <38A73B6C.74D38DB5@nimrod.itg.telecom.com.au>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au>
<5516.950461980@sss. <38A73B6C.74D38DB5@nimrod.itg.telecom.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 23:24 13/02/00 -0500, Tom Lane wrote:
Perhaps we should stick to two alternatives:
1. If LIMIT is present, optimize on an assumption that X% of the
tuples are fetched, where X does *not* depend on the specific
values given for OFFSET or LIMIT. (But we could make X a settable
parameter...)2. Optimize using OFFSET+LIMIT as the expected number of tuples to
fetch. Document that varying OFFSET or LIMIT will not necessarily
generate consistent results unless you specify ORDER BY to force a
consistent tuple order.I don't really like #1, but I can see where #2 might cause some
unhappiness as well. Comments, opinions?
#1 seems pretty nasty as a concept, unless of course this actually reflects
the way that PG retrieves rows. My guess is that it will have to retrieve
rows 1 to (offset + limit), not (offset) to (offset + limit), so the whole
appreximation should be based on #2.
[Aside: I suspect that trying to solve problems for people who want to use
context free (web) interfaces to retrieve blocks of rows is not a job for
the optimizer. It is far more suited to cursors and/or local temporary
tables, both of which require some context].
#2 seems more correct, in that it reflects a good estimation, but
pessimistic: with good indexes defined, the query may well only need to do
a scan of the index to get up to the 'offset-th' row. This, I am sure, must
be faster than retrieving all rows up to OFFSET.
This leaves two questions:
a. Does the optimizer know how to do 'index-only' queries (where all fields
are satisfied by the index)
b. Just to clarify, OFFSET does affect the tuples actually returned,
doesn't it?
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
From bouncefilter Mon Feb 14 00:51:41 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA40062
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 00:50:53 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
QAA01377 for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 16:50:21 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0NtmPe;
Mon Feb 14 16:50:03 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
QAA18406 for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 16:50:03 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd3hiPj_; Mon Feb 14 16:49:06 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id QAA14259
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 16:49:05 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
QAA14615 for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 16:48:27 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A796F1.2D2EDBA1@nimrod.itg.telecom.com.au>
Date: Mon, 14 Feb 2000 16:47:29 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
References: <38A73B6C.74D38DB5@nimrod.itg.telecom.com.au>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au>
<5516.950461980@sss. <38A73B6C.74D38DB5@nimrod.itg.telecom.com.au>
<3.0.5.32.20000214164123.0339da10@mail.rhyme.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
BTW, in the absense of an ORDER BY clause, doesn't offset totally
lose its meaning? If you're going to do this optimisation,
you may as well ignore offset entirely in this case.
From bouncefilter Mon Feb 14 01:34: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 BAA48537
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 01:34: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 BAA15110;
Mon, 14 Feb 2000 01:32:34 -0500 (EST)
To: Philip Warner <pjw@rhyme.com.au>
cc: chris@bitmead.com, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
In-reply-to: <3.0.5.32.20000214164123.0339da10@mail.rhyme.com.au>
References: <38A73B6C.74D38DB5@nimrod.itg.telecom.com.au>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.
<38A73B6C.74D38DB5@nimrod.itg.telecom.com.au>
<3.0.5.32.20000214164123.0339da10@mail.rhyme.com.au>
Comments: In-reply-to Philip Warner <pjw@rhyme.com.au>
message dated "Mon, 14 Feb 2000 16:41:23 +1100"
Date: Mon, 14 Feb 2000 01:32:33 -0500
Message-ID: <15107.950509953@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Philip Warner <pjw@rhyme.com.au> writes:
#1 seems pretty nasty as a concept, unless of course this actually reflects
the way that PG retrieves rows. My guess is that it will have to retrieve
rows 1 to (offset + limit), not (offset) to (offset + limit), so the whole
appreximation should be based on #2.
Right --- if we could start the query in the middle this would all be
a lot nicer, but we can't. The implementation of OFFSET is just to
discard the first N tuples retrieved before beginning to hand any tuples
back to the client. So the "right" approach for the optimizer is to
assume that OFFSET+LIMIT tuples will be retrieved. The trouble is that
that can mean that the query plan changes depending on OFFSET, which
leads to consistency problems if you don't lock down the tuple ordering
with ORDER BY.
a. Does the optimizer know how to do 'index-only' queries (where all fields
are satisfied by the index)
Postgres doesn't have indexes that allow index-only queries --- you
still have to fetch the tuples, because the index doesn't carry
commit status. I think that's irrelevant anyway, since we're not
only interested in the behavior for simple queries...
b. Just to clarify, OFFSET does affect the tuples actually returned,
doesn't it?
Of course.
regards, tom lane
From bouncefilter Mon Feb 14 04:19:43 2000
Received: from mail.mmwi.co.za ([196.33.47.3])
by hub.org (8.9.3/8.9.3) with SMTP id EAA89049
for <hackers@postgresql.org>; Mon, 14 Feb 2000 04:19:27 -0500 (EST)
(envelope-from davida@mmwi.co.za)
Received: from SMTP agent by mail gateway
Mon, 14 Feb 2000 11:20:28 --200
Received: from davida (davida.mmw.co.za [192.168.0.100])
by mail.mmwi.co.za (8.8.7/8.8.7) with SMTP id LAA21579
for <hackers@postgresql.org>; Mon, 14 Feb 2000 11:19:14 +0200
From: "davida" <davida@mmwi.co.za>
To: <hackers@postgresql.org>
Subject: subscribe hackers
Date: Mon, 14 Feb 2000 11:22:23 +0200
Message-ID: <00e301bf76cd$012fdb30$6400a8c0@mmw.co.za>
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 CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
subscribe hackers
David Anthony
mailto:davida@mmwi.co.za
312-1800
From bouncefilter Mon Feb 14 04:34:44 2000
Received: from hu.tm.ee (ppp727.tele2.ee [212.107.37.27])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA91819
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 04:33:57 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id E5F913A72; Mon, 14 Feb 2000 11:41:53 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38A7CDE1.B3005B98@tm.ee>
Date: Mon, 14 Feb 2000 11:41:53 +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: chris@bitmead.com
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.>
<3.0.1.32.20000213205901.01706710@mail.pacifier.com>
<38A79295.BF844BE7@nimrod.itg.telecom.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Chris Bitmead wrote:
Don Baccus wrote:
At 03:32 PM 2/14/00 +1100, Chris Bitmead wrote:
I agree you should probably go the whole hog one way or the other. I
think
ignoring offset+limit is a useful option, but like I said at the
beginning, it doesn't bother me _that_ much.It should bother you that folks who understand how SQL works might
be penalized in order to insulate the fact that those who don't know
how SQL works from an understanding of their own ignorance...Shouldn't we be more concerned with folks who bother to read an
SQL primer? Or Oracle or Informix docs on SQL?LIMIT is not SQL, both as a technical fact, and philosophically
because it reaches outside of set theory.
I see limit as a shortcut (plus an optimizer hint) for the sequence
DECLARE CURSOR - MOVE offset - FETCH limit - CLOSE CURSOR
It's utility was much debated befor it was included in Postgres,
the main argument for inclusion being "mySQL has it and it's useful
for fast-start queries", the main argument against being "it's not SQL,
people won't understand it a and will start to misuse it".
Maybe we should still discourage the use of LIMIT, and rather introduce
another "mode" for optimiser, activated by SET FastStart TO 'ON'.
Then queries with limit could be rewritten into
SET FastStart to 'ON';
DECLARE
MOVE
FETCH
CLOSE
SET FastStart to PREVIOUS_VALUE;
also maybe we will need PUSH/POP for set commands ?
What LIMIT does without ORDER BY is non-deterministic, and therefore
a subjective matter of what is the most useful: a faster answer,
or a more consistant answer.
As SQL queries are all one-time things you can't be "consistent".
It's like being able to grab the same set of socks from a bag and
then trying to devise a strategy for getting them in same order
without sorting them (i.e. possible but ridiculous)
If you need them in some order, you use ORDER BY, if you don't need
any order you omit ORDER BY.
My predudices are caused by what I use PostgreSQL for, which is
more favourable to the latter.
Whats wrong with using ORDER BY ?
I can't imagine a set of queries that need to be consistent _almost_
all the time, but without any order.
If you really need that kind of behaviour, the right decision is to
select the rows into a work table that has an additional column for
preserving order and then do the limit queries from that table.
But in that case it is often faster to have an index on said column
and to do
WHERE ID BETWEEN OFFSET AND OFFSET+LIMIT
ORDER BY ID
than to use LIMIT, more so for large offsets.
From bouncefilter Mon Feb 14 05:00:44 2000
Received: from feivel.fam-meskes.de (p3E9B9810.dip0.t-ipconnect.de
[62.155.152.16]) by hub.org (8.9.3/8.9.3) with ESMTP id EAA96475
for <pgsql-hackers@postgresql.org>;
Mon, 14 Feb 2000 04:59:18 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 001862BC8A; Mon, 14 Feb 2000 10:54:16 +0100 (CET)
Date: Mon, 14 Feb 2000 10:54:16 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: function defined in libpq?
Message-ID: <20000214105416.A9298@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
Sender: michael@fam-meskes.de
Could anyone please give me an example on how I can define a function using
libpq if that is at all possible?
Thanks.
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 Mon Feb 14 06:25:45 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 GAA14205
for <pgsql-hackers@postgresql.org>;
Mon, 14 Feb 2000 06:25:11 -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 12KJbm-0002Wr-00; Mon, 14 Feb 2000 11:24:02 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12KJbg-0003iW-00; Mon, 14 Feb 2000 11:23:56 +0000
Date: Mon, 14 Feb 2000 11:23:56 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Another nasty cache problem
Message-ID: <20000214112356.A13823@quartz.newn.cam.ac.uk>
Reply-To: prlw1@cam.ac.uk
References: <20000131191356.B8582@quartz.newn.cam.ac.uk>
<12080.949370550@sss.pgh.pa.us>
<20000203112434.B1509@quartz.newn.cam.ac.uk>
<1426.949641960@sss.pgh.pa.us>
<20000204171153.D3402@quartz.newn.cam.ac.uk>
<4803.949697937@sss.pgh.pa.us>
<20000205143515.F3402@quartz.newn.cam.ac.uk>
<7988.949771109@sss.pgh.pa.us>
<20000211210441.A11976@quartz.newn.cam.ac.uk>
<21865.950311112@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
In-Reply-To: <21865.950311112@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Fri, Feb 11, 2000 at 06:18:32PM -0500
On Fri, Feb 11, 2000 at 06:18:32PM -0500, Tom Lane wrote:
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
and the reason for the SIGSEGV, is that somehow, text_int4(text *string) in
src/backend/utils/adt/int.c is called with string=(text *)0x0, so obviously
this is a problem!Um. Probably you have a NULL value in "tblPerson"."USN" somewhere?
Yes of course! Naturally I was looking for something far too complicated and
the trees got in the way.. And that's why my test case didn't work.
There are a lot of functions without adequate defenses against NULL
inputs :-( --- we've been cleaning them up slowly, but evidently you
found another one.
So the trouble is, if the function returns and int, and you want to say
return null, there really isn't a value that can be stuck into the int
that represents null?
In the meantime, I think this might help, so I would have seen:
newnham=# select crsids.surname,"tblPerson"."Surname" from crsids,"tblPerson" where crsids.usn="tblPerson"."USN"::int4;
ERROR: Trying to convert NULL text to integer (int4)
Cheers,
Patrick
Index: int.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/utils/adt/int.c,v
retrieving revision 1.32
diff -c -r1.32 int.c
*** int.c 2000/01/26 05:57:14 1.32
--- int.c 2000/02/14 11:22:32
***************
*** 277,282 ****
--- 277,285 ----
int len;
char *str;+ if (!string)
+ elog(ERROR, "Trying to convert NULL text to integer (int2)");
+
len = (VARSIZE(string) - VARHDRSZ); str = palloc(len + 1);
***************
*** 317,322 ****
--- 320,328 ---- int len;
char *str;
+
+ if (!string)
+ elog(ERROR, "Trying to convert NULL text to integer (int4)");len = (VARSIZE(string) - VARHDRSZ);
From bouncefilter Mon Feb 14 06:48:45 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA18693
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 06:47:57 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id WAA12034
for <pgsql-hackers@postgreSQL.org>; Mon, 14 Feb 2000 22:47:53 +1100
Sender: chris@tech.com.au
Message-ID: <38A7EB66.7D2A880B@bitmead.com>
Date: Mon, 14 Feb 2000 22:47:50 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.>
<3.0.1.32.20000213205901.01706710@mail.pacifier.com>
<38A79295.BF844BE7@nimrod.itg.telecom.com.au>
<38A7CDE1.B3005B98@tm.ee>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hannu Krosing wrote:
As SQL queries are all one-time things you can't be "consistent".
It's like being able to grab the same set of socks from a bag and
then trying to devise a strategy for getting them in same order
without sorting them (i.e. possible but ridiculous)If you need them in some order, you use ORDER BY, if you don't need
any order you omit ORDER BY.My predudices are caused by what I use PostgreSQL for, which is
more favourable to the latter.Whats wrong with using ORDER BY ?
Only that it's non intuitive that ORDER BY should change the actual
results of a series of LIMIT queries, not just the order. If there are
100 records, and I do 10x LIMIT 10,offset queries one might expect to
get all 100 records. And currently you do (barring something unusual
like a vacuum at an inopportune moment that drastically changes
statistics).
I can't imagine a set of queries that need to be consistent
_almost_ all the time, but without any order.If you really need that kind of behaviour, the right decision is
to select the rows into a work table that has an additional column
for preserving order and then do the limit queries from that
table.
Impractical for stateless web based stuff where keeping state around is
painful if not impossible.
I'm just playing devils advocate here. Changing this is probably not
going to hurt me, I just think it could confuse a lot of people.
But in that case it is often faster to have an index on said column
and to do
WHERE ID BETWEEN OFFSET AND OFFSET+LIMIT
ORDER BY ID
than to use LIMIT, more so for large offsets.
--
Chris Bitmead
mailto:chris@bitmead.com
From bouncefilter Mon Feb 14 07:12:45 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA23115
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 07:12:41 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id XAA12323
for <pgsql-hackers@postgreSQL.org>; Mon, 14 Feb 2000 23:12:36 +1100
Sender: chris@tech.com.au
Message-ID: <38A7F134.822B6062@bitmead.com>
Date: Mon, 14 Feb 2000 23:12:36 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Solution for LIMIT cost estimation
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.>
<3.0.1.32.20000213205901.01706710@mail.pacifier.com>
<38A79295.BF844BE7@nimrod.itg.telecom.com.au>
<38A7CDE1.B3005B98@tm.ee> <38A7EB66.7D2A880B@bitmead.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
How about this as a compromise:
If you give an offset without an ORDER BY the offset
is useless if this optimisation is in place. If you
allowed the offset with the optimisation and no
order by it would be encouraging broken behaviour.
So therefore it would be reasonable to optimise a
limit,offset query with no order by as if there were
no offset. This would give consistent results, albeit
it may not choose the best plan. But at least it
won't hurt anyone.
The only snag is that it's not technically correct to
have an offset unless the ORDER BY yields a unique
criteria. If it's not unique, either because that
field is declared UNIQUE or because every single
field is mentioned in the order by, then optimisation
should be turned off if there is an offset. If it is
allowed people will randomly get missing results. I
mean the only purpose of OFFSET is to get something
like consistency between calls.
The thing is, I'll bet a whole lot of people will use
LIMIT,OFFSET with an ORDER BY, just not a fully unique
ORDER BY. That's why I find this "optimisation"
questionable. Unless you're _extremely_ careful with
your ORDER BY clause your results would be crap. Or
if the above idea is implemented, the execution
plan would be crap. If offset were not available,
then none of this would matter.
If this optimisation is implemented, are we going to
carefully explain exactly when an ORDER BY clause will
and won't yield consistent results? Because not just
any ORDER BY is good enough. Anybody who read that
manual page is probably going to be very confused.
--
Chris Bitmead
mailto:chris@bitmead.com
From bouncefilter Mon Feb 14 07:33:46 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 HAA27920;
Mon, 14 Feb 2000 07:33: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
HAA15711;
Mon, 14 Feb 2000 07:32:40 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002141232.HAA15711@candle.pha.pa.us>
Subject: Re: Postgres ODBC
In-Reply-To: <38A7DB02.2E73492D@easysoft.com> from Nick Gorham at "Feb 14,
2000
10:37:54 am"
To: Nick Gorham <nick@easysoft.com>
Date: Mon, 14 Feb 2000 07:32:40 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
PostgreSQL-interfaces <pgsql-interfaces@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Patch applied. Thanks.
Hi,
I suspect that you are not the person to send this to, but I wasn't sure
where else to mail it. I am the maintainer of unixODBC, and we have a
set of code in our project that started life as the Postgres windows
ODBC driver, which has been ported back to unix. Anyway I have just
fixed a memory leak in the driver, and I cant see any mention of the fix
being done in the main Postgres code, so I thougth I would let you know.Its in the statement.c module, after the COMMIT statement has been
executed in SC_Execute, the code was/*// If we are in autocommit, we must send the commit. */
if ( ! self->internal && CC_is_in_autocommit(conn) &&
STMT_UPDATE(self)) {
CC_send_query(conn, "COMMIT", NULL);
CC_set_no_trans(conn);
}I have changed it to
/*// If we are in autocommit, we must send the commit. */
if ( ! self->internal && CC_is_in_autocommit(conn) &&
STMT_UPDATE(self)) {
res = CC_send_query(conn, "COMMIT", NULL);
QR_Destructor(res);
CC_set_no_trans(conn);
}Nick Gorham
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 14 08:17:49 2000
Received: from acheron.rime.com.au (root@albatr.lnk.telstra.net
[139.130.54.222]) by hub.org (8.9.3/8.9.3) with ESMTP id IAA36304
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 08:17:26 -0500 (EST)
(envelope-from pjw@rhyme.com.au)
Received: from oberon (Oberon.rime.com.au [203.8.195.100])
by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id AAA26946;
Tue, 15 Feb 2000 00:16:55 +1100
Message-Id: <3.0.5.32.20000215001755.03435430@mail.rhyme.com.au>
X-Sender: pjw@mail.rhyme.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 15 Feb 2000 00:17:55 +1100
To: Chris <chris@bitmead.com>, pgsql-hackers@postgreSQL.org
From: Philip Warner <pjw@rhyme.com.au>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
In-Reply-To: <38A7F134.822B6062@bitmead.com>
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.>
<3.0.1.32.20000213205901.01706710@mail.pacifier.com>
<38A79295.BF844BE7@nimrod.itg.telecom.com.au>
<38A7CDE1.B3005B98@tm.ee> <38A7EB66.7D2A880B@bitmead.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 23:12 14/02/00 +1100, Chris wrote:
How about this as a compromise:
If you give an offset without an ORDER BY the offset
is useless if this optimisation is in place. If you
allowed the offset with the optimisation and no
order by it would be encouraging broken behaviour.
Not that I would do this necessarily, but
select * from t where <stuff> offset 1 limit 1
is a valid way of checking for duplicates. I would hate to see the
optimization turned off in this case.
So therefore it would be reasonable to optimise a
limit,offset query with no order by as if there were
no offset. This would give consistent results, albeit
it may not choose the best plan. But at least it
won't hurt anyone.
...etc
The problem with using a stateless connection is that you have no
transaction control, so can not control table contents between calls. eg.
if it contains:
f
-
abel tasman
charles sturt
ferdinand marcos
(spot the odd one out)
and do a 'select * from t order by f offset 0 limit 2', then someone adds
'bruce stringsteen' and you try to get the next two rows via 'select * from
t order by f offset 2 limit 2', you will get 'charles sturt' again, and
miss bruce.
Either you have to say that the database is almost never updated (ie. it's
just a copy of real data, used for web applications), in which case you can
add all sorts of fields for optimizing stateless calls (notably an ID
field), or you have to implement some kind of state preservation, and dump
ID's into a temporary table or use 'held' cursors, which is not really that
hard [Don't know if PG supports either, but you can 'fake' temporary tables
pretty easily].
I may have missed something in what you need, but someone else has already
mentioned using 'MOVE' within a cursor, and it still seems to me that
putting the optimizer through hoops to achieve the result is liable to be a
problem in the long term.
eg. The Dec/Rdb optimizer actually assesses it's strategy while it's
running. If the query is taking too long, or the estimates it used prove
too inaccurate, it may change strategy. If PG implemented such a thing,
then this whole approach to offset/limit would be blown away - a strategy
will change depending on the data retrieved. It would be a pity if this
sort of improvement in the optimizer were blocked because of problems
caused by breaking successive calls to offset/limit queries.
Maybe either 'held cursors' or 'local temporary tables' could be added to
the ToDo list for a future release.
As to documenting the behaviour, I suspect that any NOTICE should also say
'This behaviour may change in the future - don't rely on it unless you like
living dangerously'.
Just my 0.02c, but I don't like putting limits on an optimizer.
As an aside, and because I like bringing this thing up, stored query
strategies would solve the problem for selected queries; you could specify
the strategy to be used in all executions of a prticular query...maybe this
could go on the ToDo list? ;-}
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
From bouncefilter Mon Feb 14 09:04:49 2000
Received: from support.ddiworld.com ([147.72.93.229])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA45197
for <pgsql-hackers@postgresql.org>;
Mon, 14 Feb 2000 09:04:04 -0500 (EST)
(envelope-from jreed@support.ddiworld.com)
Received: (from jreed@localhost)
by support.ddiworld.com (8.9.3/8.9.3) id JAA02226
for pgsql-hackers@postgresql.org; Mon, 14 Feb 2000 09:03:34 -0500
Date: Mon, 14 Feb 2000 09:03:34 -0500
From: Joel Reed <jreed@ddiworld.com>
To: pgsql-hackers@postgresql.org
Subject: patch for binding tuples from result set to user allocated memory
Message-ID: <20000214090334.D31487@ddiworld.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="1SQmhf2mF2YjsYvc"
X-Mailer: Mutt 1.0i
--1SQmhf2mF2YjsYvc
Content-Type: text/plain; charset=us-ascii
Having been used to being able to bind tuple data from a result set to
user allocated memory (rather than having to copy the data out of the
"libpq" like API's buffers to my memory locations) in my days working
with ODBC, Oracle & SQLServer's C-API, i created the following patch
which i thought i'd submit. I've included a README as well.
if anyone has a second it would be great to know if i'm doing something
stupid or if there's anything i could do to get this patch to libpq in
the mainline releases. please CC: me as i'm not on this list. thanks.
jr
FROM THE README:
POSTGRESQL BIND PATCH FOR POSTGRESQL VERSION 6.5.3
1). INTRODUCTION
anyone interested in a very simple binding API for PGSQL-libpq that has very little
impact on the libpq source code should read on.
the API is accessed through the following two functions:
extern void PQsetResultDest(PGconn *conn, PGresAttValue* dest);
extern void PQclearResultDest(PGconn *conn);
which are found in libpq-fe.h once the patch is applied.
2). HOW DO I USE THESE FUNCTIONS?
use libpq as normal, however when you want to bind the columns of a result set to
specific memory locations...
a). construct an array of PGresAttValue's whose size is equal to the number of
columns in the result set. if you don't you'll core dump!
i.e. for "select id, name from people"
PGresAttValue bind_vec[2];
b). fill out the vector with the binding info. specifically each PGresAttValue
must have a valid "value" ptr of the desired destination address, and
and "len" that is equal to or bigger than the length of the column that will
be returned.
c). immediately before calling PQexec on a "FETCH FORWARD 1" sql statement call
PQsetResultDest(conn, bind_vec);
d). immediately after PQexec returns, call
PQclearResultDest(conn);
e). that's it. now the results of the fetch are in the memory locations
you set up in your PGresAttValue array.
3). EXTRA INFO
a). if (PGresAttValue[i].len > column[i].len) then this patch will append a null
terminator to the value. this happens to be very convenient when using
strings.
b). if (0==PGresAttValue[i].len) for any column i, then that column will
not be bound but will be accessible through standard libpq API.
4). BIGGER CODE SAMPLE
here's a more in depth code sample for a interface layer we have that sits on top
of libpq (it uses the stdc++ library vector for the bind_vec shown above, and doesn't show step two which happens elsewhere) ...
bool CCursorPGSql::fetch() throw (CDbError)
{
// build sql
tchar cmd[128];
if (-1==snprintf(cmd, sizeof(cmd), "FETCH FORWARD 1 IN %s", cursor_name))
{
CDbError err;
snprintf(err.message, sizeof(err.message),
_text("fetch: cmd buffer too short"));
throw err;
}
// setup bind locations
if (bind_vector.size()>0)
PQsetResultDest(db->postgres_handle(), bind_vector.begin());
// execute it
pg::result res(PQexec(db->postgres_handle(), cmd));
const int rc = PQresultStatus(res);
if (PGRES_BAD_RESPONSE==rc || PGRES_NONFATAL_ERROR==rc || PGRES_FATAL_ERROR==rc) THROW_DBERROR(db->postgres_handle());
// clear bindings on connection
if (bind_vector.size()>0)
PQclearResultDest(db->postgres_handle());
// return code means any data returned?
return (PQntuples(res));
}
and the patch itself (against 6.5.2 but cleanly applies to 6.5.3)
diff -u postgresql-6.5.2/src/interfaces/libpq/fe-exec.c postgresql-6.5.2-with-bind/src/interfaces/libpq/fe-exec.c
--- postgresql-6.5.2/src/interfaces/libpq/fe-exec.c Thu May 27 21:54:53 1999
+++ postgresql-6.5.2-with-bind/src/interfaces/libpq/fe-exec.c Thu Oct 21 15:32:28 1999
@@ -869,19 +869,53 @@
vlen = vlen - 4;
if (vlen < 0)
vlen = 0;
- if (tup[i].value == NULL)
- {
+ if ((conn->tuple_destinations == NULL) ||
+ (0==conn->tuple_destinations[i].len_max))
+ {
+
+ if (tup[i].value == NULL)
+ {
tup[i].value = (char *) pqResultAlloc(result, vlen + 1, binary);
if (tup[i].value == NULL)
- goto outOfMemory;
- }
- tup[i].len = vlen;
- /* read in the value */
- if (vlen > 0)
- if (pqGetnchar((char *) (tup[i].value), vlen, conn))
+ goto outOfMemory;
+ }
+
+ /* read in the value */
+ if (vlen > 0)
+ if (pqGetnchar((char *) (tup[i].value), vlen, conn))
+ return EOF;
+ /* we have to terminate this ourselves */
+ tup[i].value[vlen] = '\0';
+ }
+ else
+ {
+ if (conn->tuple_destinations[i].len_max < vlen)
+ {
+ pqClearAsyncResult(conn);
+ sprintf(conn->errorMessage,
+ "getAnotherTuple() -- column %d is %d bytes larger than bound destination\n", i, vlen-conn->tuple_destinations[i].len_max);
+ conn->result = PQmakeEmptyPGresult(conn, PGRES_FATAL_ERROR);
+ conn->asyncStatus = PGASYNC_READY;
+ /* Discard the broken message */
+ conn->inStart = conn->inEnd;
return EOF;
- /* we have to terminate this ourselves */
- tup[i].value[vlen] = '\0';
+ }
+
+ /* we set length returned no matter what */
+ *(conn->tuple_destinations[i].len_returned) = vlen;
+
+ /* read in the value */
+ if (vlen > 0)
+ {
+ if (pqGetnchar((char *) (conn->tuple_destinations[i].value), vlen, conn))
+ return EOF;
+
+ /* we only null terminate when there's space */
+ if (conn->tuple_destinations[i].len_max > vlen)
+ conn->tuple_destinations[i].value[vlen] = '\0';
+ }
+ }
+ tup[i].len = vlen;
}
/* advance the bitmap stuff */
bitcnt++;
@@ -1921,4 +1955,18 @@
return 1;
else
return 0;
+}
+
+void
+PQsetResultDest(PGconn* conn, PGbinding* _dest)
+{
+ if (0==conn) return;
+ conn->tuple_destinations = _dest;
+}
+
+void
+PQclearResultDest(PGconn* conn)
+{
+ if (0==conn) return;
+ conn->tuple_destinations = 0;
}
diff -u postgresql-6.5.2/src/interfaces/libpq/libpq-fe.h postgresql-6.5.2-with-bind/src/interfaces/libpq/libpq-fe.h
--- postgresql-6.5.2/src/interfaces/libpq/libpq-fe.h Tue May 25 12:15:13 1999
+++ postgresql-6.5.2-with-bind/src/interfaces/libpq/libpq-fe.h Thu Oct 21 15:37:04 1999
@@ -27,6 +27,13 @@/* Application-visible enum types */
+ typedef struct pgbinding
+ {
+ int len_max; /* [IN] length in bytes of the value buffer */
+ int* len_returned; /* [OUT] pointer to int that receives bytes returned */
+ char* value; /* [OUT] actual value returned */
+ } PGbinding;
+
typedef enum
{
CONNECTION_OK,
@@ -198,6 +205,10 @@
void *arg); /* === in fe-exec.c === */
+
+ /* result destinationn functions (for column binding and other things...)*/
+ extern void PQsetResultDest(PGconn *conn, PGbinding* dest);
+ extern void PQclearResultDest(PGconn *conn); /* Simple synchronous query */
extern PGresult *PQexec(PGconn *conn, const char *query);
Only in postgresql-6.5.2-with-bind/src/interfaces/libpq: libpq-fe.h~
diff -u postgresql-6.5.2/src/interfaces/libpq/libpq-int.h postgresql-6.5.2-with-bind/src/interfaces/libpq/libpq-int.h
--- postgresql-6.5.2/src/interfaces/libpq/libpq-int.h Tue May 25 18:43:49 1999
+++ postgresql-6.5.2-with-bind/src/interfaces/libpq/libpq-int.h Thu Oct 21 15:34:36 1999
@@ -217,6 +217,9 @@
PGresult *result; /* result being constructed */
PGresAttValue *curTuple; /* tuple currently being read */+ /* optional column bind location */
+ PGbinding *tuple_destinations;
+
/* Message space. Placed last for code-size reasons. */
char errorMessage[ERROR_MSG_LENGTH];
};------------------------------------------------------------------------
Joel W. Reed http://ruby.ddiworld.com/jreed
----------------We're lost, but we're making good time.----------------
--1SQmhf2mF2YjsYvc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=bind-patch
Only in postgresql-6.5.2-with-bind/src/interfaces/libpq: Makefile
Only in postgresql-6.5.2-with-bind/src/interfaces/libpq: dllist.c
Only in postgresql-6.5.2-with-bind/src/interfaces/libpq: dllist.o
Only in postgresql-6.5.2-with-bind/src/interfaces/libpq: fe-auth.o
Only in postgresql-6.5.2-with-bind/src/interfaces/libpq: fe-connect.o
diff -u postgresql-6.5.2/src/interfaces/libpq/fe-exec.c postgresql-6.5.2-with-bind/src/interfaces/libpq/fe-exec.c
--- postgresql-6.5.2/src/interfaces/libpq/fe-exec.c Thu May 27 21:54:53 1999
+++ postgresql-6.5.2-with-bind/src/interfaces/libpq/fe-exec.c Thu Oct 21 15:32:28 1999
@@ -869,19 +869,53 @@
vlen = vlen - 4;
if (vlen < 0)
vlen = 0;
- if (tup[i].value == NULL)
- {
+ if ((conn->tuple_destinations == NULL) ||
+ (0==conn->tuple_destinations[i].len_max))
+ {
+
+ if (tup[i].value == NULL)
+ {
tup[i].value = (char *) pqResultAlloc(result, vlen + 1, binary);
if (tup[i].value == NULL)
- goto outOfMemory;
- }
- tup[i].len = vlen;
- /* read in the value */
- if (vlen > 0)
- if (pqGetnchar((char *) (tup[i].value), vlen, conn))
+ goto outOfMemory;
+ }
+
+ /* read in the value */
+ if (vlen > 0)
+ if (pqGetnchar((char *) (tup[i].value), vlen, conn))
+ return EOF;
+ /* we have to terminate this ourselves */
+ tup[i].value[vlen] = '\0';
+ }
+ else
+ {
+ if (conn->tuple_destinations[i].len_max < vlen)
+ {
+ pqClearAsyncResult(conn);
+ sprintf(conn->errorMessage,
+ "getAnotherTuple() -- column %d is %d bytes larger than bound destination\n", i, vlen-conn->tuple_destinations[i].len_max);
+ conn->result = PQmakeEmptyPGresult(conn, PGRES_FATAL_ERROR);
+ conn->asyncStatus = PGASYNC_READY;
+ /* Discard the broken message */
+ conn->inStart = conn->inEnd;
return EOF;
- /* we have to terminate this ourselves */
- tup[i].value[vlen] = '\0';
+ }
+
+ /* we set length returned no matter what */
+ *(conn->tuple_destinations[i].len_returned) = vlen;
+
+ /* read in the value */
+ if (vlen > 0)
+ {
+ if (pqGetnchar((char *) (conn->tuple_destinations[i].value), vlen, conn))
+ return EOF;
+
+ /* we only null terminate when there's space */
+ if (conn->tuple_destinations[i].len_max > vlen)
+ conn->tuple_destinations[i].value[vlen] = '\0';
+ }
+ }
+ tup[i].len = vlen;
}
/* advance the bitmap stuff */
bitcnt++;
@@ -1921,4 +1955,18 @@
return 1;
else
return 0;
+}
+
+void
+PQsetResultDest(PGconn* conn, PGbinding* _dest)
+{
+ if (0==conn) return;
+ conn->tuple_destinations = _dest;
+}
+
+void
+PQclearResultDest(PGconn* conn)
+{
+ if (0==conn) return;
+ conn->tuple_destinations = 0;
}
Only in postgresql-6.5.2-with-bind/src/interfaces/libpq: fe-exec.c~
Only in postgresql-6.5.2-with-bind/src/interfaces/libpq: fe-exec.o
Only in postgresql-6.5.2-with-bind/src/interfaces/libpq: fe-lobj.o
Only in postgresql-6.5.2-with-bind/src/interfaces/libpq: fe-misc.o
Only in postgresql-6.5.2-with-bind/src/interfaces/libpq: fe-print.o
diff -u postgresql-6.5.2/src/interfaces/libpq/libpq-fe.h postgresql-6.5.2-with-bind/src/interfaces/libpq/libpq-fe.h
--- postgresql-6.5.2/src/interfaces/libpq/libpq-fe.h Tue May 25 12:15:13 1999
+++ postgresql-6.5.2-with-bind/src/interfaces/libpq/libpq-fe.h Thu Oct 21 15:37:04 1999
@@ -27,6 +27,13 @@/* Application-visible enum types */
+ typedef struct pgbinding
+ {
+ int len_max; /* [IN] length in bytes of the value buffer */
+ int* len_returned; /* [OUT] pointer to int that receives bytes returned */
+ char* value; /* [OUT] actual value returned */
+ } PGbinding;
+
typedef enum
{
CONNECTION_OK,
@@ -198,6 +205,10 @@
void *arg); /* === in fe-exec.c === */
+
+ /* result destinationn functions (for column binding and other things...)*/
+ extern void PQsetResultDest(PGconn *conn, PGbinding* dest);
+ extern void PQclearResultDest(PGconn *conn); /* Simple synchronous query */
extern PGresult *PQexec(PGconn *conn, const char *query);
Only in postgresql-6.5.2-with-bind/src/interfaces/libpq: libpq-fe.h~
diff -u postgresql-6.5.2/src/interfaces/libpq/libpq-int.h postgresql-6.5.2-with-bind/src/interfaces/libpq/libpq-int.h
--- postgresql-6.5.2/src/interfaces/libpq/libpq-int.h Tue May 25 18:43:49 1999
+++ postgresql-6.5.2-with-bind/src/interfaces/libpq/libpq-int.h Thu Oct 21 15:34:36 1999
@@ -217,6 +217,9 @@
PGresult *result; /* result being constructed */
PGresAttValue *curTuple; /* tuple currently being read */+ /* optional column bind location */
+ PGbinding *tuple_destinations;
+
/* Message space. Placed last for code-size reasons. */
char errorMessage[ERROR_MSG_LENGTH];
};
Only in postgresql-6.5.2-with-bind/src/interfaces/libpq: libpq-int.h~
Only in postgresql-6.5.2-with-bind/src/interfaces/libpq: libpq.a
Only in postgresql-6.5.2-with-bind/src/interfaces/libpq: libpq.so
Only in postgresql-6.5.2-with-bind/src/interfaces/libpq: libpq.so.2
Only in postgresql-6.5.2-with-bind/src/interfaces/libpq: libpq.so.2.0
Only in postgresql-6.5.2-with-bind/src/interfaces/libpq: pqsignal.o--1SQmhf2mF2YjsYvc--
From bouncefilter Mon Feb 14 10:45:47 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA66438
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 10:45:20 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA24078;
Mon, 14 Feb 2000 07:44:35 -0800 (PST)
Message-Id: <3.0.1.32.20000214064732.010ae660@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 14 Feb 2000 06:47:32 -0800
To: chris@bitmead.com, pgsql-hackers@postgreSQL.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
In-Reply-To: <38A79295.BF844BE7@nimrod.itg.telecom.com.au>
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.>
<3.0.1.32.20000213205901.01706710@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 04:28 PM 2/14/00 +1100, Chris Bitmead wrote:
LIMIT is not SQL
No, of course not but of course you're ignoring my point
My predudices are caused by what I use PostgreSQL for, which is
more favourable to the latter.
This, actually, IS my primary point. Tailoring a product to your
personal prejudices when it is meant to be used by a very wide
range of folks is not wise.
If Postgres is to be tailored to any particular person's
prejudices, why yours and not mine? Or Tom's? Or Bruce's?
The reality is that the developers apparently made the decision
to make Postgres into a real, albeit open source, product with
the intention that it receive wide use.
THAT - or so I believe - is the goal, not to tailor it to
any one person (or any small set of persons) particular prejudices.
That, for instance, is why it was decided to turn PG into an SQL92
compliant RDBMS.
- 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 Feb 14 09:51:49 2000
Received: from alert.infoplease.com ([208.222.166.25])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA54453
for <pgsql-hackers@postgresql.org>;
Mon, 14 Feb 2000 09:51:37 -0500 (EST)
(envelope-from kdebisschop@range.infoplease.com)
Received: from skillet.infoplease.com (skillet [10.0.1.212])
by alert.infoplease.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09849
for <pgsql-hackers@postgresql.org>;
Mon, 14 Feb 2000 09:51:05 -0500 (EST)
Received: (from kdebisschop@localhost)
by skillet.infoplease.com (8.9.3/8.9.1) id JAA28380;
Mon, 14 Feb 2000 09:51:06 -0500
Date: Mon, 14 Feb 2000 09:51:06 -0500
Message-Id: <200002141451.JAA28380@skillet.infoplease.com>
X-Authentication-Warning: skillet.infoplease.com: kdebisschop set sender to
kdebisschop@spaceheater.infoplease.com using -f
From: Karl DeBisschop <kdebisschop@range.infoplease.com>
To: pgsql-hackers@postgresql.org
In-reply-to: <Pine.LNX.4.21.0002121844190.456-100000@localhost.localdomain>
(message from Peter Eisentraut on Sun, 13 Feb 2000 22:43:15 +0100
(CET))
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Reply-to: kdebisschop@range.infoplease.com
References: <Pine.LNX.4.21.0002121844190.456-100000@localhost.localdomain>
4. Fascist variant of #3: make LIMIT without ORDER BY be an error.
Got my vote for that. At least make it a notice: "NOTICE: LIMIT without
ORDER BY results in random data being returned" -- That'll teach 'em. ;)
Given the nature of SQL, how could it be otherwise. Select is defined
to be unordered. This seems to advocate building a generic SQL
tutorial into postgreSQL.
I for one would very much rather not have that notice. My reasoning
is thus:
Say I need a quick shell script to verify that a table has been loaded
with reasonable values as part of a cron procedure. One way to do the
might be to make a shell script:
#!/bin/sh
if ! psql feature -tc "select * from elm limit 1" | egrep "^ +[0-9]+|" >/dev/null;
then
echo no data loaded;
fi
Thus, I cron this and get email if there is no record returned.
AFAICT, this is what should happen. But if you start adding wornings
to this perfectly valid query, which will presumedly come out on
STDERR, I will get email from this, even though the query and its
returns were valid and expected. And I don't want to direct stderr to
/dev/null because I do want to be warned if there really is an error.
Just my $0.02 worth.
--
Karl DeBisschop <kdebisschop@alert.infoplease.com>
617.832.0332 (Fax: 617.956.2696)
Information Please - your source for FREE online reference
http://www.infoplease.com - Your Ultimate Fact Finder
http://kids.infoplease.com - The Great Homework Helper
Netsaint Plugins Development
http://netsaintplug.sourceforge.net
From bouncefilter Mon Feb 14 10:45:58 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA66400
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 10:45:13 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA24121;
Mon, 14 Feb 2000 07:44:39 -0800 (PST)
Message-Id: <3.0.1.32.20000214065918.01708540@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 14 Feb 2000 06:59:18 -0800
To: Hannu Krosing <hannu@tm.ee>, chris@bitmead.com
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <38A7CDE1.B3005B98@tm.ee>
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.>
<3.0.1.32.20000213205901.01706710@mail.pacifier.com>
<38A79295.BF844BE7@nimrod.itg.telecom.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 11:41 AM 2/14/00 +0200, Hannu Krosing wrote:
It's utility was much debated befor it was included in Postgres,
the main argument for inclusion being "mySQL has it and it's useful
for fast-start queries", the main argument against being "it's not SQL,
people won't understand it a and will start to misuse it".
Well, it appears people have started to misuse it! :)
Oracle has recently (8i or 8.1.6 if you prefer) offered something similar,
but it gives weird results depending on whether or not you have an index
on the column. There's a kludgey workaround, which I forget since I don't
use Oracle, only laugh maniacly when it fails to install on a linux box
with less than 256MB combined RAM and swap space (i.e. virtual memory).
Maybe we should still discourage the use of LIMIT, and rather introduce
another "mode" for optimiser, activated by SET FastStart TO 'ON'.
Then queries with limit could be rewritten into
SET FastStart to 'ON';
DECLARE
MOVE
FETCH
CLOSE
SET FastStart to PREVIOUS_VALUE;also maybe we will need PUSH/POP for set commands ?
Well...personally I don't see LIMIT as being particularly harmful,
and it is a convenience. Remember, for the web space you're speaking
of keeping overhead low is a real concern, and requiring a series
of queries where currently only one needed will probably go over like
a lead ballon.
If the documentation actually pointed out that LIMIT in the absence
of an ORDER BY clause probably doesn't do what you want, fewer folks
might expect it to work any differently than it does.
- 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 Feb 14 10:45:49 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA66390
for <pgsql-hackers@postgresql.org>;
Mon, 14 Feb 2000 10:45:09 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA24130;
Mon, 14 Feb 2000 07:44:40 -0800 (PST)
Message-Id: <3.0.1.32.20000214070519.0170d150@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 14 Feb 2000 07:05:19 -0800
To: Chris <chris@bitmead.com>, pgsql-hackers@postgresql.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
In-Reply-To: <38A7EB66.7D2A880B@bitmead.com>
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.>
<3.0.1.32.20000213205901.01706710@mail.pacifier.com>
<38A79295.BF844BE7@nimrod.itg.telecom.com.au>
<38A7CDE1.B3005B98@tm.ee>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 10:47 PM 2/14/00 +1100, Chris wrote:
Only that it's non intuitive that ORDER BY should change the actual
results of a series of LIMIT queries, not just the order. If there are
100 records, and I do 10x LIMIT 10,offset queries one might expect to
get all 100 records.
The only person who will expect that is the person who hasn't bothered
to learn the fundamental SQL property that rows returned by queries
come back in non-deterministic order.
This is a FUNDAMENTAL concept in SQL, one that is mentioned in every
SQL book I've seen.
The same person probably expects NULL = NULL to return true, too.
So what?
And currently you do (barring something unusual
like a vacuum at an inopportune moment that drastically changes
statistics).
Or an insert by another back end, not at all uncommon in the
kind of web environment where this construct is frequently
used.
I'm just playing devils advocate here. Changing this is probably not
going to hurt me, I just think it could confuse a lot of people.
See above.
- 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 Feb 14 10:45:59 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA66395
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 10:45:11 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA24152;
Mon, 14 Feb 2000 07:44:43 -0800 (PST)
Message-Id: <3.0.1.32.20000214071401.01706e10@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 14 Feb 2000 07:14:01 -0800
To: Chris <chris@bitmead.com>, pgsql-hackers@postgresql.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
In-Reply-To: <38A7F134.822B6062@bitmead.com>
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.>
<3.0.1.32.20000213205901.01706710@mail.pacifier.com>
<38A79295.BF844BE7@nimrod.itg.telecom.com.au>
<38A7CDE1.B3005B98@tm.ee> <38A7EB66.7D2A880B@bitmead.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 11:12 PM 2/14/00 +1100, Chris wrote:
So therefore it would be reasonable to optimise a
limit,offset query with no order by as if there were
no offset. This would give consistent results, albeit
it may not choose the best plan. But at least it
won't hurt anyone.
Why bother?
It will only give consistent results if the table doesn't
change, which is only likely to be during testing if the
table is one which is inserted into, updated, and the like
during production, such as is true of bulletin boards and
the like.
And you normally want to order such queries anyway, by date
or by some ranking criteria.
You are making a mountain out of a molehill, here. Or,
a mountain out of a playa, there's really no molehill
even because your code's broken to begin with.
If this optimisation is implemented, are we going to
carefully explain exactly when an ORDER BY clause will
and won't yield consistent results? Because not just
any ORDER BY is good enough.
This is already true in SQL as it is, EVEN WITHOUT
LIMIT. If your ORDER BY isn't good enough, each time
you query the db you might get rows back in a different
order.
Even if you grab all the rows and walk through them
yourself, discarding the first OFFSET rows and processing
the LIMIT rows, when you revisit and start over you have
exactly the SAME non-determinancy to worry about.
It has nothing to do with LIMIT, Chris. It really doesn't.
It has to do with your desire to make broken code "work"
in a very limited set of circumstances that don't match
real world conditions often at all.
- 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 Feb 14 10:55:48 2000
Received: from homeworld.bigpanda.org
(IDENT:root@client-151-198-27-104.bellatlantic.net [151.198.27.104])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA68450
for <pgsql-hackers@postgresql.org>;
Mon, 14 Feb 2000 10:55:17 -0500 (EST)
(envelope-from acroyear@homeworld.bigpanda.org)
Received: from homeworld.bigpanda.org (IDENT:acroyear@localhost.awc.net
[127.0.0.1])
by homeworld.bigpanda.org (8.9.3/8.9.3) with ESMTP id KAA10767
for <pgsql-hackers@postgresql.org>; Mon, 14 Feb 2000 10:55:14 -0500
Message-Id: <200002141555.KAA10767@homeworld.bigpanda.org>
To: pgsql-hackers@postgresql.org
From: sszabo@bigpanda.com
Subject: Limit and Order by stuff
Date: Mon, 14 Feb 2000 10:55:14 -0500
Sender: acroyear@bigpanda.com
Actually, even currently, limit and order a non unique
order by can skip results if the table is being modified.
Even if no new rows are entered, as long as a row
on the border of the limit has been modified, you can
get indeterminate results.
acroyear=> create table test1 (a int, b varchar(10), c int);
CREATE
acroyear=> insert into test1 values (1, 'a', 1);
INSERT 748222 1
acroyear=> insert into test1 values (2, 'a', 1);
INSERT 748223 1
acroyear=> insert into test1 values (3, 'a', 1);
INSERT 748224 1
acroyear=> insert into test1 values (4, 'a', 1);
INSERT 748225 1
acroyear=> insert into test1 values (4, 'b', 2);
INSERT 748226 1
acroyear=> insert into test1 values (5, 'a', 1);
INSERT 748227 1
acroyear=> insert into test1 values (6, 'a', 1);
INSERT 748228 1
acroyear=> insert into test1 values (7, 'a', 1);
INSERT 748229 1
acroyear=> select a,b from test1 order by a limit 4;
a|b
-+-
1|a
2|a
3|a
4|a
(4 rows)
acroyear=> update test1 set c=3 where a=4 and b='a';
UPDATE 1
acroyear=> select a,b from test1 order by a offset 4 limit 4;
a|b
-+-
4|a
5|a
6|a
7|a
(4 rows)
From bouncefilter Mon Feb 14 11:00:58 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 LAA69903
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 11:00:21 -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 LAA19024;
Mon, 14 Feb 2000 11:00:16 -0500 (EST)
To: prlw1@cam.ac.uk
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Another nasty cache problem
In-reply-to: <20000214112356.A13823@quartz.newn.cam.ac.uk>
References: <20000131191356.B8582@quartz.newn.cam.ac.uk>
<12080.949370550@sss.pgh.pa.us>
<20000203112434.B1509@quartz.newn.cam.ac.uk>
<1426.949641960@sss.pgh.pa.us>
<20000204171153.D3402@quartz.newn.cam.ac.uk>
<4803.949697937@sss.pgh.pa.us>
<20000205143515.F3402@quartz.newn.cam.ac.uk>
<7988.949771109@sss.pgh.pa.us>
<20000211210441.A11976@quartz.newn.cam.ac.uk>
<21865.950311112@sss.pgh.pa.us>
<20000214112356.A13823@quartz.newn.cam.ac.uk>
Comments: In-reply-to Patrick Welche <prlw1@newn.cam.ac.uk>
message dated "Mon, 14 Feb 2000 11:23:56 +0000"
Date: Mon, 14 Feb 2000 11:00:16 -0500
Message-ID: <19021.950544016@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
+ if (!string) + elog(ERROR, "Trying to convert NULL text to integer (int2)");
This is unreasonable behavior. The correct patch is just
if (!string)
return 0;
which will allow the function manager to plow ahead with returning the
NULL that it's going to return anyway. See the past pghackers threads
about redesigning the function manager interface if you don't understand
what's going on here.
regards, tom lane
From bouncefilter Mon Feb 14 11:14:50 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 LAA73512
for <pgsql-hackers@postgresql.org>;
Mon, 14 Feb 2000 11:14:43 -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 12KO9G-0002gI-00; Mon, 14 Feb 2000 16:14:54 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12KO96-0003nG-00; Mon, 14 Feb 2000 16:14:44 +0000
Date: Mon, 14 Feb 2000 16:14:44 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Another nasty cache problem
Message-ID: <20000214161444.D13823@quartz.newn.cam.ac.uk>
Reply-To: prlw1@cam.ac.uk
References: <20000203112434.B1509@quartz.newn.cam.ac.uk>
<1426.949641960@sss.pgh.pa.us>
<20000204171153.D3402@quartz.newn.cam.ac.uk>
<4803.949697937@sss.pgh.pa.us>
<20000205143515.F3402@quartz.newn.cam.ac.uk>
<7988.949771109@sss.pgh.pa.us>
<20000211210441.A11976@quartz.newn.cam.ac.uk>
<21865.950311112@sss.pgh.pa.us>
<20000214112356.A13823@quartz.newn.cam.ac.uk>
<19021.950544016@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
In-Reply-To: <19021.950544016@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Mon, Feb 14, 2000 at 11:00:16AM -0500
On Mon, Feb 14, 2000 at 11:00:16AM -0500, Tom Lane wrote:
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
+ if (!string) + elog(ERROR, "Trying to convert NULL text to integer (int2)");This is unreasonable behavior. The correct patch is just
if (!string)
return 0;which will allow the function manager to plow ahead with returning the
NULL that it's going to return anyway. See the past pghackers threads
about redesigning the function manager interface if you don't understand
what's going on here.
Off top of head, that means that null and the string "0" both return 0..
OK - I'll look for the mail thread.
Cheers,
Patrick
From bouncefilter Mon Feb 14 11:50:48 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA81192
for <pgsql-hackers@postgresql.org>;
Mon, 14 Feb 2000 11:50:41 -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 MAA54481
for <pgsql-hackers@postgresql.org>;
Mon, 14 Feb 2000 12:50:36 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 14 Feb 2000 12:50:36 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: Programmers needed to implement Replication ...
Message-ID: <Pine.BSF.4.21.0002141241340.74045-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
PostgreSQL, Inc has been approached by a third party concerning getting
Replication implemented. Currently, we are seeking resume's and rates for
any developer that would be interested in, and has the time to, work on
such.
Interested ppl should have a strong C background, knowledge of PostgreSQL
internals and the ability to work with others ... basically, the end
result has to be approved by the PostgreSQL Core Team to be acceptable.
Resume/CVs should be forwarded to jeff@pgsql.com
Also, if any other companies and/or individuals would like to help fund
this, please contact jeff@pgsql.com, who will act as liason ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Feb 14 12:12:50 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 MAA85568;
Mon, 14 Feb 2000 12:12: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 RAA00305;
Mon, 14 Feb 2000 17:16:10 GMT
Sender: lockhart@hub.org
Message-ID: <38A8385A.3D53C38B@alumni.caltech.edu>
Date: Mon, 14 Feb 2000 17:16:10 +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>,
Postgres Patches List <patches@postgreSQL.org>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [PATCHES] Re: [HACKERS] Almost there on column aliases
References: <200002141646.LAA20282@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Looks good. Very clear. C structure changes appear minimal.
Bruce (aka King of patchers :)
I've got a slightly modified patchset to apply this evening (though if
you have already applied this one it won't be a big problem). Will do
it in ~8 hours, barring network troubles at hub.org ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Feb 14 12:30: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 MAA90536;
Mon, 14 Feb 2000 12:30: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
MAA21907;
Mon, 14 Feb 2000 12:28:00 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002141728.MAA21907@candle.pha.pa.us>
Subject: Re: [PATCHES] Re: [HACKERS] Almost there on column aliases
In-Reply-To: <38A8385A.3D53C38B@alumni.caltech.edu> from Thomas Lockhart at
"Feb 14, 2000 05:16:10 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Mon, 14 Feb 2000 12:28:00 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>,
Postgres Patches List <patches@postgreSQL.org>,
Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Looks good. Very clear. C structure changes appear minimal.
Bruce (aka King of patchers :)
I've got a slightly modified patchset to apply this evening (though if
you have already applied this one it won't be a big problem). Will do
it in ~8 hours, barring network troubles at hub.org ;)
No, I don't apply for committers. I know they prefer to do their own.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 14 14:28:53 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 OAA13472
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 14:28:29 -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 OAA22631;
Mon, 14 Feb 2000 14:27:49 -0500 (EST)
To: Philip Warner <pjw@rhyme.com.au>
cc: Chris <chris@bitmead.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
In-reply-to: <3.0.5.32.20000215001755.03435430@mail.rhyme.com.au>
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.>
<3.0.1.32.20000213205901.01706710@mail.pacifier.com>
<38A79295.BF844BE7@nimrod.itg.telecom.com.au>
<38A7CDE1.B3005B98@tm.ee> <38A7EB66.7D2A880B@bitmead.com>
<3.0.5.32.20000215001755.03435430@mail.rhyme.com.au>
Comments: In-reply-to Philip Warner <pjw@rhyme.com.au>
message dated "Tue, 15 Feb 2000 00:17:55 +1100"
Date: Mon, 14 Feb 2000 14:27:49 -0500
Message-ID: <22628.950556469@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Philip Warner <pjw@rhyme.com.au> writes:
Just my 0.02c, but I don't like putting limits on an optimizer.
That's my feeling too. I'm leaning towards letting the optimizer do the
best it can with the given query (which means using OFFSET+LIMIT as the
estimated number of tuples to be fetched), and documenting the potential
gotcha as best we can. Something like:
CAUTION: if you repeat a query several times with different OFFSET or
LIMIT values to fetch different portions of the whole result, you will
find that you get inconsistent results unless you specify an ORDER BY
condition that is strong enough to ensure that all selected tuples must
appear in a unique order. Without ORDER BY, the system is free to
return the tuples in any order it finds convenient --- and it may well
make different implementation choices leading to different orderings
depending on the OFFSET and LIMIT values. In general, you should be
very wary of using OFFSET or LIMIT with an unordered or partially
ordered query; you will get a difficult-to-predict, implementation-
dependent subset of the selected tuples.
Is that clear enough? Can anyone improve on the wording?
regards, tom lane
From bouncefilter Mon Feb 14 14:40:51 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA15872
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 14:40:14 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id LAA29588;
Mon, 14 Feb 2000 11:38:47 -0800 (PST)
Message-Id: <3.0.1.32.20000214113634.01068620@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 14 Feb 2000 11:36:34 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, Philip Warner <pjw@rhyme.com.au>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Cc: Chris <chris@bitmead.com>, pgsql-hackers@postgreSQL.org
In-Reply-To: <22628.950556469@sss.pgh.pa.us>
References: <3.0.5.32.20000215001755.03435430@mail.rhyme.com.au>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.>
<3.0.1.32.20000213205901.01706710@mail.pacifier.com>
<38A79295.BF844BE7@nimrod.itg.telecom.com.au>
<38A7CDE1.B3005B98@tm.ee> <38A7EB66.7D2A880B@bitmead.com>
<3.0.5.32.20000215001755.03435430@mail.rhyme.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 02:27 PM 2/14/00 -0500, Tom Lane wrote:
CAUTION: if you repeat a query several times with different OFFSET or
LIMIT values to fetch different portions of the whole result, you will
find that you get inconsistent results unless you specify an ORDER BY
condition that is strong enough to ensure that all selected tuples must
appear in a unique order. Without ORDER BY, the system is free to
return the tuples in any order it finds convenient
Personally, I would generalize this and leave out the reference to
LIMIT and OFFSET, except perhaps to point out that this is one
particular construct that confuses people.
As PG matures, so will the optimizer and query engine, and people
who've written code that depends on tuples being returned in a
single consistent order might find themselves in for a rude shock.
A well-deserved one (IMO), but still a shock.
The documentation won't stop most people who want to do this
from doing so, they'll test and try to "trick" the system by
taking advantage of behavior that might not be consistent in
future releases.
Still...if it stops even ONE person from doing this, the doc will
do some good.
- 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 Feb 14 16:19: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 QAA35183
for <pgsql-hackers@postgresql.org>;
Mon, 14 Feb 2000 16:19:20 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([207.144.235.58])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id QAA03252
for <pgsql-hackers@postgresql.org>; Mon, 14 Feb 2000 16:19:25 -0500
Message-ID: <38A87153.FDD9EE7@wgcr.org>
Date: Mon, 14 Feb 2000 16:19:16 -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: Release on the 15th?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Are we still 'go' for a beta release the 15th?
Before I pull a latenighter RPM building.....it would be nice to have an
idea. TIA!
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Mon Feb 14 17:47:53 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 RAA85416
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 17:46:54 -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 RAA23921;
Mon, 14 Feb 2000 17:46:37 -0500 (EST)
To: Lamar Owen <lamar.owen@wgcr.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Release on the 15th?
In-reply-to: <38A87153.FDD9EE7@wgcr.org>
References: <38A87153.FDD9EE7@wgcr.org>
Comments: In-reply-to Lamar Owen <lamar.owen@wgcr.org>
message dated "Mon, 14 Feb 2000 16:19:16 -0500"
Date: Mon, 14 Feb 2000 17:46:36 -0500
Message-ID: <23918.950568396@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Lamar Owen <lamar.owen@wgcr.org> writes:
Are we still 'go' for a beta release the 15th?
Um ... I'm not ready ...
Couple more days, Marc?
regards, tom lane
From bouncefilter Mon Feb 14 18:34:53 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA94359
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 18:34:09 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA01662; Tue, 15 Feb 2000 10:33:36 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpduY0iu_;
Tue Feb 15 10:32:46 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA27348; Tue, 15 Feb 2000 10:32:44 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd00vvzN; Tue Feb 15 10:31:54 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA21392;
Tue, 15 Feb 2000 10:31:53 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
KAA27838; Tue, 15 Feb 2000 10:31:15 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A89009.4DE7A872@nimrod.itg.telecom.com.au>
Date: Tue, 15 Feb 2000 10:30:17 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.>
<3.0.1.32.20000213205901.01706710@mail.pacifier.com>
<38A79295.BF844BE7@nimrod.itg.telecom.com.au>
<38A7CDE1.B3005B98@tm.ee>
<3.0.1.32.20000214070519.0170d150@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Don Baccus wrote:
At 10:47 PM 2/14/00 +1100, Chris wrote:
Only that it's non intuitive that ORDER BY should change the actual
results of a series of LIMIT queries, not just the order. If there are
100 records, and I do 10x LIMIT 10,offset queries one might expect to
get all 100 records.The only person who will expect that is the person who hasn't bothered
to learn the fundamental SQL property that rows returned by queries
come back in non-deterministic order.This is a FUNDAMENTAL concept in SQL, one that is mentioned in every
SQL book I've seen.
It's a logical fact that the existance of "offset", automatically
implies
ordering, no matter how many SQL textbooks you quote.
It will only give consistent results if the table doesn't
change, which is only likely to be during testing if the
table is one which is inserted into, updated, and the like
during production, such as is true of bulletin boards and
the like.
It's actually very typical for web applications to want to search
through
historical stuff that doesn't change any more. And ordering by title
or something might not be good enough.
IMHO, that's a better reasoning that wanting to misuse LIMIT to figure
out if there are duplicates or something, just because nobody can
be bothered optimising the correct SQL to do that.
From bouncefilter Mon Feb 14 19:35:54 2000
Received: from hu.tm.ee (ppp775.tele2.ee [212.107.37.75])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA11649
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 19:35:46 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 872723B47; Tue, 15 Feb 2000 02:43:45 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38A8A141.DDDE8548@tm.ee>
Date: Tue, 15 Feb 2000 02:43:45 +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: Don Baccus <dhogaza@pacifier.com>
Cc: chris@bitmead.com, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.>
<3.0.1.32.20000213205901.01706710@mail.pacifier.com>
<38A79295.BF844BE7@nimrod.itg.telecom.com.au>
<3.0.1.32.20000214065918.01708540@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Don Baccus wrote:
At 11:41 AM 2/14/00 +0200, Hannu Krosing wrote:
Maybe we should still discourage the use of LIMIT, and rather introduceanother "mode" for optimiser, activated by SET FastStart TO 'ON'.
Then queries with limit could be rewritten into
SET FastStart to 'ON';
DECLARE
MOVE
FETCH
CLOSE
SET FastStart to PREVIOUS_VALUE;also maybe we will need PUSH/POP for set commands ?
Well...personally I don't see LIMIT as being particularly harmful,
and it is a convenience. Remember, for the web space you're speaking
of keeping overhead low is a real concern, and requiring a series
of queries where currently only one needed will probably go over like
a lead ballon.
I meant that the _backend_ could (in some distant future, when the
optimiser is perfect :) implement LIMIT as above sequence.
---------------
Hannu
From bouncefilter Mon Feb 14 19:45:00 2000
Received: from hu.tm.ee (ppp775.tele2.ee [212.107.37.75])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA12583
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 19:44:27 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id C0DFA3B47; Tue, 15 Feb 2000 02:52:25 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38A8A349.7E543AAD@tm.ee>
Date: Tue, 15 Feb 2000 02:52: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: Don Baccus <dhogaza@pacifier.com>
Cc: Chris <chris@bitmead.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.>
<3.0.1.32.20000213205901.01706710@mail.pacifier.com>
<38A79295.BF844BE7@nimrod.itg.telecom.com.au>
<38A7CDE1.B3005B98@tm.ee>
<3.0.1.32.20000214070519.0170d150@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Don Baccus wrote:
This is a FUNDAMENTAL concept in SQL, one that is mentioned in every
SQL book I've seen.The same person probably expects NULL = NULL to return true, too.
IIRC SQL3 defines different /classes/ of nulls where the above could be
true if the NULLs belong to the same class.
I.e. the absence of an orange is equal to the absence of the same orange,
but not equal to the absence of an apple (and possibly another orange) ;)
I may of course be completely wrong, as I did not read it too carefully
being after completely other things at that time.
I also could not figue out the use for such a feature.
----------------
Hannu
From bouncefilter Mon Feb 14 19:57:54 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA13890
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 19:57:50 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id QAA07385;
Mon, 14 Feb 2000 16:56:59 -0800 (PST)
Message-Id: <3.0.1.32.20000214165448.01737ec0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 14 Feb 2000 16:54:48 -0800
To: chris@bitmead.com
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Cc: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
References: <38A89009.4DE7A872@nimrod.itg.telecom.com.au>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.>
<3.0.1.32.20000213205901.01706710@mail.pacifier.com>
<38A79295.BF844BE7@nimrod.itg.telecom.com.au>
<38A7CDE1.B3005B98@tm.ee>
<3.0.1.32.20000214070519.0170d150@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 10:30 AM 2/15/00 +1100, Chris Bitmead wrote:
It's a logical fact that the existance of "offset", automatically
implies
ordering, no matter how many SQL textbooks you quote.
Chris, that is your opinion and judging from the responses of other
folks on this list, it appears to be very much a minority opinion.
Minority of one, as a matter of fact. There has been a parade
of posts disagreeing with your opinion.
Why not give up and get on with your life before I get tired of
being polite? I'm *much* more stubborn than you are, particularly
when I'm right.
- 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 Feb 14 19:55:11 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 TAA13691
for <pgsql-hackers@postgresql.org>;
Mon, 14 Feb 2000 19:54:51 -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 JAA01410; Tue, 15 Feb 2000 09:53:58 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgresql.org>, "Philip Warner" <pjw@rhyme.com.au>
Subject: RE: [HACKERS] Solution for LIMIT cost estimation
Date: Tue, 15 Feb 2000 10:00:04 +0900
Message-ID: <000301bf774f$feb8aa20$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: <22628.950556469@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 LanePhilip Warner <pjw@rhyme.com.au> writes:
Just my 0.02c, but I don't like putting limits on an optimizer.
That's my feeling too. I'm leaning towards letting the optimizer do the
best it can with the given query (which means using OFFSET+LIMIT as the
estimated number of tuples to be fetched),
What about cursors ?
I heard from Jan that we could specify 'LIMIT ALL' to tell optimizer that
the response to get first rows is needed.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Mon Feb 14 20:10:54 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA15222
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 20:10:27 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id RAA12482;
Mon, 14 Feb 2000 17:09:51 -0800 (PST)
Message-Id: <3.0.1.32.20000214170012.00efc5a0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 14 Feb 2000 17:00:12 -0800
To: Hannu Krosing <hannu@tm.ee>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Cc: chris@bitmead.com, pgsql-hackers@postgreSQL.org
In-Reply-To: <38A8A141.DDDE8548@tm.ee>
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.>
<3.0.1.32.20000213205901.01706710@mail.pacifier.com>
<38A79295.BF844BE7@nimrod.itg.telecom.com.au>
<3.0.1.32.20000214065918.01708540@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 02:43 AM 2/15/00 +0200, Hannu Krosing wrote:
Don Baccus wrote:
Well...personally I don't see LIMIT as being particularly harmful,
and it is a convenience. Remember, for the web space you're speaking
of keeping overhead low is a real concern, and requiring a series
of queries where currently only one needed will probably go over like
a lead ballon.I meant that the _backend_ could (in some distant future, when the
optimiser is perfect :) implement LIMIT as above sequence.
Oops! Sorry...at the moment I'm near to loathing the very existence
of LIMIT so misunderstood :)
- 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 Feb 14 20:10:55 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA15232
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 20:10:34 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id RAA12489;
Mon, 14 Feb 2000 17:09:53 -0800 (PST)
Message-Id: <3.0.1.32.20000214170708.00efeec0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 14 Feb 2000 17:07:08 -0800
To: Hannu Krosing <hannu@tm.ee>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Cc: Chris <chris@bitmead.com>, pgsql-hackers@postgreSQL.org
In-Reply-To: <38A8A349.7E543AAD@tm.ee>
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.>
<3.0.1.32.20000213205901.01706710@mail.pacifier.com>
<38A79295.BF844BE7@nimrod.itg.telecom.com.au>
<38A7CDE1.B3005B98@tm.ee>
<3.0.1.32.20000214070519.0170d150@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 02:52 AM 2/15/00 +0200, Hannu Krosing wrote:
Don Baccus wrote:
This is a FUNDAMENTAL concept in SQL, one that is mentioned in every
SQL book I've seen.The same person probably expects NULL = NULL to return true, too.
IIRC SQL3 defines different /classes/ of nulls where the above could be
true if the NULLs belong to the same class.
I.e. the absence of an orange is equal to the absence of the same orange,
but not equal to the absence of an apple (and possibly another orange) ;)
I may of course be completely wrong, as I did not read it too carefully
being after completely other things at that time.
My recent foray into the SQL3 draft with Jan in order to figure out
MATCH <unspecified> semantics makes me suspicious of anyone's claim to
understand what the standard says :)
Particularly the authors!
I'm carrying a length of rope and am keeping mindful of the nearest
lamp post just in case I run across one in the street by accident.
I also could not figue out the use for such a feature.
Well, I just looked at Date's summary of SQL3 and while he talks
about the new user datatype and mild object-oriented innovations,
he doesn't talk about any change in the meaning of NULL. Since
he makes no effort to hide his loathing for NULL or three-valued
logic as implemented in SQL, if it had changed I'm certain he
would've mentioned it.
- 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 Feb 14 20:11:55 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA15351
for <pgsql-hackers@postgresql.org>;
Mon, 14 Feb 2000 20:11: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 VAA63426
for <pgsql-hackers@postgresql.org>;
Mon, 14 Feb 2000 21:11:24 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 14 Feb 2000 21:11:23 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: pid_t define missing in include/miscadmin.h ...
Message-ID: <Pine.BSF.4.21.0002142106120.74045-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Okay, I may be missing something here, but:
gmake[2]: Entering directory `/usr/local/pgsql/src/pgsql/src/backend/parser'
gcc -I../../include -I../../backend -O2 -m486 -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I.. -Wno-error -c scansup.c -o scansup.o
In file included from scansup.c:20:
../../include/miscadmin.h:225: syntax error before `pid'
gmake[2]: *** [scansup.o] Error 1
Looking at include/miscadmin.h:
=========
extern int SetPidFile(pid_t pid);
#endif /* MISCADMIN_H */
=========
but I can't find anywhere that pid_t is defined, and the cvs logs don't
appear to indicate that anyone has touched that file in a few weeks ...
So, am I missing something? This is using CVS source as of today, on
FreeBSD 4.0-CURRENT ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Feb 14 20:20:54 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA16428
for <pgsql-hackers@postgresql.org>;
Mon, 14 Feb 2000 20:20:14 -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 VAA64106;
Mon, 14 Feb 2000 21:19:48 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 14 Feb 2000 21:19:48 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Lamar Owen <lamar.owen@wgcr.org>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Release on the 15th?
In-Reply-To: <23918.950568396@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0002142118590.74045-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 14 Feb 2000, Tom Lane wrote:
Lamar Owen <lamar.owen@wgcr.org> writes:
Are we still 'go' for a beta release the 15th?
Um ... I'm not ready ...
Couple more days, Marc?
Say Monday?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Feb 14 21:09:59 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 VAA20598
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 21:09:00 -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
VAA27870;
Mon, 14 Feb 2000 21:08:20 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002150208.VAA27870@candle.pha.pa.us>
Subject: Re: [HACKERS] pid_t define missing in include/miscadmin.h ...
In-Reply-To: <Pine.BSF.4.21.0002142106120.74045-100000@thelab.hub.org> from
The
Hermit Hacker at "Feb 14, 2000 09:11:23 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Mon, 14 Feb 2000 21:08:20 -0500 (EST)
CC: pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
pid_t is in /usr/include/sys/types.h. Maybe it is missing that include?
Okay, I may be missing something here, but:
gmake[2]: Entering directory `/usr/local/pgsql/src/pgsql/src/backend/parser'
gcc -I../../include -I../../backend -O2 -m486 -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I.. -Wno-error -c scansup.c -o scansup.o
In file included from scansup.c:20:
../../include/miscadmin.h:225: syntax error before `pid'
gmake[2]: *** [scansup.o] Error 1Looking at include/miscadmin.h:
=========
extern int SetPidFile(pid_t pid);#endif /* MISCADMIN_H */
=========but I can't find anywhere that pid_t is defined, and the cvs logs don't
appear to indicate that anyone has touched that file in a few weeks ...
So, am I missing something? This is using CVS source as of today, on
FreeBSD 4.0-CURRENT ...Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org************
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 14 21:11:55 2000
Received: from mta1-rme.xtra.co.nz (mta1-rme.xtra.co.nz [203.96.92.1])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA20768
for <pgsql-hackers@postgresql.org>;
Mon, 14 Feb 2000 21:11:09 -0500 (EST)
(envelope-from aubrey.quarcoo@esolutions.co.nz)
Received: from aubreyq ([203.96.95.110]) by mta1-rme.xtra.co.nz
(InterMail v4.01.01.00 201-229-111) with SMTP
id <20000215021909.QFHL6460852.mta1-rme@aubreyq>
for <pgsql-hackers@postgresql.org>; Tue, 15 Feb 2000 15:19:09 +1300
Message-ID: <000801bf7759$abd682a0$6e5f60cb@team.xtra.co.nz>
From: "aubrey" <aubrey.quarcoo@esolutions.co.nz>
To: <pgsql-hackers@postgresql.org>
Subject: subscribe
Date: Tue, 15 Feb 2000 15:09:20 +1300
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0005_01BF77C6.A28FB460"
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_0005_01BF77C6.A28FB460
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
subscribe
------=_NextPart_000_0005_01BF77C6.A28FB460
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>subscribe</FONT></DIV></BODY></HTML>
------=_NextPart_000_0005_01BF77C6.A28FB460--
From bouncefilter Mon Feb 14 21:27:56 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA22087
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 21:27: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 WAA68676;
Mon, 14 Feb 2000 22:26:42 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 14 Feb 2000 22:26:42 -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] pid_t define missing in include/miscadmin.h ...
In-Reply-To: <200002150208.VAA27870@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0002142222410.74045-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 14 Feb 2000, Bruce Momjian wrote:
pid_t is in /usr/include/sys/types.h. Maybe it is missing that include?
okay guys, I've had two answers so far that I would *really* have to be a
bad programmer not to have already checked :)
miscadmin.h doesn't include sys/types.h ... if I add sys/types.h to
miscadmin.h, it compiles fine ... the first place I looked was
/usr/include/sys/types.h for this ...
According to sources as of a couple of hours ago, sys/types.h isn't
included in anywhere I can think of off hand:
%ls
CVS config.h mb port storage
access config.h.in miscadmin.h postgres.h strdup.h
bootstrap dynloader.h nodes postgres_ext.h tcop
c.h executor optimizer regex utils
catalog lib os.h rewrite version.h
commands libpq parser rusagestub.h
version.h.in
%grep TYPE config.h
#define SOCKET_SIZE_TYPE size_t
%grep type.h *.h
%grep type.h */*.h
catalog/pg_type.h: * pg_type.h
catalog/pg_type.h: * $Id: pg_type.h,v 1.79 2000/01/26 05:57:59 momjian Exp
executor/spi.h:#include "catalog/pg_type.h"
parser/parse_coerce.h:#include "catalog/pg_type.h"
parser/parse_expr.h:#include "parser/parse_type.h"
parser/parse_type.h: * parse_type.h
parser/parse_type.h: * $Id: parse_type.h,v 1.12 2000/01/26 05:58:27
momjian Exp $
utils/acl.h: change the aclitem typlen in pg_type.h */
utils/inet.h: /* add IPV6 address type here */
And I've checked scansup.c itself, which includes <ctype.h>, but <ctype.h>
doesn't include <sys/types.h> either ... or does it on other ppls OSs?
Basically, where are other ppl getting <sys/types.h> included? :)
Okay, I may be missing something here, but:
gmake[2]: Entering directory `/usr/local/pgsql/src/pgsql/src/backend/parser'
gcc -I../../include -I../../backend -O2 -m486 -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I.. -Wno-error -c scansup.c -o scansup.o
In file included from scansup.c:20:
../../include/miscadmin.h:225: syntax error before `pid'
gmake[2]: *** [scansup.o] Error 1Looking at include/miscadmin.h:
=========
extern int SetPidFile(pid_t pid);#endif /* MISCADMIN_H */
=========but I can't find anywhere that pid_t is defined, and the cvs logs don't
appear to indicate that anyone has touched that file in a few weeks ...So, am I missing something? This is using CVS source as of today, on
FreeBSD 4.0-CURRENT ...Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org************
-- Bruce Momjian | http://www.op.net/~candle pgman@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 Feb 14 21:45:02 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA24445
for <pgsql-hackers@postgresql.org>;
Mon, 14 Feb 2000 21:44:53 -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 WAA73074;
Mon, 14 Feb 2000 22:44:49 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 14 Feb 2000 22:44:49 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Sevo Stille <sevo@ip23.net>
cc: pgsql-hackers@postgresql.org
Subject: Re: schema: pg_dump -s ipmeter (fwd)
In-Reply-To: <38A8AFBC.D7E6A528@ip23.net>
Message-ID: <Pine.BSF.4.21.0002142237000.74045-101000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-1190301042-950582689=:74045"
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.
--0-1190301042-950582689=:74045
Content-Type: TEXT/PLAIN; charset=US-ASCII
I'm CC'ng this to the -hackers list, as this may be something that should
be looked into more deeply, as ppl start looking at pg_dump'ng their
databases to upgrade to 7.0 ...
Included is a pg_dump from a 7.0 system that does work ... under my v6.5.3
system, doing the same thing dies at the \connect - ipmeter shown below
... the v6.5.3 system is what is running on postgresql.org/hub.org, which
is a FreeBSD 3.4-STABLE server ...
I'm going to try a build of v6.5.3 on my home machine and see if i can
recreate the seg fault ...
On Tue, 15 Feb 2000, Sevo Stille wrote:
The Hermit Hacker wrote:
Good question ... I'm getting:
pq_recvbuf: unexpected EOF on client connection
from the backend, which *sounds* like psql is crashing ...
gdb shows it dying:
(gdb) where
#0 0x4814d0bc in strcmp () from /usr/lib/libc.so.3
#1 0x804fb28 in becomeUser ()
#2 0x804f268 in dumpIndices ()
#3 0x80501fa in dumpSchemaIdx ()
#4 0x804a8c2 in main ()
#5 0x80494dd in _start ()Strange that it seems to trap the error and exit, though. Well, I'll
have a look at the source.I've just gotten v7.0 compiled and installed ...
Good. That ought to isolate the error a bit further.
Its definitely not a problem with v7.0 ... just got her all up and
running, as far as the database is concerned ...
-----------------------------
CREATE OPERATOR >>= (PROCEDURE = port_pinecmp ,
LEFTARG = port ,
RIGHTARG = int4 );
\connect - ipmeter
CREATE UNIQUE INDEX "users_name_key" on "users" using btree ( "name" "text_ops" );
CREATE UNIQUE INDEX "importerstatus_filename_key" on "importerstatus" using btree ( "filename" "text_ops" );
-----------------------------
from what I can tell, its at the \connect - ipmeter part that it dumps ...
--0-1190301042-950582689=:74045
Content-Type: APPLICATION/octet-stream; name="dump.gz"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.BSF.4.21.0002142244490.74045@thelab.hub.org>
Content-Description:
Content-Disposition: attachment; filename="dump.gz"
H4sICDS9qDgAA2R1bXAAxVptb9s2EP5c/wrCKGYbUJc6CdagaQu4jpoFc53U
sYcNKGAwEm0Lk0hFopJm2I8fX0VJphR7brUvrXk83vPc8XjiS756BGPkUfAK
xOv0PuyMZ+5o7oJPi+l4fnU9Bd2YJHQZ4C7okxjeZwgMwMydL2bTW8C7wOgW
9I6yNDkKiQfDI2HlKAzujiLiZyFKj7iWj1Y/p6QHJqPp5WJ06YLeuHdeg0Uy
agNTgsPh5n/euBKKwYAAU5RgGIYIr+kGvAdnDkDfKrJXQ4cpxhllv1U8HMB4
FiSs5YAUYb8kSJCHggdUHMa4wSzk43qveoPzzlczA0EcIYasid66XxbudMzI
Bn4XpBSyaJ8wHl6CIoQpGIIIfnuAIYvK8fD0zenZyS+nb0AUYCkbAuBBb8N/
nHdm7u/Xv7lgNJkAgqXBVUIicLP4OLkan3cuZ6PpvNRNCftfEuqa2I0+Thif
B5SkAeE50XlhGpTFzTECboRF95SLstiHFHGrQYSYJ1EMLtxPo8VkDnqYPPY6
gyrEKtwg6DNLEmQV8pFdwM3wX46QSXY58CpMU3QvUM9kG5XaOFpuYLrpAm8D
E+ixseABJk8BXvdPjgdyRJPGNksclVhyANE2nHbBTFjiDk2wpOC4KjgpOsoF
pyUU7enpNsuQrJcJfNSRJI98dIqo0D92lDDAPvpWAA2SlMqgi0mLIebiENqk
KckSD8UIJfQpRsaukUPfT1DK4uQFfsK7fJYH1g45hiYQp3mftscH2Xsoif0s
LdBn2V2WUEJY+GlayA+mU5RtRw76bDmpyRW/Tci9LKU6xfnAygrTIxtWmVZp
WmlxQijxSKg46GZh5rPojucbj4OFRmG8hcmtO3HH86piE58Ipn8pLncBLcSf
d9QGQ41qZqCUmtBTlDwEHlIEVMvEQtZ0/m91gpxS7GpiZaw3TJpRap42Q9Nj
SyY1JFP22UImB4VmF7BpROxX/8yRReGZ7NL2G4hqlSaaGNFHkugJrQZM9ZqV
yb5AwWplXCmUX1POhXDYMysZ80LDTRid10evexavDJ0Gv4xSk2es5OlyV1to
ZFe5nOjkYX1LS8Fg0mrRcGq/Ts8X/obyqDu36W1XqSw1XyAYFRcEy7xHv5B7
WYySJcuMhy64IyTUmUZY8i0ZSF2Xj8JKl0wFyxjVsT0Ceh7JMLUM0T3bY9Ri
s4zRPeUxlpxSsWlIKKXRlE06EIWFwpv2j0Ge5ph1sq1Yvxf4vbdvueoATK/n
YLqYTMQgEvF9nLRioV5AbaBf0GpywYdPy/9vUZS2a9sL4mxgrR8HLJBKKHPv
GwKZ6zSFUaa3yoNqPZTfnzwnynW/Wl0le05c5q6JwMpWG3PgBg9ynSYPgojT
ZPlCIc307jpgR51S5eCSNPgb7bSFZzv4/kCPgmtU+9mqYjcdQSqqTS4ldMX3
vxG01cAEiZOTKR0JCzo7c61qS0bBXAPBglaZ29dnj9Q8OkvC5r0vgiuKhjno
iub3PFULOIj9tvDEUdeL4iJeFVRk/HcHjSD1Nq3C8gTZ8GNTX+yCfnRU+Rmv
L8qxuHv50fEMaatw63bh+Da8Te/ahYvlCmwRELeOiNr3sX3IABVqaUuQJTdb
Kd1xy6Utbrm2xS0Xt7jl6hb/sPJWf0FuKKwRXWL0uOQb7L7tK5yikJtQRzLQ
7/FDWW9QxLr9MrF5x0zrI5awXvedVwh+wLb5mP2Q+325g8zPaOBxgxKUt8F7
8HJ4vh8JubvtVxalYFVHQ0DVEgn8fWiog/fdE86imqJUy0WNlVT0Rdo2EzCa
Xsi3JdY63puXiY9Tmav8vapKTHTswkp7sAcxce2Y09rOnuNSforbXEklv5FV
XHR7n9nS4PlcNUxTbt+Krpjtgc3vc++e5C1xXzhav2q4rsQVt8AKk4/dH1He
RFe9rUZa2N5CFDz2QMSIrkiyISkv7uKO0yCKpi3b1A2mRNfXmYoAy7N3795r
6S4sAhyw01Z+I2XxW0a6E2CWvZQLCFA3BUBRk01HXvQAcXHhcCqCodatrIjh
eclivnCUSdXWNl8OnUqC1a00ZhcUDecBUoa5JSVzFDdrJOuIyntxbU35Ki7l
HdlnPFeq2/bU4OE5ADvMkM+0KdppjqRqY9xZbpbU6itWWa8uPFU9u9Mvn/O6
7tbj+sadjebXM/AP6N/MrsfuxWLmMoPqDgQ4nRcT99N8NLtUQi6ZXV3+WhSZ
G+/c3E8WcxD7/9neu7I9dfwtmxOfibI5LRpff/68mAtLavBayKfuZUmIbNgf
LNjrQ7BDG3ZoxWbFxuI4OsRxZHOcWh23ga8PAQ9t4KEV3IaN7g/AloMr2Ng+
47Yp5yf2A+DF+ds6xbbcltoHoNWAfbDOqTipH+QbqnXOiocPBdwTL9jGsxQf
uVHeOWjBbl7oklZ/UFpMr74sXHA1vXD/UA9eS74hXf6FnrrFR7AsDfAa3NEE
IXaOUjfpXb5TXJKY9RvuZZPl2/qlfk8w9qvX+RUg8wBhBdMwKTeSdisP8RVb
8hVGXbLX2OHftWfM6PeaRkM4km+84mHa/C1QNYz6b4C6DzDhr1915qDnUfFc
Xn7orprT7/JdvsWssxWSdRBLS+JVqxrx7SfA58ylzfYsb3XPWZQPhPUmZX9X
P6vXWfILvuaveAf66xcdrje6r9N+yet6u3We/wsBxsZlsCkAAA==
--0-1190301042-950582689=:74045--
From bouncefilter Mon Feb 14 21:37: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 VAA23391
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 21:37:22 -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 CAA00793;
Tue, 15 Feb 2000 02:44:58 GMT
Sender: lockhart@hub.org
Message-ID: <38A8BDAA.A83C9ACD@alumni.caltech.edu>
Date: Tue, 15 Feb 2000 02:44:58 +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] Release on the 15th?
References: <38A87153.FDD9EE7@wgcr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Are we still 'go' for a beta release the 15th?
Before I pull a latenighter RPM building.....it would be nice to have an
idea. TIA!
Uh, it's never been a good idea to set your watch by our beta release
schedule. In fact, for purposes of RPM building, I'd suggest lagging
even up to a day or two to see if some immediate problems crop up and
are fixed.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Feb 14 21:46:56 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA24687
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 21:46: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 WAA73095;
Mon, 14 Feb 2000 22:46:26 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 14 Feb 2000 22:46:26 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Alfred Perlstein <bright@wintelcom.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pid_t define missing in include/miscadmin.h ...
In-Reply-To: <20000214185524.F17536@fw.wintelcom.net>
Message-ID: <Pine.BSF.4.21.0002142246050.74045-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 14 Feb 2000, Alfred Perlstein wrote:
* The Hermit Hacker <scrappy@hub.org> [000214 17:43] wrote:
Okay, I may be missing something here, but:
gmake[2]: Entering directory `/usr/local/pgsql/src/pgsql/src/backend/parser'
gcc -I../../include -I../../backend -O2 -m486 -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I.. -Wno-error -c scansup.c -o scansup.o
In file included from scansup.c:20:
../../include/miscadmin.h:225: syntax error before `pid'
gmake[2]: *** [scansup.o] Error 1Looking at include/miscadmin.h:
=========
extern int SetPidFile(pid_t pid);#endif /* MISCADMIN_H */
=========but I can't find anywhere that pid_t is defined, and the cvs logs don't
appear to indicate that anyone has touched that file in a few weeks ...So, am I missing something? This is using CVS source as of today, on
FreeBSD 4.0-CURRENT ...Someone forgot to include <sys/types.h>. I brought this up before but my
inexperiance with the postgresql build leaves me without a solution except
a simple #include directive in the offending file.
That's what I'm thinking too ... but *so far* its looking like its only
affecting the FreeBSDers :(
From bouncefilter Mon Feb 14 21:27:55 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA22098
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 21:27:38 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id SAA04382;
Mon, 14 Feb 2000 18:55:24 -0800 (PST)
Date: Mon, 14 Feb 2000 18:55:24 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: The Hermit Hacker <scrappy@hub.org>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pid_t define missing in include/miscadmin.h ...
Message-ID: <20000214185524.F17536@fw.wintelcom.net>
References: <Pine.BSF.4.21.0002142106120.74045-100000@thelab.hub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Pine.BSF.4.21.0002142106120.74045-100000@thelab.hub.org>;
from scrappy@hub.org on Mon, Feb 14, 2000 at 09:11:23PM -0400
* The Hermit Hacker <scrappy@hub.org> [000214 17:43] wrote:
Okay, I may be missing something here, but:
gmake[2]: Entering directory `/usr/local/pgsql/src/pgsql/src/backend/parser'
gcc -I../../include -I../../backend -O2 -m486 -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I.. -Wno-error -c scansup.c -o scansup.o
In file included from scansup.c:20:
../../include/miscadmin.h:225: syntax error before `pid'
gmake[2]: *** [scansup.o] Error 1Looking at include/miscadmin.h:
=========
extern int SetPidFile(pid_t pid);#endif /* MISCADMIN_H */
=========but I can't find anywhere that pid_t is defined, and the cvs logs don't
appear to indicate that anyone has touched that file in a few weeks ...So, am I missing something? This is using CVS source as of today, on
FreeBSD 4.0-CURRENT ...
Someone forgot to include <sys/types.h>. I brought this up before but my
inexperiance with the postgresql build leaves me without a solution except
a simple #include directive in the offending file.
-Alfred
From bouncefilter Mon Feb 14 22:17:02 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 WAA28827
for <hackers@postgresql.org>; Mon, 14 Feb 2000 22:16: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 DAA00853;
Tue, 15 Feb 2000 03:21:01 GMT
Sender: lockhart@hub.org
Message-ID: <38A8C61D.90557A4B@alumni.caltech.edu>
Date: Tue, 15 Feb 2000 03:21: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: Tom Lane <tgl@sss.pgh.pa.us>
CC: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [PATCHES] Re: [HACKERS] Almost there on column aliases
References: <38A3A7DB.6A684EF@alumni.caltech.edu>
<18707.950251267@sss.pgh.pa.us>
<38A3B745.E720A4AC@alumni.caltech.edu>
<18803.950253638@sss.pgh.pa.us>
<38A432D2.D6998E5B@alumni.caltech.edu>
<19051.950545044@sss.pgh.pa.us>
<38A8368B.68AF6CDA@alumni.caltech.edu>
<22598.950555491@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Right. I'm looking forward to advice on the right way to do this. The
problem is that the introductory character for list structures is
*also* the introductory character for plans, so everything blows
chunks if I just call nodeRead() from _readAttr().Huh? '{' introduces a node, '(' introduces a list. See the comments
I added (not very long ago :-() in read.c. My guess is that you are
either emitting the wrong character or have some sort of error in the
way you call nodeRead. Nothing obviously wrong in the patch diffs
though.
The problem I recall is that paren also introduces a "plan", and if
you call nodeRead() it sees the paren and then complains later because
it expects a node label following the paren.
I probably misdiagnosed the behavior, but in any case I'd be *really*
happy if someone wants to put me out of my misery on this one ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Feb 14 22:29:56 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id WAA30363
for <pgsql-hackers@postgreSQL.org>;
Mon, 14 Feb 2000 22:29:02 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
OAA09921; Tue, 15 Feb 2000 14:28:30 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0ax9wp;
Tue Feb 15 14:28:09 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
OAA21512; Tue, 15 Feb 2000 14:28:08 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdhGJIg_; Tue Feb 15 14:27:18 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA26819;
Tue, 15 Feb 2000 14:27:17 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
OAA03221; Tue, 15 Feb 2000 14:26:39 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A8C735.4E5A1280@nimrod.itg.telecom.com.au>
Date: Tue, 15 Feb 2000 14:25:41 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
CC: chris@bitmead.com,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
References: <38A89009.4DE7A872@nimrod.itg.telecom.com.au>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.>
<3.0.1.32.20000213205901.01706710@mail.pacifier.com>
<38A79295.BF844BE7@nimrod.itg.telecom.com.au>
<38A7CDE1.B3005B98@tm.ee>
<3.0.1.32.20000214070519.0170d150@mail.pacifier.com>
<3.0.1.32.20000214165448.01737ec0@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Don Baccus wrote:
At 10:30 AM 2/15/00 +1100, Chris Bitmead wrote:
It's a logical fact that the existance of "offset", automatically
implies
ordering, no matter how many SQL textbooks you quote.Chris, that is your opinion and judging from the responses of other
folks on this list, it appears to be very much a minority opinion.Minority of one, as a matter of fact. There has been a parade
of posts disagreeing with your opinion.
I've heard no-one say that offset is meaningful or in any sense
useful in the absense of order. If it means something please
enlighten us. If not, try reading before posting.
Why not give up and get on with your life before I get tired of
being polite? I'm *much* more stubborn than you are, particularly
when I'm right.
From bouncefilter Mon Feb 14 23:08:56 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 XAA35175
for <pgsql-hackers@postgresql.org>;
Mon, 14 Feb 2000 23:08:30 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id WAA52225
for pgsql-hackers@postgresql.org; Mon, 14 Feb 2000 22:55:46 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
Message-ID: <38A8CF51.671454BD@home.com>
From: Howard Williams <howieshouse@home.com>
Reply-To: howieshouse@home.com
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
X-Newsgroups: comp.databases.postgresql.hackers
Subject: tuple is too big
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 19
Date: Tue, 15 Feb 2000 03:55:37 GMT
X-Complaints-To: abuse@home.net
X-Trace: news1.alsv1.occa.home.com 950586937 24.9.129.252 (Mon,
14 Feb 2000 19:55:37 PST)
Organization: @Home Network
To: pgsql-hackers@postgresql.org
Hi
I'm trying to create a table that has only 8 fields or so. Two of the
fields have CHECK's that are essentally "LIKE 'this' OR LIKE 'that".
Apparently, these restrictions add something to the tuple size, which I
understand is set at 8192. How do I increase this limit? I read one
posting that says it can be adjusted at compile time, but that it may be
dangerous.
Maybe there's a better way. How would you suggest allowing only 'AL',
'AK', 'CA', etc. for a state field, for example? A c-function in a
shared library?
And where can I find the postgresql-hackers archive?
Thanks
Howie
From bouncefilter Mon Feb 14 22:51:59 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 WAA32682
for <hackers@postgresql.org>; Mon, 14 Feb 2000 22:51:35 -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 DAA00897
for <hackers@postgresql.org>; Tue, 15 Feb 2000 03:59:15 GMT
Sender: lockhart@hub.org
Message-ID: <38A8CF13.5344649F@alumni.caltech.edu>
Date: Tue, 15 Feb 2000 03:59: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: Postgres Hackers List <hackers@postgresql.org>
Subject: Great timing (not)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I've just committed the first cut at some "join syntax" improvements,
and some other stuff including error message fixes and a start at
POSIX time zones. I'll start working on the date/time reunification
now, and Jan's gram.y shift/reduce problems after that.
My mail server seems to be down, so I'm off the air at the moment. If
I'm missing something important, send mail to
Thomas.Lockhart@jpl.nasa.gov and I'll get it tomorrow...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Tue Feb 15 00:28:57 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA50713
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 00:28:18 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id VAA18466;
Mon, 14 Feb 2000 21:27:35 -0800 (PST)
Message-Id: <3.0.1.32.20000214210823.00f05ec0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 14 Feb 2000 21:08:23 -0800
To: chris@bitmead.com
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Cc: chris@bitmead.com,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
In-Reply-To: <38A8C735.4E5A1280@nimrod.itg.telecom.com.au>
References: <38A89009.4DE7A872@nimrod.itg.telecom.com.au>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.>
<3.0.1.32.20000213205901.01706710@mail.pacifier.com>
<38A79295.BF844BE7@nimrod.itg.telecom.com.au>
<38A7CDE1.B3005B98@tm.ee>
<3.0.1.32.20000214070519.0170d150@mail.pacifier.com>
<3.0.1.32.20000214165448.01737ec0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 02:25 PM 2/15/00 +1100, Chris Bitmead wrote:
I've heard no-one say that offset is meaningful or in any sense
useful in the absense of order. If it means something please
enlighten us. If not, try reading before posting.
Actually the "limit 1 offset 1" example for uniqueness DID actually
give a meaningful hack on the usefulness of lack of order.
The basic problem, Chris, is that you want to rape the optimizer
in order to stroke ...
well...I'll be nice for one more post.
But...I'm losing patience.
Hell...push me and I'll just start deleting your questions and answers
on photo.net. After all, you don't understand that weight isn't the only
parameter that contributes to the stability of tripod support..."I'm
leery of Gitzo carbon fiber tripods because I seek WEIGHT!". If you
seek weight, eat butter. If you seek stable tripods, seek carbon
fiber and give up this bullshit weight fanatacism.
You're pretty much a putz. I could go on and on, based only on photo.net
postings. Display ignorance in one forum, and why should one be
surprised to see ignorance in another? Sign me...glad to be a moderator
of photo.net. Wish I were here, too. Why do you go to so much bother
to demonstrate the fact that you don't know what the hell you're talking
about?
Here's a photo.net example:
"Do I have the right to photograph in non-public places?"
The very subject line displays your ignorance. OF COURSE YOU DON'T.
Not by default. By definition, a private owner of an enclosed space
like the museum in question owns that space. Your lack of respect for
that authority displays selfishness. You're similarly selfish in regard
to PG.
As long as rules on photography, etc, are uniformly stated and enforced, in
English-derived legal systems you don't have a limp d... to stand on.
"The other day I went to a special museum exhibit of ancient artifacts. I paid
about $AUD 20 to get in.
I pulled out my camera and started taking a few photos of stuff, whereupon
one of the attendants chastised me and said photography wasn't allowed. I
was not using flash"
Hmmm...not using flash. So what? The issue is whether or not you can
photograph.
"because I know sometimes items can be damaged by excess light."
Which, in the case of flash has been totally debunked, though some museums
still use it as an excuse to avoid arguing over whether or not a private
venue is subject to public property access laws. So not only are you
sadly misinformed about law, but you appear to be sadly misinformed about
the effect of electronic flash on art.
"On the way out, I enquired about why I couldn't photograph. They said it
was a condition of the owner of the artifacts and was probably because they
hold "copyright" on the items."
Oh my gosh, so the person buying these things who wants to let the public
view them therefore abrogates all right to any image taken by a visitor?
Just because Chris is a self-centered, selfish man? Theft is your RIGHT?
Gag me.
OK, an apology to the forum. Chris is a pain in the butt in the photo
forum I moderate, shows little common sense nor most particularly a sense
of community, is selfish and resents law when it suggests he can't do each
and every thing he might want to do in life.
I shouldn't bring this up but I'm pretty much tired of this discussion, and
he's tired me in the past in the photo forum I help moderate. I was nice
there, didn't spank him in public, and now feel like I'm suffering over
here for my lack of diligence.
(paraphrases follow)
"I should get to photograph these artifacts even if they're
owned by someone else and even if they're being shown in a private forum".
"You guys should make sure that the optimizer doesn't cause my BROKEN code
to not "work", even though it doesn't really work today"
"Let's change how inheritance etc. works in a way that fits my personal
prejudice, regardless of how the rest of the world might view the issue"
And, yes, I'm being petty and vindicative but since you're so insistent
on being a total *bleeping* idiot, why not? Give it up! NO ONE
agrees with you.
(I'm still being polite, want to push me?)
If you don't want SQL to be SQL, write your own query language and
build it on PG. Convince the world that you're right, and you'll
be a very rich man.
No one is stopping you. Distribute it as a rival copy. You can
even incorporate each and every enhancement and bug fix that comes
along.
Since you own the one and only better-mouse-trap-ideal, you'll kick
our ass and we'll fade into oblivion.
It's a given, right?
Oh, and while you're at it, finance your own museum and let me in
to shoot and sell images resulting from my visit to my heart's desire,
all for free...I'm holding my breath, man.
(for those of you who don't know it, I actually make part of my living
as a freelance photographer, with a wide range of national [US] credits.
Despite this, I would NEVER consider questioning a private museum's right
to control photograher access to its exhibits. Nor my home, for that
matter).
Chris, you're an exceedingly selfish man.
- 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 Feb 15 00:24:57 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 AAA50495
for <hackers@postgresql.org>; Tue, 15 Feb 2000 00:24:16 -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 FAA01274
for <hackers@postgresql.org>; Tue, 15 Feb 2000 05:31:57 GMT
Sender: lockhart@hub.org
Message-ID: <38A8E4CC.536C9040@alumni.caltech.edu>
Date: Tue, 15 Feb 2000 05:31:56 +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: README.qnx4 -> FAQ_QNX4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I've renamed the README for QNX4 to be consistant with the other
platform-specific FAQs. Let me know if that's a problem or if I've
done the wrong thing for this case...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Tue Feb 15 00:55:58 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA52550
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 00:55:47 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
QAA21021 for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 16:55:05 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd7UAJo_;
Tue Feb 15 16:54:44 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
QAA09862 for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 16:54:43 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0sNNFE; Tue Feb 15 16:54:04 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id QAA10902
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 16:53:59 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
QAA06452 for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 16:53:19 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A8E996.73512383@nimrod.itg.telecom.com.au>
Date: Tue, 15 Feb 2000 16:52:22 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
References: <38A89009.4DE7A872@nimrod.itg.telecom.com.au>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
<38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au> <5516.950461980@sss.>
<3.0.1.32.20000213205901.01706710@mail.pacifier.com>
<38A79295.BF844BE7@nimrod.itg.telecom.com.au>
<38A7CDE1.B3005B98@tm.ee>
<3.0.1.32.20000214070519.0170d150@mail.pacifier.com>
<3.0.1.32.20000214165448.01737ec0@mail.pacifier.com>
<3.0.1.32.20000214210823.00f05ec0@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Don, you are one fucking son of a bitch to bring up things I've said
on photo.net here on this forum. Sure I've said some pretty dumb things
in the past, who hasn't. But for you to bring this thing up from years
ago into a completely different forum... Well you're petulent child.
Don't bother commenting on anything I write, or communicating with me
again, because I won't read it.
Don Baccus wrote:
At 02:25 PM 2/15/00 +1100, Chris Bitmead wrote:
I've heard no-one say that offset is meaningful or in any sense
useful in the absense of order. If it means something please
enlighten us. If not, try reading before posting.Actually the "limit 1 offset 1" example for uniqueness DID actually
give a meaningful hack on the usefulness of lack of order.The basic problem, Chris, is that you want to rape the optimizer
in order to stroke ...well...I'll be nice for one more post.
But...I'm losing patience.
Hell...push me and I'll just start deleting your questions and answers
on photo.net. After all, you don't understand that weight isn't the only
parameter that contributes to the stability of tripod support..."I'm
leery of Gitzo carbon fiber tripods because I seek WEIGHT!". If you
seek weight, eat butter. If you seek stable tripods, seek carbon
fiber and give up this bullshit weight fanatacism.You're pretty much a putz. I could go on and on, based only on photo.net
postings. Display ignorance in one forum, and why should one be
surprised to see ignorance in another? Sign me...glad to be a moderator
of photo.net. Wish I were here, too. Why do you go to so much bother
to demonstrate the fact that you don't know what the hell you're talking
about?Here's a photo.net example:
"Do I have the right to photograph in non-public places?"
The very subject line displays your ignorance. OF COURSE YOU DON'T.
Not by default. By definition, a private owner of an enclosed space
like the museum in question owns that space. Your lack of respect for
that authority displays selfishness. You're similarly selfish in regard
to PG.As long as rules on photography, etc, are uniformly stated and enforced, in
English-derived legal systems you don't have a limp d... to stand on."The other day I went to a special museum exhibit of ancient artifacts. I paid
about $AUD 20 to get in.I pulled out my camera and started taking a few photos of stuff, whereupon
one of the attendants chastised me and said photography wasn't allowed. I
was not using flash"Hmmm...not using flash. So what? The issue is whether or not you can
photograph."because I know sometimes items can be damaged by excess light."
Which, in the case of flash has been totally debunked, though some museums
still use it as an excuse to avoid arguing over whether or not a private
venue is subject to public property access laws. So not only are you
sadly misinformed about law, but you appear to be sadly misinformed about
the effect of electronic flash on art."On the way out, I enquired about why I couldn't photograph. They said it
was a condition of the owner of the artifacts and was probably because they
hold "copyright" on the items."Oh my gosh, so the person buying these things who wants to let the public
view them therefore abrogates all right to any image taken by a visitor?Just because Chris is a self-centered, selfish man? Theft is your RIGHT?
Gag me.
OK, an apology to the forum. Chris is a pain in the butt in the photo
forum I moderate, shows little common sense nor most particularly a sense
of community, is selfish and resents law when it suggests he can't do each
and every thing he might want to do in life.I shouldn't bring this up but I'm pretty much tired of this discussion, and
he's tired me in the past in the photo forum I help moderate. I was nice
there, didn't spank him in public, and now feel like I'm suffering over
here for my lack of diligence.(paraphrases follow)
"I should get to photograph these artifacts even if they're
owned by someone else and even if they're being shown in a private forum"."You guys should make sure that the optimizer doesn't cause my BROKEN code
to not "work", even though it doesn't really work today""Let's change how inheritance etc. works in a way that fits my personal
prejudice, regardless of how the rest of the world might view the issue"And, yes, I'm being petty and vindicative but since you're so insistent
on being a total *bleeping* idiot, why not? Give it up! NO ONE
agrees with you.(I'm still being polite, want to push me?)
If you don't want SQL to be SQL, write your own query language and
build it on PG. Convince the world that you're right, and you'll
be a very rich man.No one is stopping you. Distribute it as a rival copy. You can
even incorporate each and every enhancement and bug fix that comes
along.Since you own the one and only better-mouse-trap-ideal, you'll kick
our ass and we'll fade into oblivion.It's a given, right?
Oh, and while you're at it, finance your own museum and let me in
to shoot and sell images resulting from my visit to my heart's desire,
all for free...I'm holding my breath, man.(for those of you who don't know it, I actually make part of my living
as a freelance photographer, with a wide range of national [US] credits.
Despite this, I would NEVER consider questioning a private museum's right
to control photograher access to its exhibits. Nor my home, for that
matter).Chris, you're an exceedingly selfish man.
- 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 Feb 15 01:05:58 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 BAA57738
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 01:05: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
BAA17983;
Tue, 15 Feb 2000 01:04:47 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002150604.BAA17983@candle.pha.pa.us>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
In-Reply-To: <38A8E996.73512383@nimrod.itg.telecom.com.au> from Chris Bitmead
at "Feb 15, 2000 04:52:22 pm"
To: chris@bitmead.com
Date: Tue, 15 Feb 2000 01:04:47 -0500 (EST)
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Folks, this type of behavour is being taken care of in a private manner.
It is being addressed.
---------------------------------------------------------------------------
Don, you are one fucking son of a bitch to bring up things I've said
on photo.net here on this forum. Sure I've said some pretty dumb things
in the past, who hasn't. But for you to bring this thing up from years
ago into a completely different forum... Well you're petulent child.
Don't bother commenting on anything I write, or communicating with me
again, because I won't read it.Don Baccus wrote:
At 02:25 PM 2/15/00 +1100, Chris Bitmead wrote:
I've heard no-one say that offset is meaningful or in any sense
useful in the absense of order. If it means something please
enlighten us. If not, try reading before posting.Actually the "limit 1 offset 1" example for uniqueness DID actually
give a meaningful hack on the usefulness of lack of order.The basic problem, Chris, is that you want to rape the optimizer
in order to stroke ...well...I'll be nice for one more post.
But...I'm losing patience.
Hell...push me and I'll just start deleting your questions and answers
on photo.net. After all, you don't understand that weight isn't the only
parameter that contributes to the stability of tripod support..."I'm
leery of Gitzo carbon fiber tripods because I seek WEIGHT!". If you
seek weight, eat butter. If you seek stable tripods, seek carbon
fiber and give up this bullshit weight fanatacism.You're pretty much a putz. I could go on and on, based only on photo.net
postings. Display ignorance in one forum, and why should one be
surprised to see ignorance in another? Sign me...glad to be a moderator
of photo.net. Wish I were here, too. Why do you go to so much bother
to demonstrate the fact that you don't know what the hell you're talking
about?Here's a photo.net example:
"Do I have the right to photograph in non-public places?"
The very subject line displays your ignorance. OF COURSE YOU DON'T.
Not by default. By definition, a private owner of an enclosed space
like the museum in question owns that space. Your lack of respect for
that authority displays selfishness. You're similarly selfish in regard
to PG.As long as rules on photography, etc, are uniformly stated and enforced, in
English-derived legal systems you don't have a limp d... to stand on."The other day I went to a special museum exhibit of ancient artifacts. I paid
about $AUD 20 to get in.I pulled out my camera and started taking a few photos of stuff, whereupon
one of the attendants chastised me and said photography wasn't allowed. I
was not using flash"Hmmm...not using flash. So what? The issue is whether or not you can
photograph."because I know sometimes items can be damaged by excess light."
Which, in the case of flash has been totally debunked, though some museums
still use it as an excuse to avoid arguing over whether or not a private
venue is subject to public property access laws. So not only are you
sadly misinformed about law, but you appear to be sadly misinformed about
the effect of electronic flash on art."On the way out, I enquired about why I couldn't photograph. They said it
was a condition of the owner of the artifacts and was probably because they
hold "copyright" on the items."Oh my gosh, so the person buying these things who wants to let the public
view them therefore abrogates all right to any image taken by a visitor?Just because Chris is a self-centered, selfish man? Theft is your RIGHT?
Gag me.
OK, an apology to the forum. Chris is a pain in the butt in the photo
forum I moderate, shows little common sense nor most particularly a sense
of community, is selfish and resents law when it suggests he can't do each
and every thing he might want to do in life.I shouldn't bring this up but I'm pretty much tired of this discussion, and
he's tired me in the past in the photo forum I help moderate. I was nice
there, didn't spank him in public, and now feel like I'm suffering over
here for my lack of diligence.(paraphrases follow)
"I should get to photograph these artifacts even if they're
owned by someone else and even if they're being shown in a private forum"."You guys should make sure that the optimizer doesn't cause my BROKEN code
to not "work", even though it doesn't really work today""Let's change how inheritance etc. works in a way that fits my personal
prejudice, regardless of how the rest of the world might view the issue"And, yes, I'm being petty and vindicative but since you're so insistent
on being a total *bleeping* idiot, why not? Give it up! NO ONE
agrees with you.(I'm still being polite, want to push me?)
If you don't want SQL to be SQL, write your own query language and
build it on PG. Convince the world that you're right, and you'll
be a very rich man.No one is stopping you. Distribute it as a rival copy. You can
even incorporate each and every enhancement and bug fix that comes
along.Since you own the one and only better-mouse-trap-ideal, you'll kick
our ass and we'll fade into oblivion.It's a given, right?
Oh, and while you're at it, finance your own museum and let me in
to shoot and sell images resulting from my visit to my heart's desire,
all for free...I'm holding my breath, man.(for those of you who don't know it, I actually make part of my living
as a freelance photographer, with a wide range of national [US] credits.
Despite this, I would NEVER consider questioning a private museum's right
to control photograher access to its exhibits. Nor my home, for that
matter).Chris, you're an exceedingly selfish man.
- 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.************
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 15 01:11:59 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id BAA58422
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 01:11:42 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
RAA03588 for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 17:11:10 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd03mdAi;
Tue Feb 15 17:10:55 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
RAA29004 for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 17:10:54 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0uVZB5; Tue Feb 15 17:10:14 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id RAA24464
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 17:10:14 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
RAA06961 for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 17:09:34 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38A8ED64.864091AC@nimrod.itg.telecom.com.au>
Date: Tue, 15 Feb 2000 17:08:36 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
References: <200002150604.BAA17983@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Folks, this type of behavour is being taken care of in a private manner.
It is being addressed.
Apologies guys. I'm afraid I lost my cool. Sorry.
From bouncefilter Tue Feb 15 01:31:58 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 BAA61955
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 01:31:19 -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 BAA02157;
Tue, 15 Feb 2000 01:30:55 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: pgsql-hackers@postgreSQL.org, "Philip Warner" <pjw@rhyme.com.au>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
In-reply-to: <000301bf774f$feb8aa20$2801007e@tpf.co.jp>
References: <000301bf774f$feb8aa20$2801007e@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Tue, 15 Feb 2000 10:00:04 +0900"
Date: Tue, 15 Feb 2000 01:30:54 -0500
Message-ID: <2154.950596254@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
That's my feeling too. I'm leaning towards letting the optimizer do the
best it can with the given query (which means using OFFSET+LIMIT as the
estimated number of tuples to be fetched),
What about cursors ?
I heard from Jan that we could specify 'LIMIT ALL' to tell optimizer that
the response to get first rows is needed.
Hmm. Right now I have it coded to treat 'LIMIT ALL' the same as
no LIMIT clause, which is the way it ought to work AFAICS.
DECLARE CURSOR doesn't appear to support OFFSET/LIMIT at all (the
grammar will take the clause, but analyze.c throws it away...).
I have the LIMIT support in the planner coded to build plans for
DECLARE CURSOR queries on the assumption that 10% of the rows will
be fetched, which is the sort of compromise that will satisfy
nobody ;-).
A possible answer is to define OFFSET/LIMIT in DECLARE CURSOR as
being simply a hint to the optimizer about how much of the query
result will actually get fetched. I think we could do that by
tweaking analyze.c to pass through the clauses the same as it does
for regular select, and have the planner discard the clauses after
it's done using them. (We don't want them to get to the executor
and interfere with the actual behavior of FETCH commands, but I
don't see a reason why they can't live to reach the planner...)
Comments anyone?
regards, tom lane
From bouncefilter Tue Feb 15 01:33:58 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 BAA62105
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 01:33:04 -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 BAA02182;
Tue, 15 Feb 2000 01:33:02 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Release on the 15th?
In-reply-to: <Pine.BSF.4.21.0002142118590.74045-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0002142118590.74045-100000@thelab.hub.org>
Comments: In-reply-to The Hermit Hacker <scrappy@hub.org>
message dated "Mon, 14 Feb 2000 21:19:48 -0400"
Date: Tue, 15 Feb 2000 01:33:01 -0500
Message-ID: <2179.950596381@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
Couple more days, Marc?
Say Monday?
I think I can do Monday, but I don't know where Thomas is. Doesn't
he still want to squeeze in the date/time type consolidation?
regards, tom lane
From bouncefilter Tue Feb 15 03:01:00 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 DAA69054
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 03:00:15 -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 RAA01638; Tue, 15 Feb 2000 17:00:08 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Solution for LIMIT cost estimation
Date: Tue, 15 Feb 2000 17:06:15 +0900
Message-ID: <000601bf778b$88475940$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: <2154.950596254@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
That's my feeling too. I'm leaning towards letting the
optimizer do the
best it can with the given query (which means using OFFSET+LIMIT as the
estimated number of tuples to be fetched),What about cursors ?
I heard from Jan that we could specify 'LIMIT ALL' to telloptimizer that
the response to get first rows is needed.
Hmm. Right now I have it coded to treat 'LIMIT ALL' the same as
no LIMIT clause, which is the way it ought to work AFAICS.DECLARE CURSOR doesn't appear to support OFFSET/LIMIT at all (the
grammar will take the clause, but analyze.c throws it away...).I have the LIMIT support in the planner coded to build plans for
DECLARE CURSOR queries on the assumption that 10% of the rows will
be fetched, which is the sort of compromise that will satisfy
nobody ;-).
Probably your change would work well in most cases.
It's nice.
However it seems more preferable to be able to select first/all rows hint.
A possible answer is to define OFFSET/LIMIT in DECLARE CURSOR as
being simply a hint to the optimizer about how much of the query
result will actually get fetched. I think we could do that by
tweaking analyze.c to pass through the clauses the same as it does
for regular select, and have the planner discard the clauses after
it's done using them. (We don't want them to get to the executor
and interfere with the actual behavior of FETCH commands, but I
don't see a reason why they can't live to reach the planner...)Comments anyone?
The following was the reply from Jan 16 months ago.
Unfortunately PostgreSQL optimizer wasn't able to choose index scan
for queires with no qualification at that time.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
Re: [HACKERS] What about LIMIT in SELECT ? [1998/10/19]
Hiroshi Inoue wrote:
When using cursors,in most cases the response to get first(next) rows
is necessary for me,not the throughput.
How can we tell PostgreSQL optimzer that the response is necessary ?
With my LIMIT patch, the offset and the row count are part of
the querytree. And if a LIMIT is given, the limitCount elemet
of the querytree (a Node *) isn't NULL what it is by default.
When a LIMIT is given, the optimizer could assume that first
rows is wanted (even if the limit is ALL maybe - but I have
to think about this some more). And this assumption might let
it decide to use an index to resolve an ORDER BY even if no
qualification was given.
Telling the optimizer that first rows wanted in a cursor
operation would read
DECLARE CURSOR c FOR SELECT * FROM mytab ORDER BY a LIMIT ALL;
Jan
From bouncefilter Tue Feb 15 03:07:59 2000
Received: from acheron.rime.com.au (root@albatr.lnk.telstra.net
[139.130.54.222]) by hub.org (8.9.3/8.9.3) with ESMTP id DAA73667
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 03:07:49 -0500 (EST)
(envelope-from pjw@rhyme.com.au)
Received: from oberon (Oberon.rime.com.au [203.8.195.100])
by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id TAA06197;
Tue, 15 Feb 2000 19:07:05 +1100
Message-Id: <3.0.5.32.20000215190809.034d1b10@mail.rhyme.com.au>
X-Sender: pjw@mail.rhyme.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 15 Feb 2000 19:08:09 +1100
To: Tom Lane <tgl@sss.pgh.pa.us>, "Hiroshi Inoue" <Inoue@tpf.co.jp>
From: Philip Warner <pjw@rhyme.com.au>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <2154.950596254@sss.pgh.pa.us>
References: <000301bf774f$feb8aa20$2801007e@tpf.co.jp>
<000301bf774f$feb8aa20$2801007e@tpf.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 01:30 15/02/00 -0500, Tom Lane wrote:
What about cursors ?
I heard from Jan that we could specify 'LIMIT ALL' to tell optimizer that
the response to get first rows is needed.Hmm. Right now I have it coded to treat 'LIMIT ALL' the same as
no LIMIT clause, which is the way it ought to work AFAICS.DECLARE CURSOR doesn't appear to support OFFSET/LIMIT at all (the
grammar will take the clause, but analyze.c throws it away...).I have the LIMIT support in the planner coded to build plans for
DECLARE CURSOR queries on the assumption that 10% of the rows will
be fetched, which is the sort of compromise that will satisfy
nobody ;-).A possible answer is to define OFFSET/LIMIT in DECLARE CURSOR as
being simply a hint to the optimizer about how much of the query
result will actually get fetched.
This seems a good approach until cursors are fixed. But is there a plan to
make cursors support LIMIT properly? Do you know why they ignore the LIMIT
clause?
Or am I missing something?
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
From bouncefilter Tue Feb 15 03:33:59 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 DAA76338
for <hackers@postgreSQL.org>; Tue, 15 Feb 2000 03:33: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 DAA11113;
Tue, 15 Feb 2000 03:33:08 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Almost there on column aliases
In-reply-to: <38A8C61D.90557A4B@alumni.caltech.edu>
References: <38A3A7DB.6A684EF@alumni.caltech.edu>
<18707.950251267@sss.pgh.pa.us>
<38A3B745.E720A4AC@alumni.caltech.edu>
<18803.950253638@sss.pgh.pa.us>
<38A432D2.D6998E5B@alumni.caltech.edu>
<19051.950545044@sss.pgh.pa.us>
<38A8368B.68AF6CDA@alumni.caltech.edu>
<22598.950555491@sss.pgh.pa.us>
<38A8C61D.90557A4B@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Tue, 15 Feb 2000 03:21:01 +0000"
Date: Tue, 15 Feb 2000 03:33:07 -0500
Message-ID: <11110.950603587@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
I probably misdiagnosed the behavior, but in any case I'd be *really*
happy if someone wants to put me out of my misery on this one ;)
At least some of your problems are due to confusing list nodes with the
nodes they point to, as in this example from parse_clause.c:
List *
ListTableAsAttrs(ParseState *pstate, char *table);
List *
ListTableAsAttrs(ParseState *pstate, char *table)
{
List *rlist = NULL;
List *col;
Attr *attr = expandTable(pstate, table, TRUE);
foreach(col, attr->attrs)
{
Attr *a;
a = makeAttr(table, strVal((Value *) col));
rlist = lappend(rlist, a);
}
return rlist;
}
I tried, but failed, to refrain from remarking about the horrible
style of the function declaration --- either it's static (which
looks like the right answer here) or it should be declared in
a header file. The above method of preventing gcc from telling
you how horrible your style is is just, well, never mind.
The more immediate problem is that you want
a = makeAttr(table, strVal((Value *) lfirst(col)));
I cleaned up a similar error in ruleutils.c, but am too tired to
fix this one or go digging for more.
regards, tom lane
From bouncefilter Tue Feb 15 08:40:03 2000
Received: from corvette.mascari.com (dhcp26136108.columbus.rr.com
[24.26.136.108]) by hub.org (8.9.3/8.9.3) with ESMTP id IAA05043;
Tue, 15 Feb 2000 08:39:27 -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 IAA04403;
Tue, 15 Feb 2000 08:37:51 -0500
Sender: mascarm@corvette.mascari.com
Message-ID: <38A91019.59932F48@mascari.com>
Date: Tue, 15 Feb 2000 03:36:41 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] function defined in libpq?
References: <Pine.GSO.4.02A.10002151312230.28210-100000@Krokodil.DoCS.UU.SE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Peter Eisentraut wrote:
On Mon, 14 Feb 2000, Michael Meskes wrote:
Could anyone please give me an example on how I can define a function using
libpq if that is at all possible?Huh? I'm sure you don't mean adding a declaration to a header file and
putting the definition in a .c file of your choice, as well as ensuring
that it compiles?--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
I think what he wants to do is dynamically create a function from the client
side by issuing a CREATE FUNCTION statement (presumably one of the built-ins?
SQL, pl/pgSQL, pl/pgTcl.) For what its worth, I've issued a host of unlreated
DDL statements through PQexec and all of them have worked as expected, although
CREATE FUNCTION was never one of them...
Mike Mascari
From bouncefilter Tue Feb 15 08:45:05 2000
Received: from corvette.mascari.com (dhcp26136108.columbus.rr.com
[24.26.136.108]) by hub.org (8.9.3/8.9.3) with ESMTP id IAA05738;
Tue, 15 Feb 2000 08:44:52 -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 IAA04427;
Tue, 15 Feb 2000 08:43:43 -0500
Sender: mascarm@corvette.mascari.com
Message-ID: <38A91179.AB924F0A@mascari.com>
Date: Tue, 15 Feb 2000 03:42:33 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Meskes <meskes@postgreSQL.org>
CC: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] function question yet again
References: <20000215131439.A2553@fam-meskes.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Michael Meskes wrote:
Is it possible to define a function in language 'C' that needs more
libraries to work? I've got a small example of a function that works like a
charm when run against from a binary. However if I put this function inside
the server and execute it I getERROR: parser: parse error at or near ""
Not exactly an error message that explains itself. :-)
I have put my function into a shared library to load it, but the library
itself needs other libraries. Is this at all possible?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!
That's odd. Would it be possible for you to provide your compiliation/link
statement as well as your CREATE FUNCTION statement? I've a host of functions
which use external libaries that work as expected (on Linux), including doing
some pretty weird stuff.
Mike Mascari
From bouncefilter Tue Feb 15 08:49:03 2000
Received: from corvette.mascari.com (dhcp26136108.columbus.rr.com
[24.26.136.108]) by hub.org (8.9.3/8.9.3) with ESMTP id IAA06350;
Tue, 15 Feb 2000 08:48:08 -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 IAA04436;
Tue, 15 Feb 2000 08:46:55 -0500
Sender: mascarm@corvette.mascari.com
Message-ID: <38A91238.1258AB43@mascari.com>
Date: Tue, 15 Feb 2000 03:45:44 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] function defined in libpq?
References: <Pine.GSO.4.02A.10002151442070.28210-100000@Krokodil.DoCS.UU.SE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Peter Eisentraut wrote:
On Tue, 15 Feb 2000, Mike Mascari wrote:
On Mon, 14 Feb 2000, Michael Meskes wrote:
Could anyone please give me an example on how I can define a function using
libpq if that is at all possible?I think what he wants to do is dynamically create a function from the client
side by issuing a CREATE FUNCTION statement (presumably one of the built-ins?
SQL, pl/pgSQL, pl/pgTcl.) For what its worth, I've issued a host of unlreated
DDL statements through PQexec and all of them have worked as expected, although
CREATE FUNCTION was never one of them...Why wouldn't it work? Or, much more interesting, how else would you do it?
Yes. Sorry. Stupid answer on my part. psql is so nice, particularly the new one :-),
that I keep forgetting it is dependent entirely upon libpq....
Mike Mascari
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Feb 15 04:04:01 2000
Received: from gwineta.repas.de (gwineta.repas.de [193.101.49.1])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA78786
for <hackers@postgresql.org>; Tue, 15 Feb 2000 04:03:10 -0500 (EST)
(envelope-from kardos@repas-aeg.de)
Received: (from smap@localhost) by gwineta.repas.de (8.8.8/8.8.8) id KAA04187
for <hackers@postgresql.org>; Tue, 15 Feb 2000 10:03:09 +0100
Received: from dragon.dr.repas.de(172.30.48.206) by gwineta.repas.de via smap
(V2.1) id xma004182; Tue, 15 Feb 00 10:02:54 +0100
Received: from kardos.dr.repas.de ([172.30.48.153])
by dragon.dr.repas.de (UCX V4.2-21C, OpenVMS V6.2 Alpha);
Tue, 15 Feb 2000 10:03:19 +0200
Message-ID: <00f401bf7793$7256c410$99301eac@Dr.repas.de>
From: "Kardos, Dr. Andreas" <kardos@repas-aeg.de>
To: "Thomas Lockhart" <lockhart@alumni.caltech.edu>
Cc: "Postgres Hackers List" <hackers@postgresql.org>
References: <38A8E4CC.536C9040@alumni.caltech.edu>
Subject: Re: [HACKERS] README.qnx4 -> FAQ_QNX4
Date: Tue, 15 Feb 2000 10:02:52 +0100
Organization: repas AEG Automation GmbH
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.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
I named it README.qnx4 because it is a more README like document than FAQ.
There are no questions and answers in it. BTW there is README.NT too.
But nevertheless feel free to name it as you like.
Andreas Kardos
I've renamed the README for QNX4 to be consistant with the other
platform-specific FAQs. Let me know if that's a problem or if I've
done the wrong thing for this case...- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California************
From bouncefilter Tue Feb 15 07:16:02 2000
Received: from feivel.fam-meskes.de (p3E9B98F7.dip0.t-ipconnect.de
[62.155.152.247]) by hub.org (8.9.3/8.9.3) with ESMTP id HAA94359
for <pgsql-hackers@postgresql.org>;
Tue, 15 Feb 2000 07:15:51 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 33A702BC8F; Tue, 15 Feb 2000 10:53:34 +0100 (CET)
Date: Tue, 15 Feb 2000 10:53:34 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: parser changes
Message-ID: <20000215105334.A869@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
Sender: michael@fam-meskes.de
We have to make sure this time all parser changes make it into ecpg's parser
as well. Not like 6.5.3 where the backend accepted queries that ecpg didn't.
Right now I'm very busy though, so please bear with me if I need a little
more time.
I will try to keep as much up-to-date as possible.
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 Tue Feb 15 06:05:02 2000
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA88286
for <hackers@postgreSQL.org>; Tue, 15 Feb 2000 06:04:50 -0500 (EST)
(envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.3/8.9.3) with SMTP id OAA17447
for <hackers@postgreSQL.org>; Tue, 15 Feb 2000 14:04:11 +0300 (GMT)
Date: Tue, 15 Feb 2000 14:04:11 +0300 (GMT)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: hackers@postgreSQL.org
Subject: ERROR: copyObject: don't know how to copy 1381319466
Message-ID: <Pine.GSO.3.96.SK.1000215140237.16880A-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi,
just tried latest CVS and got the problem after
compiling,installing.
zen:~$ psql -l
ERROR: copyObject: don't know how to copy 1381319466
Do I need initdb ? postamster started normally
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
From bouncefilter Tue Feb 15 07:12:02 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA93705
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 07:11:36 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Krokodil.DoCS.UU.SE (e99re41@Krokodil.DoCS.UU.SE
[130.238.9.184])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id NAA00051;
Tue, 15 Feb 2000 13:11:31 +0100 (MET)
Received: from localhost (e99re41@localhost) by Krokodil.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id NAA28241;
Tue, 15 Feb 2000 13:11:29 +0100
X-Authentication-Warning: Krokodil.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 15 Feb 2000 13:11:28 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pgsql-support 'distribution' ...
In-Reply-To: <Pine.BSF.4.21.0002140011320.74045-100000@thelab.hub.org>
Message-ID: <Pine.GSO.4.02A.10002151307390.28210-100000@Krokodil.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 14 Feb 2000, The Hermit Hacker wrote:
The idea is that there are alot of sites out there that don't need
the whole backend sources, they only need the bin/interfaces stuff, so why
download a 7+meg file. Its also giving me a chance to play with
libtool/automake :)
There are no 'template' files, or 'Makefile.port' files or
anything like that ...
Hey Marc,
I've had automake/libtool on my list of things to bring up for 7.1. If
you're already getting a head start, I better take a look at it. If you
can report good things from it, and no one else around here has any
fundamental opposition to the concept, what do you think about us making a
push for this once the new devel cycle starts?
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Feb 15 07:14:02 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA93951;
Tue, 15 Feb 2000 07:13:22 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Krokodil.DoCS.UU.SE (e99re41@Krokodil.DoCS.UU.SE
[130.238.9.184])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id NAA00156;
Tue, 15 Feb 2000 13:13:17 +0100 (MET)
Received: from localhost (e99re41@localhost) by Krokodil.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id NAA28245;
Tue, 15 Feb 2000 13:13:16 +0100
X-Authentication-Warning: Krokodil.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 15 Feb 2000 13:13:15 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Michael Meskes <meskes@postgreSQL.org>
cc: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] function defined in libpq?
In-Reply-To: <20000214105416.A9298@fam-meskes.de>
Message-ID: <Pine.GSO.4.02A.10002151312230.28210-100000@Krokodil.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 14 Feb 2000, Michael Meskes wrote:
Could anyone please give me an example on how I can define a function using
libpq if that is at all possible?
Huh? I'm sure you don't mean adding a declaration to a header file and
putting the definition in a .c file of your choice, as well as ensuring
that it compiles?
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Feb 15 07:16:03 2000
Received: from feivel.fam-meskes.de (p3E9B98F7.dip0.t-ipconnect.de
[62.155.152.247]) by hub.org (8.9.3/8.9.3) with ESMTP id HAA94357
for <pgsql-hackers@postgresql.org>;
Tue, 15 Feb 2000 07:15:51 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id B379B2BC91; Tue, 15 Feb 2000 13:14:39 +0100 (CET)
Date: Tue, 15 Feb 2000 13:14:39 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: function question yet again
Message-ID: <20000215131439.A2553@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
Sender: michael@fam-meskes.de
Is it possible to define a function in language 'C' that needs more
libraries to work? I've got a small example of a function that works like a
charm when run against from a binary. However if I put this function inside
the server and execute it I get
ERROR: parser: parse error at or near ""
Not exactly an error message that explains itself. :-)
I have put my function into a shared library to load it, but the library
itself needs other libraries. Is this at all possible?
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 Tue Feb 15 09:05:03 2000
Received: from feivel.fam-meskes.de (p3E9B983A.dip0.t-ipconnect.de
[62.155.152.58]) by hub.org (8.9.3/8.9.3) with ESMTP id JAA09131
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 09:04:15 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 7C1AE2BB9E; Tue, 15 Feb 2000 13:24:06 +0100 (CET)
Date: Tue, 15 Feb 2000 13:24:06 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] function defined in libpq?
Message-ID: <20000215132406.A3178@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
References: <20000214105416.A9298@fam-meskes.de>
<Pine.GSO.4.02A.10002151312230.28210-100000@Krokodil.DoCS.UU.SE>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <Pine.GSO.4.02A.10002151312230.28210-100000@Krokodil.DoCS.UU.SE>;
from e99re41@DoCS.UU.SE on Tue, Feb 15, 2000 at 01:13:15PM +0100
Sender: michael@fam-meskes.de
On Tue, Feb 15, 2000 at 01:13:15PM +0100, Peter Eisentraut wrote:
Huh? I'm sure you don't mean adding a declaration to a header file and
putting the definition in a .c file of your choice, as well as ensuring
that it compiles?
Oops. No, of course not. I meant writing a C function using libpq, making it
a shared library and then adding it to the backend via CREATE FUNCTION.
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 Tue Feb 15 07:25:02 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA95744
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 07:25:00 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Krokodil.DoCS.UU.SE (e99re41@Krokodil.DoCS.UU.SE
[130.238.9.184])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id NAA00975;
Tue, 15 Feb 2000 13:24:51 +0100 (MET)
Received: from localhost (e99re41@localhost) by Krokodil.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id NAA28261;
Tue, 15 Feb 2000 13:24:49 +0100
X-Authentication-Warning: Krokodil.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 15 Feb 2000 13:24:49 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: The Hermit Hacker <scrappy@hub.org>
cc: Sevo Stille <sevo@ip23.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: schema: pg_dump -s ipmeter (fwd)
In-Reply-To: <Pine.BSF.4.21.0002142237000.74045-101000@thelab.hub.org>
Message-ID: <Pine.GSO.4.02A.10002151323220.28210-100000@Krokodil.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 14 Feb 2000, The Hermit Hacker wrote:
On Tue, 15 Feb 2000, Sevo Stille wrote:
The Hermit Hacker wrote:
Good question ... I'm getting:
pq_recvbuf: unexpected EOF on client connection
from the backend, which *sounds* like psql is crashing ...
gdb shows it dying:
(gdb) where
#0 0x4814d0bc in strcmp () from /usr/lib/libc.so.3
#1 0x804fb28 in becomeUser ()
#2 0x804f268 in dumpIndices ()
#3 0x80501fa in dumpSchemaIdx ()
#4 0x804a8c2 in main ()
#5 0x80494dd in _start ()
That looks more like a pg_dump trace to me. If you didn't know yet,
pg_dump 7.0 can't be used with previous databases, so maybe that's a
reason.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Feb 15 07:59:04 2000
Received: from andie.ip23.net (andie.ip23.net [212.83.32.23])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA00739
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 07:58:36 -0500 (EST) (envelope-from sevo@ip23.net)
Received: from imap1.ip23.net (imap1.ip23.net [212.83.32.35])
by andie.ip23.net (8.9.3/8.9.3) with ESMTP id NAA10742;
Tue, 15 Feb 2000 13:58:02 +0100 (CET)
Received: from ip23.net (spc.ip23.net [212.83.32.122])
by imap1.ip23.net (8.9.3/8.9.3) with ESMTP id NAA12137;
Tue, 15 Feb 2000 13:59:47 +0100 (CET)
Sender: sevo@imap1.ip23.net
Message-ID: <38A94D5A.6BD18832@ip23.net>
Date: Tue, 15 Feb 2000 13:58:02 +0100
From: Sevo Stille <sevo@ip23.net>
Organization: IP23
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i686)
X-Accept-Language: de, en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: schema: pg_dump -s ipmeter (fwd)
References: <Pine.GSO.4.02A.10002151323220.28210-100000@Krokodil.DoCS.UU.SE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Peter Eisentraut wrote:
That looks more like a pg_dump trace to me. If you didn't know yet,
pg_dump 7.0 can't be used with previous databases, so maybe that's a
reason.
If I got Marc right, pg_dump 6.5.3 was crashing on him while dumping
from a 6.5.3 db, and he can dump from 7.0 as well as from another 6.5.3
installation. It rather looks like becomeUser croaks the fourth time it
is called and the first time it is switching users, on that particular
installation. Might be something gone wrong with the user, but it could
as well be some obscure overflow problem that only rarely triggers.
Sevo
From bouncefilter Tue Feb 15 08:45:03 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA05653;
Tue, 15 Feb 2000 08:44:07 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Krokodil.DoCS.UU.SE (e99re41@Krokodil.DoCS.UU.SE
[130.238.9.184])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id OAA10097;
Tue, 15 Feb 2000 14:43:59 +0100 (MET)
Received: from localhost (e99re41@localhost) by Krokodil.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id OAA28430;
Tue, 15 Feb 2000 14:43:57 +0100
X-Authentication-Warning: Krokodil.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 15 Feb 2000 14:43:56 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Mike Mascari <mascarm@mascari.com>
cc: Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] function defined in libpq?
In-Reply-To: <38A91019.59932F48@mascari.com>
Message-ID: <Pine.GSO.4.02A.10002151442070.28210-100000@Krokodil.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 15 Feb 2000, Mike Mascari wrote:
On Mon, 14 Feb 2000, Michael Meskes wrote:
Could anyone please give me an example on how I can define a function using
libpq if that is at all possible?
I think what he wants to do is dynamically create a function from the client
side by issuing a CREATE FUNCTION statement (presumably one of the built-ins?
SQL, pl/pgSQL, pl/pgTcl.) For what its worth, I've issued a host of unlreated
DDL statements through PQexec and all of them have worked as expected, although
CREATE FUNCTION was never one of them...
Why wouldn't it work? Or, much more interesting, how else would you do it?
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Feb 15 14:03:07 2000
Received: from feivel.fam-meskes.de (h-62.96.159.23.host.de.colt.net
[62.96.159.23]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA53574
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 14:01:58 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id DF8C62BBA3; Tue, 15 Feb 2000 15:13:26 +0100 (CET)
Date: Tue, 15 Feb 2000 15:13:26 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] function defined in libpq?
Message-ID: <20000215151326.A10899@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
References: <Pine.GSO.4.02A.10002151312230.28210-100000@Krokodil.DoCS.UU.SE>
<38A91019.59932F48@mascari.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <38A91019.59932F48@mascari.com>;
from mascarm@mascari.com on Tue, Feb 15, 2000 at 03:36:41AM -0500
Sender: michael@fam-meskes.de
On Tue, Feb 15, 2000 at 03:36:41AM -0500, Mike Mascari wrote:
I think what he wants to do is dynamically create a function from the client
side by issuing a CREATE FUNCTION statement (presumably one of the built-ins?
SQL, pl/pgSQL, pl/pgTcl.) For what its worth, I've issued a host of unlreated
The function itself is defined using libpq.
CREATE FUNCTION was never one of them...
Creating the function through libpq works fine.
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 Tue Feb 15 09:16:04 2000
Received: from andie.ip23.net (andie.ip23.net [212.83.32.23])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA10806;
Tue, 15 Feb 2000 09:15:31 -0500 (EST) (envelope-from sevo@ip23.net)
Received: from imap1.ip23.net (imap1.ip23.net [212.83.32.35])
by andie.ip23.net (8.9.3/8.9.3) with ESMTP id PAA10836;
Tue, 15 Feb 2000 15:14:57 +0100 (CET)
Received: from ip23.net (spc.ip23.net [212.83.32.122])
by imap1.ip23.net (8.9.3/8.9.3) with ESMTP id PAA12255;
Tue, 15 Feb 2000 15:16:43 +0100 (CET)
Sender: sevo@imap1.ip23.net
Message-ID: <38A95F61.701B458C@ip23.net>
Date: Tue, 15 Feb 2000 15:14:57 +0100
From: Sevo Stille <sevo@ip23.net>
Organization: IP23
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i686)
X-Accept-Language: de, en
MIME-Version: 1.0
To: Michael Meskes <meskes@postgreSQL.org>
CC: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] function question yet again
References: <20000215131439.A2553@fam-meskes.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Michael Meskes wrote:
Is it possible to define a function in language 'C' that needs more
libraries to work? I've got a small example of a function that works like a
charm when run against from a binary. However if I put this function inside
the server and execute it I getERROR: parser: parse error at or near ""
Not exactly an error message that explains itself. :-)
Actually, it is very suggestive of quoting or escaping errors.
Presumably your statement terminates somewhere where you would not
expect it.
I have put my function into a shared library to load it, but the library
itself needs other libraries. Is this at all possible?
If the system knows how to find it, absolutely. That is, whatever you
depend on will have to be in a system or pgsql library directory.
Sevo
From bouncefilter Tue Feb 15 14:02:07 2000
Received: from feivel.fam-meskes.de (h-62.96.159.23.host.de.colt.net
[62.96.159.23]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA52566
for <pgsql-hackers@postgresql.org>;
Tue, 15 Feb 2000 14:01:36 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 3290A2BBA4; Tue, 15 Feb 2000 15:24:30 +0100 (CET)
Date: Tue, 15 Feb 2000 15:24:30 +0100
From: Michael Meskes <meskes@postgresql.org>
To: Alfred Perlstein <bright@wintelcom.net>
Cc: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] function question yet again
Message-ID: <20000215152430.B10899@fam-meskes.de>
Mail-Followup-To: Alfred Perlstein <bright@wintelcom.net>,
PostgreSQL Hacker <pgsql-hackers@postgresql.org>
References: <20000215131439.A2553@fam-meskes.de>
<20000215045848.K17536@fw.wintelcom.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <20000215045848.K17536@fw.wintelcom.net>;
from bright@wintelcom.net on Tue, Feb 15, 2000 at 04:58:49AM -0800
Sender: michael@fam-meskes.de
On Tue, Feb 15, 2000 at 04:58:49AM -0800, Alfred Perlstein wrote:
As a temporary hack you may want to try linking the shared object that you
are creating with the static versions of the third level libraries.
Good idea. Unfottunately it didn't change anything. Using ldd on my shared
library no tells me it is statically linked. But the error message remains
the same.
I tried to write a log file and it appears the function does correctly
connect to the backend but cannot execute the select. IDK however if a
function inside the backend is allowed to create a connection. But if not
how can I send a query over libpq?
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 Tue Feb 15 14:02:08 2000
Received: from feivel.fam-meskes.de (h-62.96.159.23.host.de.colt.net
[62.96.159.23]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA53281
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 14:01:55 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 917A52BBA5; Tue, 15 Feb 2000 15:26:20 +0100 (CET)
Date: Tue, 15 Feb 2000 15:26:20 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] function question yet again
Message-ID: <20000215152620.A11746@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
References: <20000215131439.A2553@fam-meskes.de>
<38A91179.AB924F0A@mascari.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="YiEDa0DAkWCtVeE4"
User-Agent: Mutt/1.0.1i
In-Reply-To: <38A91179.AB924F0A@mascari.com>;
from mascarm@mascari.com on Tue, Feb 15, 2000 at 03:42:33AM -0500
Sender: michael@fam-meskes.de
--YiEDa0DAkWCtVeE4
Content-Type: text/plain; charset=us-ascii
On Tue, Feb 15, 2000 at 03:42:33AM -0500, Mike Mascari wrote:
That's odd. Would it be possible for you to provide your compiliation/link
statement as well as your CREATE FUNCTION statement? I've a host of functions
which use external libaries that work as expected (on Linux), including doing
some pretty weird stuff.
I attach both files. My intend was to get this thing going by using ecpg.
I'm not sure anymore if this is at all possible.
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!
--YiEDa0DAkWCtVeE4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="test5.pgc"
#include <stdlib.h>
#include <stdio.h>
EXEC SQL INCLUDE sqlca;
static void ErrorExit (void);
int main (void)
{
EXEC SQL BEGIN DECLARE SECTION;
int result;
int values[2], i;
EXEC SQL END DECLARE SECTION;
FILE *dbgs;
if ((dbgs = fopen("log", "w")) != NULL)
ECPGdebug(1, dbgs);
EXEC SQL WHENEVER SQLERROR DO ErrorExit();
EXEC SQL CONNECT TO 'mm';
EXEC SQL CREATE TABLE tab (index int);
EXEC SQL INSERT INTO tab(index) values(14);
EXEC SQL INSERT INTO tab(index) values(7);
EXEC SQL COMMIT;
EXEC SQL CREATE FUNCTION my_fun () RETURNS int AS
'/home/postgres/pgsql/src/interfaces/ecpg.mm/test/stp.so' LANGUAGE 'C';
EXEC SQL COMMIT;
EXEC SQL SELECT index INTO :values FROM tab;
for (i = 0; i < 2; i++)
printf("tab[%d] = %d\n", i, values[i]);
EXEC SQL SELECT my_fun () INTO :result;
printf ("result = %d\n", result);
EXEC SQL DROP TABLE tab;
EXEC SQL DROP FUNCTION my_fun ();
EXEC SQL COMMIT;
EXEC SQL DISCONNECT;
if (dbgs != NULL)
fclose(dbgs);
exit (0);
}
static void ErrorExit (void)
{
EXEC SQL WHENEVER SQLERROR CONTINUE;
sqlprint();
EXEC SQL ROLLBACK;
EXEC SQL DROP TABLE tab;
EXEC SQL DROP FUNCTION my_fun ();
EXEC SQL COMMIT;
EXEC SQL DISCONNECT;
exit (-1);
}
--YiEDa0DAkWCtVeE4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="stp.pgc"
EXEC SQL INCLUDE sqlca;
int my_fun (void)
{
EXEC SQL BEGIN DECLARE SECTION;
int sql_index = 0;
EXEC SQL END DECLARE SECTION;
FILE *dbgs;
if ((dbgs = fopen("log", "w")) != NULL)
ECPGdebug(1, dbgs);
EXEC SQL WHENEVER SQLERROR GOTO Error;
EXEC SQL CONNECT TO 'mm';
EXEC SQL SELECT MIN(index) INTO :sql_index FROM tab;
EXEC SQL DISCONNECT;
if (dbgs != NULL)
fclose(dbgs);
return (sql_index);
Error:
return (sqlca.sqlcode);
}
--YiEDa0DAkWCtVeE4--
From bouncefilter Tue Feb 15 09:52:04 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 JAA15559
for <pgsql-hackers@postgresql.org>;
Tue, 15 Feb 2000 09:51:59 -0500 (EST) (envelope-from jeffm@pgsql.com)
Received: from rage.hub.org (nat195.216.mpoweredpc.net [142.177.195.216])
by clio.trends.ca (8.9.3+Sun/8.9.3) with ESMTP id JAA09691
for <pgsql-hackers@postgresql.org>;
Tue, 15 Feb 2000 09:51:50 -0500 (EST)
Received: from localhost (jeffm@localhost)
by rage.hub.org (8.9.3/8.9.3) with ESMTP id KAA41870
for <pgsql-hackers@postgresql.org>;
Tue, 15 Feb 2000 10:42:11 -0400 (AST) (envelope-from jeffm@pgsql.com)
X-Authentication-Warning: rage.hub.org: jeffm owned process doing -bs
Date: Tue, 15 Feb 2000 10:42:10 -0400 (AST)
From: "Jeff MacDonald <jeff@pgsql.com>" <jeffm@pgsql.com>
X-Sender: jeffm@rage.hub.org
Reply-To: Jeff MacDonald <jeff@pgsql.com>
To: pgsql-hackers@postgresql.org
Subject: Most Advanced
Message-ID: <Pine.BSF.4.10.10002151041030.10395-100000@rage.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi,
For PostgreSQL We tend to use the Phrase
"Most Advanced Open Source RDBMS" alot.
Will this statement still hold true when/if
Inprise becomes open source ?
Jeff
======================================================
Jeff MacDonald
jeff@pgsql.com irc: bignose on EFnet
======================================================
From bouncefilter Tue Feb 15 15:13:08 2000
Received: from corvette.mascari.com (dhcp26136108.columbus.rr.com
[24.26.136.108]) by hub.org (8.9.3/8.9.3) with ESMTP id PAA68529;
Tue, 15 Feb 2000 15:12:07 -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 PAA05046;
Tue, 15 Feb 2000 15:10:43 -0500
Sender: mascarm@corvette.mascari.com
Message-ID: <38A96C2F.6796050A@mascari.com>
Date: Tue, 15 Feb 2000 10:09:35 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Meskes <meskes@postgreSQL.org>
CC: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] function question yet again
References: <20000215131439.A2553@fam-meskes.de>
<38A91179.AB924F0A@mascari.com>
<20000215152620.A11746@fam-meskes.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Michael Meskes wrote:
I attach both files. My intend was to get this thing going by using
ecpg.
I'm not sure anymore if this is at all possible.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!
Wow. I'm not quite sure why it shouldn't work, but I've never
reconnected on the server side through libpq. Instead, I've
always used the SPI interface sequence of:
SPI_connect()
SPI_exec()
SPI_getvalue()
SPI_finish()
I think I've tried in the past to reconnect on the server side
through libpq but it always resulted in a core dump of the
running backend.
Sorry I'm no more help then that,
Mike Mascari
From bouncefilter Tue Feb 15 10:51:05 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 KAA21090
for <pgsql-hackers@postgresql.org>;
Tue, 15 Feb 2000 10:50:24 -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 KAA04647;
Tue, 15 Feb 2000 10:50:23 -0500
Message-ID: <38A975B9.30F3AFFA@wgcr.org>
Date: Tue, 15 Feb 2000 10:50:17 -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: Jeff MacDonald <jeff@pgsql.com>
CC: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Most Advanced
References: <Pine.BSF.4.10.10002151041030.10395-100000@rage.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"Jeff MacDonald " wrote:
Hi,
For PostgreSQL We tend to use the Phrase
"Most Advanced Open Source RDBMS" alot.Will this statement still hold true when/if
Inprise becomes open source ?
Now that's a good question. If we rephrase our tag to:
"Most Advanced Open Source ORDBMS" it's not a problem.
However, it really depends upon what apects in which we consider
ourselves to be the "Most Advanced" -- what is "Advanced" in that
context? Are we advanced in terms of features, or are we advanced in
terms of our development process? I believe we are advanced in both
regards -- and we're certainly the most advanced when it comes to
maturity of development in an open source fashion -- advanced in age in
that context.
Until InterBase is released open source, it remains to be seen how
advanced of an open source database it will be.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Tue Feb 15 10:53:06 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 KAA21270
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 10:52: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
KAA04021;
Tue, 15 Feb 2000 10:50:59 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002151550.KAA04021@candle.pha.pa.us>
Subject: Re: [HACKERS] Most Advanced
In-Reply-To: <Pine.BSF.4.10.10002151041030.10395-100000@rage.hub.org> from
"Jeff MacDonald <jeff@pgsql.com>" at "Feb 15, 2000 10:42:10 am"
To: Jeff MacDonald <jeff@pgsql.com>
Date: Tue, 15 Feb 2000 10:50:59 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hi,
For PostgreSQL We tend to use the Phrase
"Most Advanced Open Source RDBMS" alot.Will this statement still hold true when/if
Inprise becomes open source ?
That is my statement originally because we weren't getting good press.
Yes, I don't think Inprise will match us at all. Our Object-Relational
features will keep s as most advanced for the foreseeable future.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 15 10:59:10 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 KAA21993
for <hackers@postgreSQL.org>; Tue, 15 Feb 2000 10:58:53 -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 KAA12129;
Tue, 15 Feb 2000 10:58:02 -0500 (EST)
To: Oleg Bartunov <oleg@sai.msu.su>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] ERROR: copyObject: don't know how to copy 1381319466
In-reply-to: <Pine.GSO.3.96.SK.1000215140237.16880A-100000@ra>
References: <Pine.GSO.3.96.SK.1000215140237.16880A-100000@ra>
Comments: In-reply-to Oleg Bartunov <oleg@sai.msu.su>
message dated "Tue, 15 Feb 2000 14:04:11 +0300"
Date: Tue, 15 Feb 2000 10:58:02 -0500
Message-ID: <12126.950630282@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Oleg Bartunov <oleg@sai.msu.su> writes:
ERROR: copyObject: don't know how to copy 1381319466
Do I need initdb ? postamster started normally
Probably --- I recall Thomas muttering yesterday that he needed an
initdb himself. FWIW, I got fairly clean regress results from a
CVS pull of about 1AM (6AM GMT) this morning ... but I did initdb.
No catversion.h update to force initdb though. Naughty naughty,
Thomas...
regards, tom lane
From bouncefilter Tue Feb 15 11:00:06 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 KAA22122
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 10:59:43 -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 KAA04669;
Tue, 15 Feb 2000 10:59:44 -0500
Message-ID: <38A977EB.B5C2B95D@wgcr.org>
Date: Tue, 15 Feb 2000 10:59: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-hackers@postgreSQL.org
Subject: Re: [HACKERS] Release on the 15th?
References: <38A87153.FDD9EE7@wgcr.org> <38A8BDAA.A83C9ACD@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas Lockhart wrote:
Are we still 'go' for a beta release the 15th?
Uh, it's never been a good idea to set your watch by our beta release
schedule.
I have found that out, acutally, with the three minors to 6.5.
In fact, for purposes of RPM building, I'd suggest lagging
even up to a day or two to see if some immediate problems crop up and
are fixed.
Well, having been on the other side of the fence, so to speak, WRT the
RPM's, I may be overreacting a little. I was always aggravated and
annoyed by the long lag (up to six months prior to 6.5) between a
PostgreSQL release and an RPM for me to bang on. While I could very
well have pulled the source tarball and gone through a conversion from
an RPM installation to a tarball installation, I was not too enamored of
that approach, just to have to move the other way at RedHat-upgrade
time.
So, I got involved in the RPM building process primarily so that RPM
PostgreSQL users that want to beta test (if I was interested in doing
so, I know there were and are more) can have a timely beta to test.
Maybe I'm a little too zealous in this regards....
However, even the packaging itself this go around is beta. I will want
to have RPM's out there being tested long before a final 7.0 release.
Plus, since I am building on RedHat for the RPM's, I catch build-time
bugs for that OS early.
But, if you feel I should lag a couple of days, I can do that.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Tue Feb 15 11:03:06 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 LAA22594
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 11:02:29 -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
LAA04685;
Tue, 15 Feb 2000 11:01:36 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002151601.LAA04685@candle.pha.pa.us>
Subject: Re: [HACKERS] Most Advanced
In-Reply-To: <38A975B9.30F3AFFA@wgcr.org> from Lamar Owen at "Feb 15,
2000 10:50:17 am"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Tue, 15 Feb 2000 11:01:36 -0500 (EST)
CC: Jeff MacDonald <jeff@pgsql.com>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Now that's a good question. If we rephrase our tag to:
"Most Advanced Open Source ORDBMS" it's not a problem.However, it really depends upon what apects in which we consider
ourselves to be the "Most Advanced" -- what is "Advanced" in that
context? Are we advanced in terms of features, or are we advanced in
terms of our development process? I believe we are advanced in both
regards -- and we're certainly the most advanced when it comes to
maturity of development in an open source fashion -- advanced in age in
that context.Until InterBase is released open source, it remains to be seen how
advanced of an open source database it will be.
Is Interbase any good? I never heard of them much. Sounds like it is a
PC database like dbase, right? They don't scale very well.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 15 11:49:07 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 LAA27750
for <pgsql-hackers@postgresql.org>;
Tue, 15 Feb 2000 11:48:14 -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 LAA04736;
Tue, 15 Feb 2000 11:48:12 -0500
Message-ID: <38A98346.9E75AD3C@wgcr.org>
Date: Tue, 15 Feb 2000 11:48:06 -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: Jeff MacDonald <jeff@pgsql.com>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Most Advanced
References: <200002151601.LAA04685@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Until InterBase is released open source, it remains to be seen how
advanced of an open source database it will be.
Is Interbase any good? I never heard of them much. Sounds like it is a
PC database like dbase, right? They don't scale very well.
Well, rummaging around the interbase.com website, I found an
introductory whitepaper that lists their features. Check
http://www.interbase.com/downloads/what_is_ib.pdf for more info.
It seems to be an interesting system. To summarize its features (going
quickly against the PDF referenced above):
Client-server architecture;
SQL parser in server;
Server side triggers;
Stored Procedures;
User-defined functions;
Event alerters (that notify clients of database changes);
Declarative Referential Integrity with cascading operations;
Domains and contstraints extend SQL types;
Automatic two-phase commit to stabilize distributed mulit-database
transactions;
Cross-platform scalability and interoperability;
Small footprint (3MB disk for minimum, ~20MB for full install)
Up to 150 concurrent clients;
Y2K correct;
Implements entry level SQL-92, plus many intermediate level features and
selected features from the full level;
InterBase Corp has voting member status in the ANSI SQL standards
committee, X3H2;
SQL Roles for group-level security;
SQL-92 syntax for inner and outer JOIN clauses;
Views on tables and joins;
Select procedures (that return not a value, but a result set);
Full transactional operation;
MultiGenerational Architecture (basically the same as our MVCC);
Row-level locking;
Multiple concurrent transactions on a per-client basis -- each client
can have multiple concurrent transactions;
Distributed transactions -- a single transaction can be open against
multiple databases, with a two-phase commit;
BLOBs;
Arrays (implemented as structured BLOBs);
BLOB filter functions (such as a JPEG to PNG translator);
Cost-analysis query optimization;
On Unix systems, the InterBase security can be integrated with OS
security;
Internationalization support, including UNICODE;
Integration with Borland JBuilder;
ODBC client;
Automatic garbage collection -- no vacuum;
No preallocation of disk space required -- files up to 4GB in size, with
expansion through the use of secondary files (similar to our
segmentation);
Full ACID compliance.
That's the short version.
I don't see stuff like:
Ability to use Tcl and Perl in stored procedural functions;
Object Relational in nature;
Endlessly extensible for types, languages, functions, etc. (I
especially like that one).
And other features of PostgreSQL that we know and love. Nor do I see as
many supported architectures.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Tue Feb 15 12:24:07 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA33712
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 12:23: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 NAA84256;
Tue, 15 Feb 2000 13:23:42 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 15 Feb 2000 13:23:42 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Peter Eisentraut <peter_e@gmx.net>
cc: Sevo Stille <sevo@ip23.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: schema: pg_dump -s ipmeter (fwd)
In-Reply-To: <Pine.GSO.4.02A.10002151323220.28210-100000@Krokodil.DoCS.UU.SE>
Message-ID: <Pine.BSF.4.21.0002151323120.74045-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 15 Feb 2000, Peter Eisentraut wrote:
On Mon, 14 Feb 2000, The Hermit Hacker wrote:
On Tue, 15 Feb 2000, Sevo Stille wrote:
The Hermit Hacker wrote:
Good question ... I'm getting:
pq_recvbuf: unexpected EOF on client connection
from the backend, which *sounds* like psql is crashing ...
gdb shows it dying:
(gdb) where
#0 0x4814d0bc in strcmp () from /usr/lib/libc.so.3
#1 0x804fb28 in becomeUser ()
#2 0x804f268 in dumpIndices ()
#3 0x80501fa in dumpSchemaIdx ()
#4 0x804a8c2 in main ()
#5 0x80494dd in _start ()That looks more like a pg_dump trace to me. If you didn't know yet,
pg_dump 7.0 can't be used with previous databases, so maybe that's a
reason.
I *really* hope you don't mean that you cn't pg_dump from v6.5.3 (what I
was trying) and reload again into 7.0? :)
From bouncefilter Tue Feb 15 12:25:12 2000
Received: from marvin.muc.de (marvin.muc.de [193.149.48.2])
by hub.org (8.9.3/8.9.3) with SMTP id MAA33772
for <hackers@postgresql.org>; Tue, 15 Feb 2000 12:24:10 -0500 (EST)
(envelope-from
moderators-muc-lists-postgres-hackers-owner@moderators.muc.de)
Received: (qmail 51748 invoked by alias); 15 Feb 2000 17:23:14 -0000
Delivered-To: moderators-muc-lists-postgres-hackers@moderators.muc.de
Received: (qmail 51743 invoked from network); 15 Feb 2000 17:23:14 -0000
Received: from mailout01.sul.t-online.de (194.25.134.80)
by marvin.muc.de with SMTP; 15 Feb 2000 17:23:14 -0000
Received: from imh00.btx.dtag.de by mailout01.sul.t-online.de with smtp
id 12KlhF-0002lw-00; Tue, 15 Feb 2000 18:23:33 +0100
Received: from news03.btx.dtag.de by imh00.btx.dtag.de
with esmtp id 12KlhF-0001kY-00; Tue, 15 Feb 2000 18:23:33 +0100
Received: from news by news03.btx.dtag.de
with local id 12KlhE-00015Y-00; Tue, 15 Feb 2000 18:23:33 +0100
To: muc-lists-postgres-hackers@moderators.muc.de
Path: news.btx.dtag.de!not-for-mail
From: "Andreas" <angelheart@t-online.de>
Newsgroups: muc.lists.postgres.hackers
Subject: Germany
Date: Tue, 15 Feb 2000 18:26:20 +0100
Organization: T-Online
Lines: 4
Message-ID: <88c22k$42r$1@news03.btx.dtag.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: news03.btx.dtag.de 950635412 4187 04182293415-0001 000215 17:23:32
X-Complaints-To: abuse@t-online.de
X-Sender: 04182293415-0001@t-dialin.net
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Gibt es in dieser Newsgroup auch jemanden der Deutsch spricht?????
From bouncefilter Tue Feb 15 12:28:07 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA34353
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 12:27: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 NAA84303;
Tue, 15 Feb 2000 13:27:06 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 15 Feb 2000 13:27:06 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Release on the 15th?
In-Reply-To: <2179.950596381@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0002151326280.74045-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 15 Feb 2000, Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
Couple more days, Marc?
Say Monday?
I think I can do Monday, but I don't know where Thomas is. Doesn't
he still want to squeeze in the date/time type consolidation?
Okay, let's set Monday for now, and re-evaluate, let's say, Friday, as to
whether we need to postpone a little bit more ...
From bouncefilter Tue Feb 15 12:37:09 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA35606
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 12:36:32 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Krokodil.DoCS.UU.SE (e99re41@Krokodil.DoCS.UU.SE
[130.238.9.184])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id SAA00404;
Tue, 15 Feb 2000 18:36:23 +0100 (MET)
Received: from localhost (e99re41@localhost) by Krokodil.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id SAA28860;
Tue, 15 Feb 2000 18:36:21 +0100
X-Authentication-Warning: Krokodil.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 15 Feb 2000 18:36:20 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Lamar Owen <lamar.owen@wgcr.org>, Jeff MacDonald <jeff@pgsql.com>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Most Advanced
In-Reply-To: <200002151601.LAA04685@candle.pha.pa.us>
Message-ID: <Pine.GSO.4.02A.10002151732440.28210-100000@Krokodil.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 15 Feb 2000, Bruce Momjian wrote:
Is Interbase any good? I never heard of them much. Sounds like it is a
PC database like dbase, right? They don't scale very well.
"InterBase is an enterprise-level database system used by firms and
agencies like Nokia, MCI, Northern Telecom, NASA, the US Army, and Boeing.
Despite its speed and capabilities, it has been a well-kept secret and
holds an insignificant share of the relational database market. Growth of
that market has slowed, reducing chance for InterBase to increase its
share as a proprietary product."
Although they do stand in the tradition of dBase and Paradox, they do
appear to be a serious product. This URL might give you an idea what kind
of SQL (and beyond) they support.
<http://www.interbase.com/products/dsqlsyntax.html>
Also, they seem to have an edge (against us) in the areas of logging
(journaling) and distributed stuff. Their client languages seem to
concentrate around Delphi, C++, and Java.
I am just wondering how/whether they will be able to enlist any outside
developers in significant masses. (see also Mozilla)
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Feb 15 12:39:06 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA35837
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 12:38:28 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Krokodil.DoCS.UU.SE (e99re41@Krokodil.DoCS.UU.SE
[130.238.9.184])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id SAA00568;
Tue, 15 Feb 2000 18:38:21 +0100 (MET)
Received: from localhost (e99re41@localhost) by Krokodil.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id SAA28866;
Tue, 15 Feb 2000 18:38:19 +0100
X-Authentication-Warning: Krokodil.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 15 Feb 2000 18:38:18 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: The Hermit Hacker <scrappy@hub.org>
cc: Sevo Stille <sevo@ip23.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: schema: pg_dump -s ipmeter (fwd)
In-Reply-To: <Pine.BSF.4.21.0002151323120.74045-100000@thelab.hub.org>
Message-ID: <Pine.GSO.4.02A.10002151836560.28210-100000@Krokodil.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 15 Feb 2000, The Hermit Hacker wrote:
I *really* hope you don't mean that you cn't pg_dump from v6.5.3 (what I
was trying) and reload again into 7.0? :)
No, what I meant was that you can't use pg_dump 7.0 to dump non-7.0
databases. At least it was like this last time I tried it.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Feb 15 13:05:06 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA39895
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 13:04: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 OAA84539;
Tue, 15 Feb 2000 14:04:13 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 15 Feb 2000 14:04:13 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Peter Eisentraut <peter_e@gmx.net>
cc: Sevo Stille <sevo@ip23.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: schema: pg_dump -s ipmeter (fwd)
In-Reply-To: <Pine.GSO.4.02A.10002151836560.28210-100000@Krokodil.DoCS.UU.SE>
Message-ID: <Pine.BSF.4.21.0002151404000.74045-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 15 Feb 2000, Peter Eisentraut wrote:
On Tue, 15 Feb 2000, The Hermit Hacker wrote:
I *really* hope you don't mean that you cn't pg_dump from v6.5.3 (what I
was trying) and reload again into 7.0? :)No, what I meant was that you can't use pg_dump 7.0 to dump non-7.0
databases. At least it was like this last time I tried it.
Okay, that I would expect ... :)
From bouncefilter Tue Feb 15 12:57:09 2000
Received: from hu.tm.ee (ppp875.tele2.ee [212.107.37.175])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA38519
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 12:56:59 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 198693B02; Tue, 15 Feb 2000 20:04:56 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38A99547.FEE6D99F@tm.ee>
Date: Tue, 15 Feb 2000 20:04: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: Lamar Owen <lamar.owen@wgcr.org>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>, Jeff MacDonald <jeff@pgsql.com>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Most Advanced
References: <200002151601.LAA04685@candle.pha.pa.us>
<38A98346.9E75AD3C@wgcr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lamar Owen wrote:
Bruce Momjian wrote:
Until InterBase is released open source, it remains to be seen how
advanced of an open source database it will be.Is Interbase any good? I never heard of them much. Sounds like it is a
PC database like dbase, right? They don't scale very well.
IIRC it was missing shared cache between backends.
It seems to be an interesting system. To summarize its features (going
quickly against the PDF referenced above):
I try putting a + or - based on weather PG has it (please correct me)
+> Client-server architecture;
+> SQL parser in server;
+> Server side triggers;
+> Stored Procedures;
+> User-defined functions;
+> Event alerters (that notify clients of database changes);Actually or LISTEN/NOTIFY would could use some improvement, it would be
much more powerful if it allowed even a single argument to be passed.
+> Declarative Referential Integrity with cascading operations;
Will be in 7.0 ?
-> Domains and contstraints extend SQL types;
?> Automatic two-phase commit to stabilize distributed mulit-database
transactions;
+> Cross-platform scalability and interoperability;
+> Small footprint (3MB disk for minimum, ~20MB for full install)PG should be about the same size
+> Up to 150 concurrent clients;
What is the upper limit for PG ?
+> Y2K correct;
+> Implements entry level SQL-92, plus many intermediate level features and
selected features from the full level;
-> InterBase Corp has voting member status in the ANSI SQL standards
committee, X3H2;Is this the bunch of guys we often fondly remember for their SQL3 standard ?
-> SQL Roles for group-level security;
+> SQL-92 syntax for inner and outer JOIN clauses;
Will be in 7.0 ?
+> Views on tables and joins;
-> Select procedures (that return not a value, but a result set);This requires a rewrite of the pl function API
+> Full transactional operation;
+> MultiGenerational Architecture (basically the same as our MVCC);
?> Row-level locking;How are we doing here ?
?> Multiple concurrent transactions on a per-client basis -- each client
can have multiple concurrent transactions;
If client==connection, then we don't have it, if we opened a connection per
trx we do
-> Distributed transactions -- a single transaction can be open against
multiple databases, with a two-phase commit;
Support for multi-db is generally weak in PG. A single connction can work only
with one db at a time
+> BLOBs;
We have LOs, but the implementation is nut usable for more than a few on
most UNIX filesystems (we have one LO per file, all in the same directory with
everything else)
+> Arrays (implemented as structured BLOBs);
But nut implemented as structured BLOBS ;)
+> BLOB filter functions (such as a JPEG to PNG translator);
Could be done easily, but not included in distribution at least.
+> Cost-analysis query optimization;
+> On Unix systems, the InterBase security can be integrated with OS
security;
+> Internationalization support, including UNICODE;Do we have UNICODE (or just several other MB charsets)?
-> Integration with Borland JBuilder;
No intgration but can be used from it
+> ODBC client;
-> Automatic garbage collection -- no vacuum;Implementing it to be _fully_ automatic would make it very hard to
re-introduce time travel.
We have it semi-automatic using psql -c "vacuum;" in cron ;-p
+> No preallocation of disk space required -- files up to 4GB in size, with
expansion through the use of secondary files (similar to our
segmentation);
+> Full ACID compliance.That's the short version.
I don't see stuff like:
+> Ability to use Tcl and Perl in stored procedural functions;
-> Object Relational in nature;Maybe we should rephrase it to "Object Relational by ancestry".
We have very few OR features currently in working order, and
probably won't before 7.1. Chris Bitmead has patches for making
inherited tables work right (for SELECT,DELETE,UPDATE), but
they won't probably be included in 7.0 as they change the behaviour
of the only statment (SELECT) that is currently working to some extent
and some of the core developers seem to be dependent on the old
behaviour, i.e using inheritance as a shortcut for including the
same set of columns in an unrelated table.
Also people were set back by SQL3 standard which pg should (?) follow
to some extent at least, but which is incomprehensible when read
directly and which can only be understood through the works
of apostles ;)
+> Endlessly extensible for types, languages, functions, etc. (I
especially like that one).
Otoh, they have implemented DOMAINS, which allow much of simpler types to
be done at SQL level. They won't probably be indexable.
-------------------
Hannu
From bouncefilter Tue Feb 15 13:14:11 2000
Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net
[194.217.242.92]) by hub.org (8.9.3/8.9.3) with ESMTP id NAA41363
for <pgsql-hackers@postgresql.org>;
Tue, 15 Feb 2000 13:13:49 -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 anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1)
id 12KmTr-000EFf-0Y; Tue, 15 Feb 2000 18:13:47 +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 SAA11098;
Tue, 15 Feb 2000 18:13:46 GMT
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <1050AZ6Y>; Tue, 15 Feb 2000 18:12:43 -0000
Message-ID:
<1B3D5E532D18D311861A00600865478C70C1E3@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'The Hermit Hacker'" <scrappy@hub.org>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Lamar Owen <lamar.owen@wgcr.org>, pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] Release on the 15th?
Date: Tue, 15 Feb 2000 18:12:42 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Monday would be good for me...
[Now to see what else is going to go wrong... :-(]
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, February 15, 2000 1:20 AM
To: Tom Lane
Cc: Lamar Owen; pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Release on the 15th?
On Mon, 14 Feb 2000, Tom Lane wrote:
Lamar Owen <lamar.owen@wgcr.org> writes:
Are we still 'go' for a beta release the 15th?
Um ... I'm not ready ...
Couple more days, Marc?
Say Monday?
Marc G. Fournier ICQ#7615664 IRC Nick:
Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary:
scrappy@{freebsd|postgresql}.org
************
From bouncefilter Tue Feb 15 14:24:07 2000
Received: from feivel.fam-meskes.de (h-62.96.159.195.host.de.colt.net
[62.96.159.195]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA62268
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 14:23:07 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id CA4622BBA4; Tue, 15 Feb 2000 20:21:21 +0100 (CET)
Date: Tue, 15 Feb 2000 20:21:21 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] function question yet again
Message-ID: <20000215202121.B1114@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
References: <20000215131439.A2553@fam-meskes.de> <38A95F61.701B458C@ip23.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <38A95F61.701B458C@ip23.net>;
from sevo@ip23.net on Tue, Feb 15, 2000 at 03:14:57PM +0100
Sender: michael@fam-meskes.de
On Tue, Feb 15, 2000 at 03:14:57PM +0100, Sevo Stille wrote:
Actually, it is very suggestive of quoting or escaping errors.
Presumably your statement terminates somewhere where you would not
expect it.
Okay. But why does it work when run from outside the backend?
If the system knows how to find it, absolutely. That is, whatever you
depend on will have to be in a system or pgsql library directory.
I made my shared lib not depend on any other lib, but nothing changes.
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 Tue Feb 15 15:25:11 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 PAA70865
for <pgsql-hackers@postgresql.org>;
Tue, 15 Feb 2000 15:24:42 -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
PAA11097;
Tue, 15 Feb 2000 15:18:14 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002152018.PAA11097@candle.pha.pa.us>
Subject: Re: [HACKERS] Most Advanced
In-Reply-To: <Pine.GSO.4.02A.10002151732440.28210-100000@Krokodil.DoCS.UU.SE>
from Peter Eisentraut at "Feb 15, 2000 06:36:20 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Tue, 15 Feb 2000 15:18:14 -0500 (EST)
CC: Lamar Owen <lamar.owen@wgcr.org>, Jeff MacDonald <jeff@pgsql.com>,
pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Tue, 15 Feb 2000, Bruce Momjian wrote:
Is Interbase any good? I never heard of them much. Sounds like it is a
PC database like dbase, right? They don't scale very well."InterBase is an enterprise-level database system used by firms and
agencies like Nokia, MCI, Northern Telecom, NASA, the US Army, and Boeing.
Despite its speed and capabilities, it has been a well-kept secret and
holds an insignificant share of the relational database market. Growth of
that market has slowed, reducing chance for InterBase to increase its
share as a proprietary product."Although they do stand in the tradition of dBase and Paradox, they do
appear to be a serious product. This URL might give you an idea what kind
of SQL (and beyond) they support.<http://www.interbase.com/products/dsqlsyntax.html>
Also, they seem to have an edge (against us) in the areas of logging
(journaling) and distributed stuff. Their client languages seem to
concentrate around Delphi, C++, and Java.I am just wondering how/whether they will be able to enlist any outside
developers in significant masses. (see also Mozilla)
Yes, that is a key question. I know Solaris got criticized about over
their new "Solaris" open-source license, and I heard the
Monzilla/Netscape code was so ugly that the open source effort is going
very slowly.
Honestly, a big part of success is atmosphere and code structure.
Without both of those, it is pretty slow going. It is hard to imagine
how anyone would _new_ would start working on Interbase rather than
PostgreSQL because of our good reputation.
Also, Corel bough Inprise/Borland, so there is no way of knowing what
will happen with Interbase now. I just heard that the new WordPerfect
Office will run under WINE(yuck) rather than native Linux/Unix. That is
quite bad and a clear failure for Corel IMHO. Corel doesn't seem to be
very good at enlisting assistance in open source projects. The
developed their _own_ version of WINE to get Word Perfect Office out the
door, and they say they will merge their changes in "later" to main WINE
distribution. Their WINE source is accessible, though.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 15 16:04:09 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 QAA74476
for <hackers@postgreSQL.org>; Tue, 15 Feb 2000 16:03:31 -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 QAA23667;
Tue, 15 Feb 2000 16:02:11 -0500 (EST)
To: Thomas Lockhart <Thomas.Lockhart@jpl.nasa.gov>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Almost there on column aliases
In-reply-to: <38A8C61D.90557A4B@alumni.caltech.edu>
References: <38A3A7DB.6A684EF@alumni.caltech.edu>
<18707.950251267@sss.pgh.pa.us>
<38A3B745.E720A4AC@alumni.caltech.edu>
<18803.950253638@sss.pgh.pa.us>
<38A432D2.D6998E5B@alumni.caltech.edu>
<19051.950545044@sss.pgh.pa.us>
<38A8368B.68AF6CDA@alumni.caltech.edu>
<22598.950555491@sss.pgh.pa.us>
<38A8C61D.90557A4B@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Tue, 15 Feb 2000 03:21:01 +0000"
Date: Tue, 15 Feb 2000 16:02:10 -0500
Message-ID: <23664.950648530@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
The problem I recall is that paren also introduces a "plan", and if
you call nodeRead() it sees the paren and then complains later because
it expects a node label following the paren.
I probably misdiagnosed the behavior, but in any case I'd be *really*
happy if someone wants to put me out of my misery on this one ;)
Ah-hah, I see it. nodeRead() expects that simple Value objects
(T_Integer, T_Float, T_String) will be output without any '{' ... '}'
wrapping. _outNode() was putting them out with wrapping. Apparently,
you're the first person in a long time (maybe forever) to try to dump
and reload node structures in which these node types appear outside
the context of a Const node. (outConst calls outValue directly, without
going through outNode, so the bug didn't appear in that case.)
I've fixed _outNode() to suppress the unwanted wrapper for a Value
and removed the now-unnecessary special-case code for Attr lists.
BTW, the rule regress test is presently failing because I modified
ruleutils.c to dump the Attr list if it is not null, rather than
only if the refname is different from the relname:
*** 992,1008 ****
quote_identifier(rte->relname),
inherit_marker(rte));
if (strcmp(rte->relname, rte->ref->relname) != 0)
- {
- List *col;
appendStringInfo(buf, " %s",
quote_identifier(rte->ref->relname));
appendStringInfo(buf, " (");
! foreach (col, rte->ref->attrs)
{
! if (col != lfirst(rte->ref->attrs))
appendStringInfo(buf, ", ");
! appendStringInfo(buf, "%s", strVal(col));
}
}
}
}
--- 992,1012 ----
quote_identifier(rte->relname),
inherit_marker(rte));
if (strcmp(rte->relname, rte->ref->relname) != 0)
appendStringInfo(buf, " %s",
quote_identifier(rte->ref->relname));
+ if (rte->ref->attrs != NIL)
+ {
+ List *col;
+
appendStringInfo(buf, " (");
! foreach(col, rte->ref->attrs)
{
! if (col != rte->ref->attrs)
appendStringInfo(buf, ", ");
! appendStringInfo(buf, "%s",
! quote_identifier(strVal(lfirst(col))));
}
+ appendStringInfo(buf, ")");
}
}
}While this seems like appropriate logic, a bunch of the rule tests are
now showing long and perfectly content-free lists of attribute names in
reverse-listed FROM clauses. This bothers me because it implies that
those names are being stored in the querytree that's dumped out to
pg_rewrite, which will be a further crimp in people's ability to write
complex rules. I think we really don't want to store those nodes if we
don't have to. Why are we building Attr lists when there's no actual
column aliasing being done?
regards, tom lane
From bouncefilter Tue Feb 15 16:10:09 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 QAA75337
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 16:09: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 QAA14889
for pgsql-hackers@postgreSQL.org; Tue, 15 Feb 2000 16:09:03 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002152109.QAA14889@candle.pha.pa.us>
Subject: Interbase
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Tue, 15 Feb 2000 16:09:03 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Something someone pointed out to me recently is that when comparing
databases, you have to look at the speed of improvement as well as
current features. While we are behind some commercial databases, our
improvement speed is far better than theirs, so we will overtake them
sometime in the future.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 15 16:13:14 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA75789
for <pgsql-hackers@postgresql.org>;
Tue, 15 Feb 2000 16:12: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 RAA86135;
Tue, 15 Feb 2000 17:12:17 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 15 Feb 2000 17:12:17 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>, Lamar Owen <lamar.owen@wgcr.org>,
Jeff MacDonald <jeff@pgsql.com>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Most Advanced
In-Reply-To: <200002152018.PAA11097@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0002151707590.74045-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 15 Feb 2000, Bruce Momjian wrote:
Also, Corel bough Inprise/Borland, so there is no way of knowing what
will happen with Interbase now. I just heard that the new WordPerfect
Office will run under WINE(yuck) rather than native Linux/Unix. That
is quite bad and a clear failure for Corel IMHO. Corel doesn't seem
to be very good at enlisting assistance in open source projects. The
developed their _own_ version of WINE to get Word Perfect Office out
the door, and they say they will merge their changes in "later" to
main WINE distribution. Their WINE source is accessible, though.
Actually, I think you might be looking at this wrong ... figure that Corel
is putting resources into making WINE a viable "engine" to running
Micro$loth applications ... WINE is open source.
Now, which is better/easier? Re-code Wordperfect Office (one app) to run
natively, or improve an open source application so that Linux/Unix can run
any existing Micro$loth product? Which is cheaper in the long run?
If they were starting WordPerfect from scratch, okay ... but how many
hundreds of thousands of lines of Windoze specific code is in
WP-Office? :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Tue Feb 15 16:24: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 QAA77998
for <pgsql-hackers@postgresql.org>;
Tue, 15 Feb 2000 16:23:36 -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
QAA14970;
Tue, 15 Feb 2000 16:18:31 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002152118.QAA14970@candle.pha.pa.us>
Subject: Re: [HACKERS] Most Advanced
In-Reply-To: <Pine.BSF.4.21.0002151707590.74045-100000@thelab.hub.org> from
The
Hermit Hacker at "Feb 15, 2000 05:12:17 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Tue, 15 Feb 2000 16:18:31 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>, Lamar Owen <lamar.owen@wgcr.org>,
Jeff MacDonald <jeff@pgsql.com>, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Actually, I think you might be looking at this wrong ... figure that Corel
is putting resources into making WINE a viable "engine" to running
Micro$loth applications ... WINE is open source.Now, which is better/easier? Re-code Wordperfect Office (one app) to run
natively, or improve an open source application so that Linux/Unix can run
any existing Micro$loth product? Which is cheaper in the long run?If they were starting WordPerfect from scratch, okay ... but how many
hundreds of thousands of lines of Windoze specific code is in
WP-Office? :)
I have never been very confident about emulation of any form. Also, if
Corel has Inprise and Corel Linux, you would think it would be worth
making the port to a _real_ operating system.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 15 16:30:12 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 QAA78677;
Tue, 15 Feb 2000 16:29:52 -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 QAA24031;
Tue, 15 Feb 2000 16:29:25 -0500 (EST)
To: Mike Mascari <mascarm@mascari.com>
cc: Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] function question yet again
In-reply-to: <38A96C2F.6796050A@mascari.com>
References: <20000215131439.A2553@fam-meskes.de>
<38A91179.AB924F0A@mascari.com>
<20000215152620.A11746@fam-meskes.de>
<38A96C2F.6796050A@mascari.com>
Comments: In-reply-to Mike Mascari <mascarm@mascari.com>
message dated "Tue, 15 Feb 2000 10:09:35 -0500"
Date: Tue, 15 Feb 2000 16:29:25 -0500
Message-ID: <24028.950650165@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Mike Mascari <mascarm@mascari.com> writes:
Wow. I'm not quite sure why it shouldn't work, but I've never
reconnected on the server side through libpq. Instead, I've
always used the SPI interface sequence of:
SPI_connect()
SPI_exec()
SPI_getvalue()
SPI_finish()
SPI is the recommended interface for server-side addon code, I think.
I think I've tried in the past to reconnect on the server side
through libpq but it always resulted in a core dump of the
running backend.
Bear in mind that libpq is not present in the backend. If you load
a library containing your code + libpq and then try to do something
via libpq, what will happen is that libpq will contact the postmaster,
fire up a new backend, and send all your queries to that other backend.
Probably not quite what you had in mind, and I could imagine it leading
to deadlock problems against your own backend. (But I don't see why it
would cause the particular error Michael is complaining of; that still
looks like it might be a newline-versus-carriage-return kind of bug.)
I believe that long ago, there was code in the backend that presented
a libpq-equivalent interface for queries originating from loaded
libraries, but that facility hasn't been maintained and probably
doesn't work at all anymore.
regards, tom lane
From bouncefilter Tue Feb 15 16:39:12 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 QAA79663
for <pgsql-hackers@postgresql.org>;
Tue, 15 Feb 2000 16:39:06 -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 QAA05402;
Tue, 15 Feb 2000 16:37:34 -0500
Message-ID: <38A9C715.65C0DA7D@wgcr.org>
Date: Tue, 15 Feb 2000 16:37:25 -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] Interbase
References: <200002152109.QAA14889@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
While we are behind some commercial databases, our
improvement speed is far better than theirs, so we will overtake them
sometime in the future.
And this, Bruce, is where the PostgreSQL RDBMS truly is the "Most
Advanced Open Source RDBMS."
In chronology, 6.1.1 wasn't too long ago. In features, 6.1.1 was _eons_
ago. I know -- I used 6.1.1. And 6.2.1. And 6.3.2. Now 6.5.3. Soon
7.0. (I never did put 6.4.2 in production -- the RPM lag factor meant
that 6.5beta was available while the shipping RPM's were still 6.3.2 for
RedHat users.)
And now we have developers that are _very_ familiar with the guts of
PostgreSQL -- it will take people at least a year or more to get up to
speed on Interbase.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Tue Feb 15 16:42:09 2000
Received: from mythos.jpl.nasa.gov (mythos.jpl.nasa.gov [137.78.15.110])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA79952
for <hackers@postgreSQL.org>; Tue, 15 Feb 2000 16:41:39 -0500 (EST)
(envelope-from Thomas.G.Lockhart@jpl.nasa.gov)
Received: from jpl.nasa.gov (localhost [127.0.0.1])
by mythos.jpl.nasa.gov (8.8.7/8.8.7) with ESMTP id VAA28235;
Tue, 15 Feb 2000 21:38:25 GMT
Sender: lockhart@mythos.jpl.nasa.gov
Message-ID: <38A9C751.7365FA7@jpl.nasa.gov>
Date: Tue, 15 Feb 2000 21:38:25 +0000
From: Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
Organization: Caltech/JPL
X-Mailer: Mozilla 4.7 [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: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Almost there on column aliases
References: <38A3A7DB.6A684EF@alumni.caltech.edu>
<18707.950251267@sss.pgh.pa.us>
<38A3B745.E720A4AC@alumni.caltech.edu>
<18803.950253638@sss.pgh.pa.us>
<38A432D2.D6998E5B@alumni.caltech.edu>
<19051.950545044@sss.pgh.pa.us>
<38A8368B.68AF6CDA@alumni.caltech.edu>
<22598.950555491@sss.pgh.pa.us>
<38A8C61D.90557A4B@alumni.caltech.edu>
<23664.950648530@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Ah-hah, I see it. nodeRead() expects that simple Value objects
(T_Integer, T_Float, T_String) will be output without any '{' ... '}'
wrapping. _outNode() was putting them out with wrapping. Apparently,
you're the first person in a long time (maybe forever) to try to dump
and reload node structures in which these node types appear outside
the context of a Const node. (outConst calls outValue directly, without
going through outNode, so the bug didn't appear in that case.)
I've fixed _outNode() to suppress the unwanted wrapper for a Value
and removed the now-unnecessary special-case code for Attr lists.
Great. Thanks. And I should have committed my garbage earlier rather
than trying to make it work poorly ;)
BTW, the rule regress test is presently failing because I modified
ruleutils.c to dump the Attr list if it is not null, rather than
only if the refname is different from the relname:*** 992,1008 **** quote_identifier(rte->relname), inherit_marker(rte)); if (strcmp(rte->relname, rte->ref->relname) != 0) - { - List *col; appendStringInfo(buf, " %s", quote_identifier(rte->ref->relname)); appendStringInfo(buf, " ("); ! foreach (col, rte->ref->attrs) { ! if (col != lfirst(rte->ref->attrs)) appendStringInfo(buf, ", "); ! appendStringInfo(buf, "%s", strVal(col)); } } } } --- 992,1012 ---- quote_identifier(rte->relname), inherit_marker(rte)); if (strcmp(rte->relname, rte->ref->relname) != 0) appendStringInfo(buf, " %s", quote_identifier(rte->ref->relname)); + if (rte->ref->attrs != NIL) + { + List *col; + appendStringInfo(buf, " ("); ! foreach(col, rte->ref->attrs) { ! if (col != rte->ref->attrs) appendStringInfo(buf, ", "); ! appendStringInfo(buf, "%s", ! quote_identifier(strVal(lfirst(col)))); } + appendStringInfo(buf, ")"); } } }
istm that the column aliases (rte->ref->attrs) should not be written out
if the table alias (rte->ref->relname) is not written. And the rules
regression test should be failing anyway, because I didn't update it
since I knew that there was something wrong with those plan strings and
I didn't want to hide that.
While this seems like appropriate logic, a bunch of the rule tests are
now showing long and perfectly content-free lists of attribute names in
reverse-listed FROM clauses. This bothers me because it implies that
those names are being stored in the querytree that's dumped out to
pg_rewrite, which will be a further crimp in people's ability to write
complex rules. I think we really don't want to store those nodes if we
don't have to. Why are we building Attr lists when there's no actual
column aliasing being done?
Hmm. Because there are multiple places in the parser which needs to get
at a column name. When handling column aliases, I was having to look up
the actual column names anyway to verify that there were the correct
number of aliases specified (actually, I decided to allow any number of
aliases <= the number of actual columns, filling in with the underlying
column names if an alias was not specified) and so while I had the info
I cached it into the RTE structure for later use.
If I make the ref structure optional, then I have to start returning
lists of columns when working out the new join syntax, and I hated to
keep generating a bunch of temporary lists of things. Also, by making
the ref->refname non-optional in the structure, I could stop checking
for its existance before using either it *or* the true table name; this
cleaned up a bit of the code.
- Thomas
--
Thomas Lockhart
Caltech/JPL
Interferometry Systems and Technology
From bouncefilter Tue Feb 15 17:01: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 RAA86482
for <pgsql-hackers@postgresql.org>;
Tue, 15 Feb 2000 17:00:22 -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
QAA16126;
Tue, 15 Feb 2000 16:57:21 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002152157.QAA16126@candle.pha.pa.us>
Subject: Re: [HACKERS] Interbase
In-Reply-To: <38A9C715.65C0DA7D@wgcr.org> from Lamar Owen at "Feb 15,
2000 04:37:25 pm"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Tue, 15 Feb 2000 16:57:21 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
In chronology, 6.1.1 wasn't too long ago. In features, 6.1.1 was _eons_
ago. I know -- I used 6.1.1. And 6.2.1. And 6.3.2. Now 6.5.3. Soon
7.0. (I never did put 6.4.2 in production -- the RPM lag factor meant
that 6.5beta was available while the shipping RPM's were still 6.3.2 for
RedHat users.)And now we have developers that are _very_ familiar with the guts of
PostgreSQL -- it will take people at least a year or more to get up to
speed on Interbase.
I have seen the MySQL code and it is clearly very hard to understand. I
can't imagine how many people _don't_ get involved because of that, and
the license.
Does MySQL have the team size we have? I don't see them progressing at
our speed.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 15 16:57:10 2000
Received: from hu.tm.ee (ppp29.tele2.ee [212.107.33.29])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA86053
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 16:56:56 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 7A27B39A1; Wed, 16 Feb 2000 00:04:54 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38A9CD86.250FF840@tm.ee>
Date: Wed, 16 Feb 2000 00:04:54 +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: The Hermit Hacker <scrappy@hub.org>, Peter Eisentraut <peter_e@gmx.net>,
Lamar Owen <lamar.owen@wgcr.org>, Jeff MacDonald <jeff@pgsql.com>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Most Advanced
References: <200002152118.QAA14970@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Actually, I think you might be looking at this wrong ... figure that Corel
is putting resources into making WINE a viable "engine" to running
Micro$loth applications ... WINE is open source.Now, which is better/easier? Re-code Wordperfect Office (one app) to run
natively, or improve an open source application so that Linux/Unix can run
any existing Micro$loth product? Which is cheaper in the long run?If they were starting WordPerfect from scratch, okay ... but how many
hundreds of thousands of lines of Windoze specific code is in
WP-Office? :)I have never been very confident about emulation of any form. Also, if
Corel has Inprise and Corel Linux, you would think it would be worth
making the port to a _real_ operating system.
AFAIIC they are just using WINE as their cross-platform toolkit, same as
Mozilla
does with theirs XPCOM (or whatever it's called;).
I don't see any of the GUI toolkits as basically better than others (though I
have used lately wxPython).
And cross-platform is important nowadays - even in my small company there are
developers using Linux,BeOS,Win32 and Macs and it is counterproductive if we
have to use some important tool that isnt available for some platform or can't
be run remotely (over http/html or X11)
---------------
Hannu
From bouncefilter Tue Feb 15 17:14:10 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 RAA88424
for <hackers@postgreSQL.org>; Tue, 15 Feb 2000 17:14:01 -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 RAA28642;
Tue, 15 Feb 2000 17:13:54 -0500 (EST)
To: Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Almost there on column aliases
In-reply-to: <38A9C751.7365FA7@jpl.nasa.gov>
References: <38A3A7DB.6A684EF@alumni.caltech.edu>
<18707.950251267@sss.pgh.pa.us>
<38A3B745.E720A4AC@alumni.caltech.edu>
<18803.950253638@sss.pgh.pa.us>
<38A432D2.D6998E5B@alumni.caltech.edu>
<19051.950545044@sss.pgh.pa.us>
<38A8368B.68AF6CDA@alumni.caltech.edu>
<22598.950555491@sss.pgh.pa.us>
<38A8C61D.90557A4B@alumni.caltech.edu>
<23664.950648530@sss.pgh.pa.us> <38A9C751.7365FA7@jpl.nasa.gov>
Comments: In-reply-to Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
message dated "Tue, 15 Feb 2000 21:38:25 +0000"
Date: Tue, 15 Feb 2000 17:13:54 -0500
Message-ID: <28639.950652834@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
BTW, the rule regress test is presently failing because I modified
ruleutils.c to dump the Attr list if it is not null, rather than
only if the refname is different from the relname:
istm that the column aliases (rte->ref->attrs) should not be written out
if the table alias (rte->ref->relname) is not written.
Hmm. If it's not possible to specify column aliases without specifying
a table-name alias, then that's OK ... but I thought table aliases were
optional.
And the rules
regression test should be failing anyway, because I didn't update it
since I knew that there was something wrong with those plan strings and
I didn't want to hide that.
The weird thing is that I'm pretty sure the rules test was *passing*
(against the present expected file) last night after I made the change
I just quoted. It wasn't till after I changed the readfuncs/outfuncs
stuff this morning that I started seeing the long lists of column names
in the rules output.
OTOH, "last night" was about 3AM and I was tired. Maybe I remember it
wrong.
While this seems like appropriate logic, a bunch of the rule tests are
now showing long and perfectly content-free lists of attribute names in
reverse-listed FROM clauses. This bothers me because it implies that
those names are being stored in the querytree that's dumped out to
pg_rewrite, which will be a further crimp in people's ability to write
complex rules. I think we really don't want to store those nodes if we
don't have to. Why are we building Attr lists when there's no actual
column aliasing being done?
Hmm. Because there are multiple places in the parser which needs to get
at a column name. When handling column aliases, I was having to look up
the actual column names anyway to verify that there were the correct
number of aliases specified (actually, I decided to allow any number of
aliases <= the number of actual columns, filling in with the underlying
column names if an alias was not specified) and so while I had the info
I cached it into the RTE structure for later use.
Fair enough, but we don't need those column names any more after the
parse/analyze phase completes, right? Maybe we could remove the lists
at that time, or at least do so before writing out rule querytrees.
Since we aren't going to have TOAST in 7.0, I'm concerned that the
rule representation not get any more verbose than it is already...
regards, tom lane
From bouncefilter Tue Feb 15 16:56:09 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA85934
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 16:56:06 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id OAA04565;
Tue, 15 Feb 2000 14:23:53 -0800 (PST)
Date: Tue, 15 Feb 2000 14:23:53 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Jeff MacDonald <jeff@pgsql.com>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Most Advanced
Message-ID: <20000215142353.N17536@fw.wintelcom.net>
References: <Pine.BSF.4.10.10002151041030.10395-100000@rage.hub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Pine.BSF.4.10.10002151041030.10395-100000@rage.hub.org>;
from jeffm@pgsql.com on Tue, Feb 15, 2000 at 10:42:10AM -0400
* Jeff MacDonald <jeff@pgsql.com> <jeffm@pgsql.com> [000215 07:33] wrote:
Hi,
For PostgreSQL We tend to use the Phrase
"Most Advanced Open Source RDBMS" alot.Will this statement still hold true when/if
Inprise becomes open source ?
Depending on the license it could become
"Most Advanced Really Open Source RDBMS"
And who says that it will actually be more advanced?
-Alfred
From bouncefilter Tue Feb 15 17:52:20 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA04524
for <pgsql-hackers@postgresql.org>;
Tue, 15 Feb 2000 17:51:30 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12KqoZ-000LELC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for pgsql-hackers@postgresql.org; Tue, 15 Feb 2000 16:51:27 -0600 (CST)
Date: Tue, 15 Feb 2000 16:51:27 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Most Advanced
Message-ID: <20000215165127.A5050@rice.edu>
References: <200002152118.QAA14970@candle.pha.pa.us> <38A9CD86.250FF840@tm.ee>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <38A9CD86.250FF840@tm.ee>;
from hannu@tm.ee on Wed, Feb 16, 2000 at 12:04:54AM +0200
On Wed, Feb 16, 2000 at 12:04:54AM +0200, Hannu Krosing wrote:
Bruce Momjian wrote:
Actually, I think you might be looking at this wrong ... figure that Corel
is putting resources into making WINE a viable "engine" to running
Micro$loth applications ... WINE is open source.Now, which is better/easier? Re-code Wordperfect Office (one app) to run
natively, or improve an open source application so that Linux/Unix can run
any existing Micro$loth product? Which is cheaper in the long run?If they were starting WordPerfect from scratch, okay ... but how many
hundreds of thousands of lines of Windoze specific code is in
WP-Office? :)I have never been very confident about emulation of any form. Also, if
Corel has Inprise and Corel Linux, you would think it would be worth
making the port to a _real_ operating system.AFAIIC they are just using WINE as their cross-platform toolkit, same as
Mozilla
does with theirs XPCOM (or whatever it's called;).
I don't see any of the GUI toolkits as basically better than others (though I
have used lately wxPython).
And cross-platform is important nowadays - even in my small company there are
developers using Linux,BeOS,Win32 and Macs and it is counterproductive if we
have to use some important tool that isnt available for some platform or can't
be run remotely (over http/html or X11)
I've been following WINE development longer than PostgreSQL, so I
think I should comment on this. Hannu's exactly right: WINE Is Not
an Emulator, it's an implementation of the Win32 API on top of Unix/X
(well, mostly Linux, but they do occasionally get someone testing on
*BSD). Given that, there _is_ a second component: implementation of
the Win32 ABI. This is the wine executable that sometimes gets called
the "emulator". The API implementation requires recompiling your Win32
targeted code - this is a 'winlib' app. The wine executable knows all
about loading Windows format binaries, so you can run Windows _binaries_
directly. Such a clean distinction didn't really exist, at first. Since
_most_ Windows programs that people wanted to run where binary only,
and the idea that companies might actually recompile their code for the
Linux market (what market?) was somewhat laughed at, the WINE project
started as an ABI emulation, and only fairly recently has restructured,
to include both. The eventual goal is the the wine executable will just
be another winlib app, just like any other, it just knows how to read
a Windows binary, and do any fix-up needed.
As to Corel's work with WINE: their developers (and their contractors)
have had their own, until quite recently private, tree, but they have
been pushing patches out to the public tree on a regular basis, and
participating in design discussions on the public mailing lists. The
recent opening of their tree seems to me to have come about to alleviate
the problem of needing to push patches out, as release deadline pressures
neared. In fact, that was explicitly mentioned by one of their developers,
who invited everyone to generate patch sets and submit them to the open
tree. The use of WINE as opposed to 'native' I read as "Win32 binary"
rather than winlib, ELF binary.
Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
From bouncefilter Tue Feb 15 17:56:10 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA04935
for <pgsql-hackers@postgresql.org>;
Tue, 15 Feb 2000 17:55:50 -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 SAA86924;
Tue, 15 Feb 2000 18:55:22 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 15 Feb 2000 18:55:21 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>, Lamar Owen <lamar.owen@wgcr.org>,
Jeff MacDonald <jeff@pgsql.com>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Most Advanced
In-Reply-To: <200002152118.QAA14970@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0002151851450.74045-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 15 Feb 2000, Bruce Momjian wrote:
Actually, I think you might be looking at this wrong ... figure that Corel
is putting resources into making WINE a viable "engine" to running
Micro$loth applications ... WINE is open source.Now, which is better/easier? Re-code Wordperfect Office (one app) to run
natively, or improve an open source application so that Linux/Unix can run
any existing Micro$loth product? Which is cheaper in the long run?If they were starting WordPerfect from scratch, okay ... but how many
hundreds of thousands of lines of Windoze specific code is in
WP-Office? :)I have never been very confident about emulation of any form. Also, if
Corel has Inprise and Corel Linux, you would think it would be worth
making the port to a _real_ operating system.
I've gotten 4 Windoze users at work converted over to FreeBSD over the
past month or so, the latest one being as a result of VMWare ... now they
can run all their Windoze programs that they require without having to
dual-boot into Windoze when they need to ...
If the emulation is done well enough, the end result is a much broader set
of applications while still running a *good* operating system ... the blue
screen of death doesn't require rebooting a whole computer :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Tue Feb 15 19:02:11 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 TAA12118
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 19:01: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
SAA20764;
Tue, 15 Feb 2000 18:01:05 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002152301.SAA20764@candle.pha.pa.us>
Subject: Re: [HACKERS] Most Advanced
In-Reply-To: <20000215165127.A5050@rice.edu> from "Ross J. Reedstrom" at "Feb
15, 2000 04:51:27 pm"
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
Date: Tue, 15 Feb 2000 18:01:05 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
have had their own, until quite recently private, tree, but they have
been pushing patches out to the public tree on a regular basis, and
participating in design discussions on the public mailing lists. The
recent opening of their tree seems to me to have come about to alleviate
the problem of needing to push patches out, as release deadline pressures
neared. In fact, that was explicitly mentioned by one of their developers,
who invited everyone to generate patch sets and submit them to the open
tree. The use of WINE as opposed to 'native' I read as "Win32 binary"
rather than winlib, ELF binary.
Quite interesting. I can see a Win32 compatible library as quite handy.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 15 18:17:10 2000
Received: from mythos.jpl.nasa.gov (mythos.jpl.nasa.gov [137.78.15.110])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA06771
for <hackers@postgreSQL.org>; Tue, 15 Feb 2000 18:16:43 -0500 (EST)
(envelope-from Thomas.G.Lockhart@jpl.nasa.gov)
Received: from jpl.nasa.gov (localhost [127.0.0.1])
by mythos.jpl.nasa.gov (8.8.7/8.8.7) with ESMTP id XAA28408;
Tue, 15 Feb 2000 23:15:01 GMT
Sender: lockhart@mythos.jpl.nasa.gov
Message-ID: <38A9DDF5.10482FE9@jpl.nasa.gov>
Date: Tue, 15 Feb 2000 23:15:01 +0000
From: Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
Organization: Caltech/JPL
X-Mailer: Mozilla 4.7 [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: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Almost there on column aliases
References: <38A3A7DB.6A684EF@alumni.caltech.edu>
<18707.950251267@sss.pgh.pa.us>
<38A3B745.E720A4AC@alumni.caltech.edu>
<18803.950253638@sss.pgh.pa.us>
<38A432D2.D6998E5B@alumni.caltech.edu>
<19051.950545044@sss.pgh.pa.us>
<38A8368B.68AF6CDA@alumni.caltech.edu>
<22598.950555491@sss.pgh.pa.us>
<38A8C61D.90557A4B@alumni.caltech.edu>
<23664.950648530@sss.pgh.pa.us> <38A9C751.7365FA7@jpl.nasa.gov>
<28639.950652834@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
istm that the column aliases (rte->ref->attrs) should not be written out
if the table alias (rte->ref->relname) is not written.Hmm. If it's not possible to specify column aliases without specifying
a table-name alias, then that's OK ... but I thought table aliases were
optional.
I don't think so (ie a table alias is required if a column alias is
specified), but my SQL books are at home so I can't verify my
recollection.
Fair enough, but we don't need those column names any more after the
parse/analyze phase completes, right? Maybe we could remove the lists
at that time, or at least do so before writing out rule querytrees.
Possibly. I'm transforming the qualifications on the join clause as the
join clause is transformed (rather than later during the WHERE
transformation) in the hope that the column (and table) names will have
been replaced by attribute numbers and RTE indices. If that is the case,
and if the "correlation names" or aliases are never needed after that,
then we can drop 'em.
Except that we'll possibly need them to get a valid pg_dump of the
rules? Or is an untransformed copy of the original definition kept
around someplace??
Since we aren't going to have TOAST in 7.0, I'm concerned that the
rule representation not get any more verbose than it is already...
Right.
- Thomas
--
Thomas Lockhart
Caltech/JPL
Interferometry Systems and Technology
From bouncefilter Tue Feb 15 18:59:11 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 SAA11606
for <hackers@postgreSQL.org>; Tue, 15 Feb 2000 18:58:30 -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 SAA29208;
Tue, 15 Feb 2000 18:58:05 -0500 (EST)
To: Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Almost there on column aliases
In-reply-to: <38A9DDF5.10482FE9@jpl.nasa.gov>
References: <38A3A7DB.6A684EF@alumni.caltech.edu>
<18707.950251267@sss.pgh.pa.us>
<38A3B745.E720A4AC@alumni.caltech.edu>
<18803.950253638@sss.pgh.pa.us>
<38A432D2.D6998E5B@alumni.caltech.edu>
<19051.950545044@sss.pgh.pa.us>
<38A8368B.68AF6CDA@alumni.caltech.edu>
<22598.950555491@sss.pgh.pa.us>
<38A8C61D.90557A4B@alumni.caltech.edu>
<23664.950648530@sss.pgh.pa.us> <38A9C751.7365FA7@jpl.nasa.gov>
<28639.950652834@sss.pgh.pa.us> <38A9DDF5.10482FE9@jpl.nasa.gov>
Comments: In-reply-to Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
message dated "Tue, 15 Feb 2000 23:15:01 +0000"
Date: Tue, 15 Feb 2000 18:58:05 -0500
Message-ID: <29205.950659085@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov> writes:
Fair enough, but we don't need those column names any more after the
parse/analyze phase completes, right? Maybe we could remove the lists
at that time, or at least do so before writing out rule querytrees.
Except that we'll possibly need them to get a valid pg_dump of the
rules? Or is an untransformed copy of the original definition kept
around someplace??
As far as I can tell without having tried it, you'd still get a correct
dump, although it might look different from the original query because
columns would be referred to by their untransformed names (but that'll
happen anyway, unless you go back and change ruleutil.c's way of looking
up column names). For example, with current sources:
regression=# create view qq as select a from tenk1 t1 (a);
CREATE 276745 1
regression=# \d qq
View "qq"
Attribute | Type | Modifier
-----------+---------+----------
a | integer |
View definition: SELECT t1.unique1 AS a FROM tenk1 t1 (a, unique2, two, four, ten, twenty, hundred, thousand, twothousand, fivethous, tenthous, odd, even, stringu1, stringu2, string4);
The only "external" view of the alias is as the column title, and notice
that that's getting enforced by an AS clause independently of any
aliases. (In the querytree, that title is coming from a refname in the
targetlist entry --- we don't need another copy in the RTE to make it
work.)
BTW, I'm practically certain that I tried this same example last night
and got a rule dump of just
SELECT t1.unique1 AS a FROM tenk1 t1 (a);
which is more like what I would expect. Did you change the behavior
w.r.t. adding additional columns to the alias list just recently, like
since 11PM EST yesterday?
regards, tom lane
PS: Am I the only one who thinks that column aliases done this way are
extremely brain-dead? If you write "FROM table alias (a b c)" then
you've just written a query that depends critically and non-obviously
on which columns are first, second, third in the physical table.
One of the few things I know about good SQL style is that you don't
write INSERT without an explicit column list, because such code will
break (possibly without warning) if you insert/delete/rearrange columns
in the table definition. This alias facility seems to be just another
method of shooting yourself in the foot with that same bullet...
From bouncefilter Tue Feb 15 19:40:11 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA23370
for <hackers@postgresql.org>; Tue, 15 Feb 2000 19:40:04 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12KsVZ-000LELC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for hackers@postgresql.org; Tue, 15 Feb 2000 18:39:57 -0600 (CST)
Date: Tue, 15 Feb 2000 18:39:57 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: Postgres Hackers List <hackers@postgresql.org>
Subject: IBM sues Informix over DB patents
Message-ID: <20000215183957.A5657@rice.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
Anyone see this little news item? It showed up in my
paper copy of InfoWorld today.
http://www.infoworld.com/articles/hn/xml/00/02/14/000214hnpatent.xml
It caught my eye, and I'm forwarding it here, since Informix's Universal
DB now incorporates the old Illustra code. Since stepping on patents
has always been one of the open source software nightmare scenarios,
it's be nice to know which patents are involved.
(BTW, I was checking out Informix's DataBlade technology: turns out it's
just like pgsql's user extensible types and functions, with pretty PR
and training tools - and a little better integration packaging. The basic
API is so similar, I woudn't be suprised if it's a direct descendant)
Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
From bouncefilter Tue Feb 15 19:50:12 2000
Received: from mythos.jpl.nasa.gov (mythos.jpl.nasa.gov [137.78.15.110])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA24000
for <hackers@postgreSQL.org>; Tue, 15 Feb 2000 19:49:24 -0500 (EST)
(envelope-from Thomas.G.Lockhart@jpl.nasa.gov)
Received: from jpl.nasa.gov (localhost [127.0.0.1])
by mythos.jpl.nasa.gov (8.8.7/8.8.7) with ESMTP id AAA28531;
Wed, 16 Feb 2000 00:46:13 GMT
Sender: lockhart@mythos.jpl.nasa.gov
Message-ID: <38A9F355.31CB349B@jpl.nasa.gov>
Date: Wed, 16 Feb 2000 00:46:13 +0000
From: Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
Organization: Caltech/JPL
X-Mailer: Mozilla 4.7 [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: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Almost there on column aliases
References: <38A3A7DB.6A684EF@alumni.caltech.edu>
<18707.950251267@sss.pgh.pa.us>
<38A3B745.E720A4AC@alumni.caltech.edu>
<18803.950253638@sss.pgh.pa.us>
<38A432D2.D6998E5B@alumni.caltech.edu>
<19051.950545044@sss.pgh.pa.us>
<38A8368B.68AF6CDA@alumni.caltech.edu>
<22598.950555491@sss.pgh.pa.us>
<38A8C61D.90557A4B@alumni.caltech.edu>
<23664.950648530@sss.pgh.pa.us> <38A9C751.7365FA7@jpl.nasa.gov>
<28639.950652834@sss.pgh.pa.us> <38A9DDF5.10482FE9@jpl.nasa.gov>
<29205.950659085@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Except that we'll possibly need them to get a valid pg_dump of the
rules? Or is an untransformed copy of the original definition kept
around someplace??As far as I can tell without having tried it, you'd still get a correct
dump, although it might look different from the original query because
columns would be referred to by their untransformed names (but that'll
happen anyway, unless you go back and change ruleutil.c's way of looking
up column names). For example, with current sources:
View definition: SELECT t1.unique1 AS a
FROM tenk1 t1 (a, unique2, two, four, ten, twenty, hundred,
thousand, twothousand, fivethous, tenthous, odd, even, stringu1, stringu2, string4);
The only "external" view of the alias is as the column title, and notice
that that's getting enforced by an AS clause independently of any
aliases. (In the querytree, that title is coming from a refname in the
targetlist entry --- we don't need another copy in the RTE to make it
work.)
Well, there are other queries which *do* rely on the column aliases:
select a, b from t1 ta (a, b, c) natural join t2 tb (a, d);
where the column in the target list called "a" is not allowed to have an
explicit reference to a table name. That is, neither
select t1.a, b from t1 ta (a, b, c) natural join t2 tb (a, d);
nor
select t2.a, b from t1 ta (a, b, c) natural join t2 tb (a, d);
are legal SQL, but, for example,
select a, ta.b from t1 ta (a, b, c) natural join t2 tb (a, d);
is. Not sure how this impacts the rule representation or dump/reload of
views.
BTW, I'm practically certain that I tried this same example last night
which is more like what I would expect. Did you change the behavior
w.r.t. adding additional columns to the alias list just recently, like
since 11PM EST yesterday?
Yeah right ;)
I've only committed one set of patches; don't remember what time that
was...
PS: Am I the only one who thinks that column aliases done this way are
extremely brain-dead? If you write "FROM table alias (a b c)" then
you've just written a query that depends critically and non-obviously
on which columns are first, second, third in the physical table.
One of the few things I know about good SQL style is that you don't
write INSERT without an explicit column list, because such code will
break (possibly without warning) if you insert/delete/rearrange columns
in the table definition. This alias facility seems to be just another
method of shooting yourself in the foot with that same bullet...
It's required for doing complex join syntax, and is allowed for other
joins as well. But we certainly have got along just fine without it, eh?
- Thomas
--
Thomas Lockhart
Caltech/JPL
Interferometry Systems and Technology
From bouncefilter Tue Feb 15 22:02:13 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 WAA42635
for <pgsql-hackers@postgreSQL.org>;
Tue, 15 Feb 2000 22:01: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 DAA08288;
Wed, 16 Feb 2000 03:05:59 GMT
Sender: lockhart@hub.org
Message-ID: <38AA1417.CDAB7D23@alumni.caltech.edu>
Date: Wed, 16 Feb 2000 03:05: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: Tom Lane <tgl@sss.pgh.pa.us>
CC: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Release on the 15th?
References: <Pine.BSF.4.21.0002142118590.74045-100000@thelab.hub.org>
<2179.950596381@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I think I can do Monday, but I don't know where Thomas is. Doesn't
he still want to squeeze in the date/time type consolidation?
I'm building to test now. And will be out of town from this weekend
through the next (9 days). I should be able to get the datetime stuff
and Jan's parser stuff done beforehand...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Tue Feb 15 22:05:12 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 WAA42995
for <hackers@postgreSQL.org>; Tue, 15 Feb 2000 22:05:08 -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 DAA08659;
Wed, 16 Feb 2000 03:09:27 GMT
Sender: lockhart@hub.org
Message-ID: <38AA14E7.310C2FB1@alumni.caltech.edu>
Date: Wed, 16 Feb 2000 03:09: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: Tom Lane <tgl@sss.pgh.pa.us>, Oleg Bartunov <oleg@sai.msu.su>
CC: hackers@postgreSQL.org
Subject: Re: [HACKERS] ERROR: copyObject: don't know how to copy 1381319466
References: <Pine.GSO.3.96.SK.1000215140237.16880A-100000@ra>
<12126.950630282@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Do I need initdb ? postamster started normally
Probably --- I recall Thomas muttering yesterday that he needed an
initdb himself. FWIW, I got fairly clean regress results from a
CVS pull of about 1AM (6AM GMT) this morning ... but I did initdb.
Sorry, yes, and I should have announce it.
No catversion.h update to force initdb though. Naughty naughty,
Thomas...
Oops. And I should have known, having been stopped dead in the water
once or twice in the last few weeks resyncing from CVS and finding
that my work in progress required an initdb due to other changes. Oh,
and finding that my parser was so broken that initdb wouldn't run. Fun
fun fun ;)
Anyway, istm to be a mixed blessing during pre-beta, but I didn't
intentionally subvert it...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Tue Feb 15 23:03:15 2000
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA49587
for <pgsql-hackers@postgresql.org>;
Tue, 15 Feb 2000 23:03:10 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.34.146]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Tue, 15 Feb 2000 22:03:48 -0600
Sender: ed
Message-ID: <38AA2204.5FD74243@austin.rr.com>
Date: Tue, 15 Feb 2000 22:05:24 -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: pghackers <pgsql-hackers@postgresql.org>
Subject: vnunet.com Inprise/Borland spins off Interbase database as separate
company
Content-Type: multipart/mixed; boundary="------------C7710D4F4C3C67CBE57FD184"
This is a multi-part message in MIME format.
--------------C7710D4F4C3C67CBE57FD184
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Forgive me if you've seen this, but thought it'd be interesting to
some given the recent discussion of Interbase...
http://www.vnunet.com/News/106540
--------------C7710D4F4C3C67CBE57FD184
Content-Type: text/html; charset=iso-8859-1;
name="106540"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
filename="106540"
Content-Base: "http://www.vnunet.com/News/106540"
Content-Location: "http://www.vnunet.com/News/106540"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!-- *****************************************************************
* =A91999 VNU Business Publishing Limited [All rights reserved]
*
* This page is the vnunet.com/news page.
*
* Author Designer Darrell Kingsley
* Developer Vipul Solanki
*
* Version 1.00 26 October 1999
*
*****************************************************************-->=
<HTML>
<HEAD>
<TITLE>vnunet.com Inprise/Borland spins off Interbase database as separat=
e company</TITLE>
<META NAME=3D"keywords" CONTENT=3D"fuller, inprise, borland, interim, chi=
ef, executive, combining, interbase, technology, experienced, management,=
team, startup, environment, enabling, users, leverage, power, world, cla=
ss, database, multiple, platforms, firm, cash, venture, million, fund, an=
nounced, january, invest, startups, developing, applications, linux, inte=
rnet, wireless, technology, interbase, company, headed, ann, harrison, fo=
unders, original, interbase, taken, borland, paul, beach, uk, remain, bec=
ome, vice, president, sales, back, january, inprise, borland, announced, =
upcoming, release, version, support, two, operating, environments, linux,=
sun, microsystems, solaris, top, traditional, microsoft, windows, novell=
, netware, platforms, company, release, interbase, source, code, open, so=
urce, community, joint, founder, depalma, expressed, concern, open, sourc=
e, plan, complexity, interbase, claimed, really, non, experts, mucking, i=
nprise, borland, spins, interbase, database, separate, company, inprise, =
borland, teaming, range, unnamed, venture, capitalist, organisations, fun=
d, spinoff, company, house, interbase, database, inprise, borland, teamin=
g, range, unnamed, venture, capitalist, organisations, fund, spinoff, com=
pany, house, interbase, database, move, latest, long, succession, spinoff=
s, development, tools, supplier, date, ended, rolling, former, subsidiari=
es, back, core, business, corel, announced, plans, inprise, borland, dale=
">
<META NAME=3D"description" CONTENT=3D"Inprise/Borland is teaming with a r=
ange of unnamed venture capitalist organisations to fund the spinoff of a=
new company to house its Interbase database." >
<LINK REL=3D"stylesheet" TYPE=3D"text/css" HREF=3D"http://www2.vnu.co.uk/=
v5_style/main.css">
</HEAD>
<BODY BGCOLOR=3D"#FFFFFF" TEXT=3D"#00006F" LINK=3D"#00006F" VLINK=3D"#455=
050" ALINK=3D"#438787">
<CENTER>
<!-- ** VNUNET TOP TABLE ** -->
<TABLE CELLPADDING=3D0 CELLSPACING=3D0 WIDTH=3D720 BORDER=3D0>
<TR>
<!-- ** VNUNET DATE BAR ** -->
<TD COLSPAN=3D2 HEIGHT=3D16 BGCOLOR=3D"#003396">
<FONT SIZE=3D"1" FACE=3D"Verdana" COLOR=3D"#FFFFFF"><B> Wednesday 1=
6 February 2000</B> | 04:02 AM GMT<BR></FONT>
</TD>
</TR>
<TR>
<TD WIDTH=3D120 BGCOLOR=3D"#697DFF" VALIGN=3D"TOP">
<!-- L O G O -->
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gi=
f" WIDTH=3D1 HEIGHT=3D6 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
<CENTER><A HREF=3D"http://www.vnunet.com" TARGET=3D"_top"><IMG SRC=3D"htt=
p://www2.vnu.co.uk/v5_image/v5_logo_01x.gif" WIDTH=3D110 HEIGHT=3D83 BORD=
ER=3D0 ALT=3D"vnunet.com"></A></CENTER>
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gi=
f" WIDTH=3D1 HEIGHT=3D20 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
</TD>
<TD VALIGN=3D"TOP" WIDTH=3D600>
<!-- VNUNET GRAD + SEARCH -->
<TABLE CELLPADDING=3D0 CELLSPACING=3D0 WIDTH=3D600 BORDER=3D0 BGCOLOR=3D=
"#FFFFFF" VALIGN=3D"TOP">
<TR>
<TD COLSPAN=3D"4">
<TABLE CELLPADDING=3D0 CELLSPACING=3D0 WIDTH=3D600 BORDER=3D0>
<TR>
<TD WIDTH=3D40 HEIGHT=3D46 VALIGN=3D"TOP" ALIGN=3D"LEFT">
<IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v5_grad_0.jpg" WIDTH=3D31 HE=
IGHT=3D47 BORDER=3D0 ALT=3D""></TD>
<TD WIDTH=3D560 HEIGHT=3D46 VALIGN=3D"TOP" ALIGN=3D"LEFT">
<!-- SEARCH -->
<TABLE WIDTH=3D100% CELLPADDING=3D"0" CELLSPACING=3D"0" BORDER=3D"0" V=
ALIGN=3D"TOP">
<TR>
<TD WIDTH=3D375 VALIGN=3D"TOP" ROWSPAN=3D1>
<BR><FONT SIZE=3D2 FACE=3D"Arial, Verdana, Helvetica" COLOR=3D"#697DF=
F"> <B>your computer connection</B><BR></FONT>
</TD>
<TD WIDTH=3D5 ROWSPAN=3D1>
</TD>
<TD>
<TABLE WIDTH=3D240 CELLPADDING=3D0 CELLSPACING=3D0 BORDER=3D0>
<TR>
<TD ALIGN=3DRIGHT COLSPAN=3D"2">
<FONT SIZE=3D1 FACE=3D"Verdana, Arial, Helvetica" COLOR=3D"#798DFF"><=
B>Search vnunet <A HREF=3D"/Search"><I>Power search»</I>=
</A> <A HREF=3D"/Search"><I>Help»</I></A></B><BR></FONT>
</TD>
</TR>
<TR>
<TD COLSPAN=3D"2">
<IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gif" WIDTH=3D=
10 HEIGHT=3D5 BORDER=3D0 HSPACE=3D0 VSPACE=3D0 ALT=3D"SPACED OUT!"><BR>
</TD>
</TR>
<TR>
<TD WIDTH=3D163 ALIGN=3DRIGHT VALIGN=3D"TOP">
<FORM ACTION=3D"/SearchResult" METHOD=3D"POST">
<INPUT TYPE=3D"TEXT" NAME=3D"searchTerm" SIZE=3D"18" MAXLENGTH=3D"70"=
</TD>
<TD WIDTH=3D77 ALIGN=3DRIGHT VALIGN=3D"TOP">
<INPUT TYPE=3D"IMAGE" SRC=3D"http://www2.vnu.co.uk/v5_image/sundries/=
v_search_go4.gif" BORDER=3D"0" NAME=3D"submit" VALUE=3D"Go">
</TD>
</FORM>
</TR>
</TABLE>
</TD>
</TR>
</TABLE>
</TD>
</TR>
</TABLE>
</TD>
</TR>
<!-- VNUNET AD BANNER TOP -->
<TR>
<TD WIDTH=3D"15">
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.g=
if" WIDTH=3D15 HEIGHT=3D3 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
</TD>
<TD HEIGHT=3D60>
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.g=
if" WIDTH=3D1 HEIGHT=3D3 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
<A HREF=3D"http://VNU.eu-adcenter.net/click.ng/section=3DNews&id=3D=
-512293054&site=3Dvnunet&pageposition=3Dtop" TARGET=3D"_blank">
<IMG WIDTH=3D468 HEIGHT=3D60 border=3D0 SRC=3D"http://VNU.eu-adce=
nter.net/image.ng/section=3DNews&id=3D-512293054&site=3Dvnunet&pagepositi=
on=3Dtop"></A> </TD>
<TD WIDTH=3D"15">
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.g=
if" WIDTH=3D15 HEIGHT=3D3 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
</TD>
<TD WIDTH=3D"102">
<IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gif" WIDTH=3D1 H=
EIGHT=3D3 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
<A HREF=3D"/Register"><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/home/v5=
_hp_reg_0.gif" WIDTH=3D102 HEIGHT=3D60 BORDER=3D0 ALT=3D"REGISTER NOW"></=
A>
</TD>
</TR>
<TR>
<TD VALIGN=3D"TOP" BGCOLOR=3D"#000000" COLSPAN=3D"4">
<!-- VNUNET 3 CHANNEL BOXES -->
<TABLE CELLPADDING=3D1 CELLSPACING=3D6 WIDTH=3D100% BORDER=3D0 VALIGN=
=3D"TOP">
<TR><TD BGCOLOR=3D"#1C184F" ALIGN=3D"CENTER" VALIGN=3D"MIDDLE">
<A HREF=3D"http://thebusiness.vnunet.com">
<FONT SIZE=3D1 FACE=3D"Verdana, Arial, Helvetica" COLOR=3D"#FFFFFF"=
<B>T H E B U S I N E S S <I>home</I></B> »<BR></FONT><=
/A>
</TD>
<TD BGCOLOR=3D"#FFEA00" ALIGN=3D"CENTER" VALIGN=3D"MIDDLE">
<A HREF=3D"http://theconnection.vnunet.com">
<FONT SIZE=3D1 FACE=3D"Verdana, Arial, Helvetica" COLOR=3D"#FF0000"=
<B>T H E C O N N E C T I O N <I>home</I></B> »<BR></FO=
NT></A>
</TD>
<TD BGCOLOR=3D"#B7233F" ALIGN=3D"CENTER" VALIGN=3D"MIDDLE">
<A HREF=3D"http://thechannel.vnunet.com">
<FONT SIZE=3D1 FACE=3D"Verdana, Arial, Helvetica" COLOR=3D"#FFFFFF"=
<B>T H E C H A N N E L <I>home</I></B> »<BR></FONT></A=
</TD></TR>
</TABLE>
</TD>
</TR>
</TABLE>
=
</TD>
</TR> =
</TABLE>
<!-- ** END OF TOP CHUNK ** -->
<!-- ** VNUNET MIDDLE CHUNK ** -->
<!-- ** LEFT COLUMN NAVIGATION ** -->
<SCRIPT LANGUAGE=3D"JavaScript" SRC=3D"http://www2.vnu.co.uk/v5_scripts/n=
avbar2.js"></SCRIPT>
<TD WIDTH=3D4 BGCOLOR=3D"#697DFF">
<IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gif" WIDTH=3D4 HE=
IGHT=3D1 BORDER=3D0 HSPACE=3D0 VSPACE=3D0 ALT=3D"SPACED OUT!">
</TD>
<TD VALIGN=3D"TOP">
<!-- ** STRAPS ** -->
<TABLE CELLPADDING=3D0 CELLSPACING=3D0 WIDTH=3D600 BORDER=3D0 VAL=
IGN=3D"TOP" HEIGHT=3D18>
<TR>
<TD VALIGN=3D"MIDDLE" BGCOLOR=3D"#A50055" WIDTH=3D330>
<FONT SIZE=3D1 FACE=3D"Verdana, Arial, Helvetica" COLOR=3D"#FFFFF=
F"><B> <!-- news bullet --><IMG SRC=3D"http://www2=
=2Evnu.co.uk/v5_image/v5_bullet/v5_new_ic_01.gif" WIDTH=3D15 HEIGHT=3D13 =
BORDER=3D0 ALT=3D"www.vnunet.com/news">NEWS REPORT</B><BR></FONT>
</TD>
<TD BGCOLOR=3D"#A50055" WIDTH=3D120>
<!-- Java script back history -->
<A HREF=3D"javascript:history.go(-1)">
<FONT SIZE=3D1 FACE=3D"Verdana, Arial, Helvetica" COLOR=3D"#FFFFFF">=
1;<B> PREVIOUS PAGE </B><BR></FONT></A>
</TD>
<TD BGCOLOR=3D"#000000" WIDTH=3D150>
<CENTER><A HREF=3D"/News"><FONT SIZE=3D1 FACE=3D"Verdana, Arial, =
Helvetica" COLOR=3D"#FFFFFF">« <B>NEWS HOME </B></FONT><!-- news bul=
let --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v5_bullet/v5_new_ib_01.=
gif" WIDTH=3D15 HEIGHT=3D13 BORDER=3D0 ALT=3D"www.vnunet.com/news"></A><B=
R><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gif" WIDTH=3D1 =
HEIGHT=3D2 BORDER=3D0 HSPACE=3D0 VSPACE=3D0 ALT=3D"SPACED OUT!"></CENTER>=
</TD>
</TR>
</TABLE>
=
<!-- * * E D I T O R I A L S E C T I O N * * -->
=
<TABLE CELLPADDING=3D0 CELLSPACING=3D0 WIDTH=3D600 BORDER=3D0 VALIGN=3D"T=
OP" BGCOLOR=3D"#FFFFFF">
<TR>
<TD VALIGN=3D"TOP" ALIGN=3D"CENTER" WIDTH=3D"15" BACKGROUND=3D"http:/=
/www2.vnu.co.uk/v5_image/sundries/v_white_shadow_bgl.gif" HEIGHT=3D"440">=
</TD>
<!-- MIDDLE COLUMN -->
<!-- * * * * * P A G E C O N T E N T * * * * * * -->
<TD VALIGN=3D"TOP" WIDTH=3D"435">
<TABLE CELLPADDING=3D0 CELLSPACING=3D0 WIDTH=3D410 BORDER=3D0 VALIGN=3D"T=
OP">
<TR>
<TD VALIGN=3D"TOP">
<!-- Top News story -->
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gi=
f" WIDTH=3D1 HEIGHT=3D6 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
<IMG SRC=3D"http://www2.vnu.co.uk/v5_image/bull/v5_gen_b_01.gif" WIDTH=3D=
16 HEIGHT=3D14 BORDER=3D0 ALT=3D"vnunet.com/generic/arrow"><FONT SIZE=3D2=
FACE=3D"Verdana, Arial, Helvetica" COLOR=3D"#A50055"><B>Databases</B></F=
ONT><FONT SIZE=3D1 FACE=3D"Verdana, Arial, Helvetica"> »&=
nbsp;<B>John Geralds in Silicon Valley</B> [15 Feb 2000]</FONT><BR>
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gi=
f" WIDTH=3D1 HEIGHT=3D6 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
<FONT SIZE=3D4 FACE=3D"Verdana, Arial, Helvetica" COLOR=3D"#A50055">
<B>Inprise/Borland spins off Interbase database as separate company</B></=
FONT>
<BR>
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gi=
f" WIDTH=3D1 HEIGHT=3D8 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
<FONT SIZE=3D2 FACE=3D"Verdana, Arial, Helvetica">
Inprise/Borland is teaming with a range of unnamed venture capitalist org=
anisations to fund the spinoff of a new company to house its Interbase da=
tabase.<p>The move is the latest in a long succession of spinoffs by the =
development tools supplier, which has to date ended up rolling former sub=
sidiaries back into to its core business. Last week, Corel announced plan=
s to take over Inprise/Borland.<p>Dale Fuller, Inprise/Borland's interim =
chief executive, said: "By combining the Interbase technology with an exp=
erienced management team in a startup environment, we are enabling users =
to leverage the power of this world class database for multiple platforms=
=2E"<p>The firm will take some of the cash for the new venture from a $60=
million fund that it announced in January to invest in startups that are=
developing applications based on Linux, Internet and wireless technology=
=2E<p>The new Interbase company will be headed by Ann Harrison, one of th=
e founders of the original Interbase that was taken over by Borland. Paul=
Beach, who is based in the UK and will remain so, will become vice presi=
dent of sales.<p>Back in January, Inprise/Borland announced that the upco=
ming release, version 6.0, would support two more operating environments,=
Linux and Sun Microsystems' Solaris, on top of its traditional Microsoft=
Windows and Novell Netware platforms. The company also said it would rel=
ease Interbase source code to the open source community.<p>But another jo=
int founder, Don DePalma, has expressed concern at the open source plan. =
Because of the complexity of Interbase, he claimed: "You really don't wan=
t non-experts mucking about with it."<p>But the source code is scheduled =
to be available by the middle of this year. Marilee Adams, Inprise/Borlan=
d's vice president of corporate communications, said: "The licensing agre=
ement will put the users in control and that is a good thing." =
</FONT><BR>
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gi=
f" WIDTH=3D1 HEIGHT=3D20 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
<FONT SIZE=3D1 FACE=3D"Verdana, Arial, Helvetica" COLOR=3D"#A50055">
» If you would like to comment on this article email us @ <A HREF=3D=
"mailto:newseditor@vnunet.com"><B>newseditor@vnunet.com</B></A><BR></FONT=
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gi=
f" WIDTH=3D1 HEIGHT=3D20 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
<!-- related table -->
<TABLE CELLPADDING=3D0 CELLSPACING=3D2 WIDTH=3D400 BORDER=3D0 VALIGN=3D"T=
OP">
<!-- External Links -->
</TABLE>
<IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gif" WIDTH=3D1 HE=
IGHT=3D4 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
<HR WIDTH=3D"100%" SIZE=3D"1" NOSHADE COLOR=3D"#F0F0F0">
<A HREF=3D"/print/106540" TARGET=3D"NEWWIN"><IMG SRC=3D"http://www2.vnu.c=
o.uk/v5_image/sundries/v5_print_2.gif" WIDTH=3D38 HEIGHT=3D30 BORDER=3D0 =
ALT=3D"Printer friendly version of this page"></A><FONT SIZE=3D1 FACE=3D"=
Verdana, Arial, Helvetica">» <A HREF=3D"/print/106540" TARGET=3D"NEW=
WIN"><B>Printer friendly version of this story</B></A></FONT><BR>
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gi=
f" WIDTH=3D1 HEIGHT=3D6 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
<A HREF=3D"/News/Stfriend/106540"><IMG SRC=3D"http://www2=
=2Evnu.co.uk/v5_image/sundries/v5_efriend_w2.gif" WIDTH=3D38 HEIGHT=3D30 =
BORDER=3D0 ALT=3D"Email this to a friend"></A><FONT SIZE=3D1 FACE=3D"Verd=
ana, Arial, Helvetica">» <A HREF=3D"/News/Stfriend/106540"><B>Send t=
his article to a friend</B></A> </FONT><BR>
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gi=
f" WIDTH=3D1 HEIGHT=3D6 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
<FONT SIZE=3D1 FACE=3D"Verdana, Arial, Helvetica">News re=
port from » </FONT><FONT SIZE=3D1 FACE=3D"Verdana, Arial, Helvetica"=
COLOR=3D"#A50055">
<B>vnunet.com</B><BR></FONT>
<FONT SIZE=3D1 FACE=3D"Verdana, Arial, Helvetica" >Copyright <B>&co=
py; 2000 VNU Business Publishing Limited</B><BR> [All rights reserved]</F=
ONT><BR>
<HR WIDTH=3D"100%" SIZE=3D"1" NOSHADE COLOR=3D"#F0F0F0">
=
<IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.g=
if" WIDTH=3D1 HEIGHT=3D20 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
=
</TD>
</TR>
</TABLE>
=
=
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_space=
d_out.gif" WIDTH=3D1 HEIGHT=3D12 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
=
</TD>
<!-- * * * RIGHT HAND COLUMN * * * -->
<TD ROWSPAN=3D10 BGCOLOR=3D"#FFFFFF" WIDTH=3D150 VALIGN=3D"TOP" A=
LIGN=3D"RIGHT">
<!-- table start -->
<TABLE CELLPADDING=3D0 CELLSPACING=3D0 WIDTH=3D150 BORDER=3D0 VALIGN=3D"T=
OP">
<!-- the heading -->
<TR>
<TD COLSPAN=3D2>
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gi=
f" WIDTH=3D1 HEIGHT=3D6 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
<CENTER><FONT SIZE=3D1 FACE=3D"Verdana, Arial, Helvetica" COLOR=3D"#A5005=
5"><B>** LATEST **<BR>DATABASES HEADLINES<BR></B></FONT></CENTER>
</TD>
</TR>
<!-- the spacer -->
<TR><TD COLSPAN=3D2>
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gi=
f" WIDTH=3D1 HEIGHT=3D4 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
</TD></TR>
<!-- the data row -->
<TR><TD WIDTH=3D18 VALIGN=3D"TOP">
<!-- news bullet --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v5_bullet/=
v5_new_i_01.gif" WIDTH=3D16 HEIGHT=3D14 BORDER=3D0 ALT=3D"www.vnunet.com/=
news">
</TD><TD WIDTH=3D132>
<B><FONT SIZE=3D1 FACE=3D"Verdana, Arial, Helvetica">
<A HREF=3D '/News/106208' > =
First sprouts from IBM's Garlic project take root in DB2</A>
</FONT></B><BR><FONT SIZE=3D1 FACE=3D"Arial, Helvetica" COLOR=3D"#697DFF"=
[07 Feb 2000]<BR></FONT>
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gi=
f" WIDTH=3D1 HEIGHT=3D2 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
</TD></TR>
<!-- the spacer -->
<TR><TD COLSPAN=3D2>
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gi=
f" WIDTH=3D1 HEIGHT=3D4 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
</TD></TR>
<!-- the data row -->
<TR><TD WIDTH=3D18 VALIGN=3D"TOP">
<!-- news bullet --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v5_bullet/=
v5_new_i_01.gif" WIDTH=3D16 HEIGHT=3D14 BORDER=3D0 ALT=3D"www.vnunet.com/=
news">
</TD><TD WIDTH=3D132>
<B><FONT SIZE=3D1 FACE=3D"Verdana, Arial, Helvetica">
<A HREF=3D '/News/106115' > =
Database guru warns of standards split</A>
</FONT></B><BR><FONT SIZE=3D1 FACE=3D"Arial, Helvetica" COLOR=3D"#697DFF"=
[04 Feb 2000]<BR></FONT>
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gi=
f" WIDTH=3D1 HEIGHT=3D2 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
</TD></TR>
<!-- the spacer -->
<TR><TD COLSPAN=3D2>
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gi=
f" WIDTH=3D1 HEIGHT=3D4 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
</TD></TR>
<!-- the data row -->
<TR><TD WIDTH=3D18 VALIGN=3D"TOP">
<!-- news bullet --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v5_bullet/=
v5_new_i_01.gif" WIDTH=3D16 HEIGHT=3D14 BORDER=3D0 ALT=3D"www.vnunet.com/=
news">
</TD><TD WIDTH=3D132>
<B><FONT SIZE=3D1 FACE=3D"Verdana, Arial, Helvetica">
<A HREF=3D '/News/105742' > =
Cognos creates analytical applications division</A>
</FONT></B><BR><FONT SIZE=3D1 FACE=3D"Arial, Helvetica" COLOR=3D"#697DFF"=
[27 Jan 2000]<BR></FONT>
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gi=
f" WIDTH=3D1 HEIGHT=3D2 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
</TD></TR>
<!-- the spacer -->
<TR><TD COLSPAN=3D2>
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gi=
f" WIDTH=3D1 HEIGHT=3D4 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
</TD></TR>
<!-- the data row -->
<TR><TD WIDTH=3D18 VALIGN=3D"TOP">
<!-- news bullet --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v5_bullet/=
v5_new_i_01.gif" WIDTH=3D16 HEIGHT=3D14 BORDER=3D0 ALT=3D"www.vnunet.com/=
news">
</TD><TD WIDTH=3D132>
<B><FONT SIZE=3D1 FACE=3D"Verdana, Arial, Helvetica">
<A HREF=3D '/News/105204' > =
Bann bolsters operation to prevent cash saviour from going</A>
</FONT></B><BR><FONT SIZE=3D1 FACE=3D"Arial, Helvetica" COLOR=3D"#697DFF"=
[11 Jan 2000]<BR></FONT>
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gi=
f" WIDTH=3D1 HEIGHT=3D2 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
</TD></TR>
<!-- the spacer -->
<TR><TD COLSPAN=3D2>
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gi=
f" WIDTH=3D1 HEIGHT=3D4 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
</TD></TR>
<!-- the data row -->
<TR><TD WIDTH=3D18 VALIGN=3D"TOP">
<!-- news bullet --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v5_bullet/=
v5_new_i_01.gif" WIDTH=3D16 HEIGHT=3D14 BORDER=3D0 ALT=3D"www.vnunet.com/=
news">
</TD><TD WIDTH=3D132>
<B><FONT SIZE=3D1 FACE=3D"Verdana, Arial, Helvetica">
<A HREF=3D '/News/104115' > =
Ellison admits distributed databases are junk</A>
</FONT></B><BR><FONT SIZE=3D1 FACE=3D"Arial, Helvetica" COLOR=3D"#697DFF"=
[03 Dec 1999]<BR></FONT>
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gi=
f" WIDTH=3D1 HEIGHT=3D2 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
</TD></TR>
</TABLE>
<BR>
<!-- ANALYSIS -->
<!-- RELATED STUFF -->
<IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gif" WIDTH=3D1 H=
EIGHT=3D10 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
<TABLE CELLPADDING=3D0 CELLSPACING=3D1 WIDTH=3D100% BORDE=
R=3D0 VALIGN=3D"TOP" BGCOLOR=3D"#FFFFFF">
<TR>
<TD BGCOLOR=3D"#A50055" ALIGN=3D"CENTER">
<FONT SIZE=3D1 FACE=3D"Verdana, Arial, Helvetica" COLOR=3D=
"#FFFFFF"><B>NEWS CATEGORIES</B></FONT><BR>
</TD>
</TR>
<TR>
<TD>
<IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gif" WIDTH=3D=
1 HEIGHT=3D4 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
<FONT SIZE=3D1 FACE=3D"Verdana, Arial, Helvetica">
» <A HREF=3D"/News/Apple"><B>Apple</B></A><BR>
» <A HREF=3D"/News/Chips"><B>Chips</B></A><BR>
» <A HREF=3D"/News/Consumer%20Electronics"><B>Consumer Electronics</=
B></A><BR>
» <A HREF=3D"/News/Cyberculture"><B>Cyberculture</B></A><BR>
» <A HREF=3D"/News/Databases"><B>Databases</B></A><BR>
» <A HREF=3D"/News/Design"><B>Design</B></A><BR>
» <A HREF=3D"/News/ERP"><B>ERP</B></A><BR>
» <A HREF=3D"/News/Ecommerce"><B>Ecommerce</B></A><BR>
» <A HREF=3D"/News/Financial"><B>Financial</B></A><BR>
» <A HREF=3D"/News/IT%20Management"><B>IT Management</B></A><BR>
» <A HREF=3D"/News/Industry"><B>Industry</B></A><BR>
» <A HREF=3D"/News/Internet"><B>Internet</B></A><BR>
» <A HREF=3D"/News/Law"><B>Law</B></A><BR>
» <A HREF=3D"/News/Linux"><B>Linux</B></A><BR>
» <A HREF=3D"/News/Mobile"><B>Mobile</B></A><BR>
» <A HREF=3D"/News/Networking"><B>Networking</B></A><BR>
» <A HREF=3D"/News/Operating%20Systems"><B>Operating Systems</B></A>=
<BR>
» <A HREF=3D"/News/Security"><B>Security</B></A><BR>
» <A HREF=3D"/News/Servers"><B>Servers</B></A><BR>
» <A HREF=3D"/News/Skills"><B>Skills</B></A><BR>
» <A HREF=3D"/News/Software%20Development"><B>Software Development</=
B></A><BR>
» <A HREF=3D"/News/Storage"><B>Storage</B></A><BR>
» <A HREF=3D"/News/Telecomms"><B>Telecomms</B></A><BR>
</FONT><HR ALIGN=3D"CENTER" SIZE=3D"1" WIDTH=3D"100%" COLOR=3D"#E0E0E0" N=
OSHADE><FONT SIZE=3D1 FACE=3D"Verdana, Arial, Helvetica">» <A HREF=3D=
"/News/Brief"><B>In Brief Section</B></A><BR>» <A HREF=3D"/news/all"=
<B>Last 7 days news</B></A><BR><HR ALIGN=3D"CENTER" SIZE=3D"1" WIDTH=3D"=
100%" COLOR=3D"#E0E0E0" NOSHADE>» <A HREF=3D"mailto:newseditor@vnune=
t.com"><B>email us</B><BR>newseditor@vnunet.com</A></FONT><BR><HR ALIGN=3D=
"CENTER" SIZE=3D"1" WIDTH=3D"100%" COLOR=3D"#E0E0E0" NOSHADE><A HREF=3D"/=
radio"><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v5_radio/v5_radio_icon_=
w3.gif" WIDTH=3D16 HEIGHT=3D14 BORDER=3D0 ALT=3D"VNUNET AUDIO"><FONT SIZE=
=3D1 FACE=3D"Verdana, Arial, Helvetica" COLOR=3D"#FF6400"><B>For news in =
audio</B></FONT></A>
<BR><HR ALIGN=3D"CENTER" SIZE=3D"1" WIDTH=3D"100%" COLOR=3D"#A50055" NOSH=
ADE>
<!--
<SCRIPT LANGUAGE=3D"JavaScript" SRC=3D"http://www2.vnu.co.uk/v5_scripts/n=
ews_cat.js"></SCRIPT>
-->
</TD>
</TR>
</TABLE>
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gi=
f" WIDTH=3D1 HEIGHT=3D4 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
<!-- This is the table for the "whatisb2" search box... -=
->
=
<TABLE WIDTH=3D100% BORDER=3D0 BGCOLOR=3D"#697DFF" CELLSP=
ACING=3D"0" CELLPADDING=3D1>
<TR>
<TD>
<TABLE WIDTH=3D100% BORDER=3D0 BGCOLOR=3D"#FFFFFF=
" CELLSPACING=3D"0" CELLPADDING=3D"0">
<TR>
<TD>
<FORM ACTION=3D"http://www.whatis.com/api=
-shl/qsearch.cfm?search=3DYES&remote=3DYES" METHOD=3D"post" TARGET=3D"new=
win">
<TABLE WIDTH=3D100% BORDER=3D"0" CELLSPAC=
ING=3D"0" CELLPADDING=3D"0" ALIGN=3D"center">
<TR VALIGN=3D"top" ALIGN=3D"left">
<TD WIDTH=3D"120" HEIGHT=3D"12" VALIGN=3D=
"middle" ALIGN=3D"left" COLSPAN=3D"3">
<IMG SRC=3D"http://www2.vnu.co.uk/v5_imag=
e/whatis/top2.gif" WIDTH=3D"120" HEIGHT=3D"12" BORDER=3D"0">
</TD>
</TR>
<TR>
<TD WIDTH=3D"26" HEIGHT=3D"18" VALIGN=3D"=
middle" ALIGN=3D"left">
<IMG SRC=3D"http://www2.vnu.co.uk/v5_imag=
e/whatis/left.gif" WIDTH=3D"26" HEIGHT=3D"18" BORDER=3D"0">
</TD> =
<TD WIDTH=3D"66" HEIGHT=3D"18" VALIGN=3D"=
middle" ALIGN=3D"left">
<INPUT TYPE=3D"text" NAME=3D"thisterm" SI=
ZE=3D"10" MAXLENGTH=3D"25">
</TD>
<TD WIDTH=3D"28" HEIGHT=3D"18" VALIGN=3D"=
middle" ALIGN=3D"left">
<INPUT TYPE=3D"IMAGE" SRC=3D"http://www2.=
vnu.co.uk/v5_image/whatis/right.gif" NAME=3D"submit" VALUE=3D"Go">
</TD>
</TR>
<TR>
<TD COLSPAN=3D"3" WIDTH=3D"120" HEIGHT=3D=
"61" VALIGN=3D"top" ALIGN=3D"left">
<IMG SRC=3D"http://www2.vnu.co.uk/v5_imag=
e/whatis/bottom.gif" WIDTH=3D"120" HEIGHT=3D"61" BORDER=3D"0">
</TD>
</TR>
</TABLE>
</FORM>
</TD>
</TR>
</TABLE>
</TD>
</TR>
</TABLE>
</TD>
</TR>
</TABLE>
</TD>
</TR>
</TABLE>
<!-- END OF PAGE -->
<!-- BOTTOM TABLE AD + VNU COPYRIGHT -->
<TABLE CELLPADDING=3D0 CELLSPACING=3D0 WIDTH=3D720 BORDER=3D0>
<TR>
<TD WIDTH=3D120 BGCOLOR=3D"#697DFF" VALIGN=3D"TOP"> </TD>
<TD>
<!-- ** AD BANNER BOTTOM ** -->
<TABLE CELLPADDING=3D0 CELLSPACING=3D0 WIDTH=3D100% BORDER=3D0 VALIGN=3D=
"BOTTOM">
<TR>
<TD WIDTH=3D"15" BACKGROUND=3D"http://www2.vnu.co.uk/v5_image/sundries/v=
_white_shadow_bgl.gif">
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.g=
if" WIDTH=3D15 HEIGHT=3D3 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
</TD>
<TD HEIGHT=3D60>
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.g=
if" WIDTH=3D1 HEIGHT=3D3 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
<A HREF=3D"http://VNU.eu-adcenter.net/click.ng/section=3DNews&id=3D=
-512293054&site=3Dvnunet&pageposition=3Dbottom" TARGET=3D"_blank">
<IMG WIDTH=3D468 HEIGHT=3D60 border=3D0 SRC=3D"http://VNU.eu-adce=
nter.net/image.ng/section=3DNews&id=3D-512293054&site=3Dvnunet&pagepositi=
on=3Dbottom"></A>
</TD>
<TD WIDTH=3D"11">
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.g=
if" WIDTH=3D11 HEIGHT=3D3 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
</TD>
<TD WIDTH=3D"100">
<IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.gif" WIDTH=3D1 H=
EIGHT=3D3 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
<A HREF=3D"/Register"><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/home/v5=
_hp_reg_0.gif" WIDTH=3D102 HEIGHT=3D60 BORDER=3D0 ALT=3D"REGISTER NOW"></=
A>
</TD>
</TR>
</TABLE>
=
<!-- * VNUNET COPYRIGHT FOOTER * -->
<TABLE CELLPADDING=3D0 CELLSPACING=3D0 WIDTH=3D100% BORDER=3D0 VALIGN=3D=
"BOTTOM">
<TR>
<TD BACKGROUND=3D"http://www2.vnu.co.uk/v5_image/sundries/v_white_shadow=
_bgl.gif">
<!-- SPACER --><IMG SRC=3D"http://www2.vnu.co.uk/v5_image/v_spaced_out.g=
if" WIDTH=3D1 HEIGHT=3D4 BORDER=3D0 ALT=3D"SPACED OUT"><BR>
<FONT SIZE=3D1 FACE=3D"Verdana, Arial, Helvetica"> Copyright=
<B>© 2000 VNU Business Publishing Limited</B> [All rights reserved]=
</FONT><BR>
</TD>
</TR>
</TABLE>
=
</TD>
</TR>
</TABLE>
</CENTER>
</BODY>
</HTML>
--------------C7710D4F4C3C67CBE57FD184--
From bouncefilter Tue Feb 15 23:33: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 XAA53274;
Tue, 15 Feb 2000 23:32:15 -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 EAA10577;
Wed, 16 Feb 2000 04:39:54 GMT
Sender: lockhart@hub.org
Message-ID: <38AA2A1A.2627BE39@alumni.caltech.edu>
Date: Wed, 16 Feb 2000 04:39:54 +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: Michael Meskes <meskes@postgreSQL.org>
CC: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] parser changes
References: <20000215105334.A869@fam-meskes.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
... this time all parser changes make it into ecpg's parser
Do you have a pretty good way to track changes in gram.y? Let me know
if you want some help (though I won't be able to for a week or so).
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Wed Feb 16 01:02:26 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 BAA61221;
Wed, 16 Feb 2000 01:01:33 -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
AAA00170;
Wed, 16 Feb 2000 00:48:18 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002160548.AAA00170@candle.pha.pa.us>
Subject: Re: [HACKERS] parser changes
In-Reply-To: <38AA2A1A.2627BE39@alumni.caltech.edu> from Thomas Lockhart at
"Feb 16, 2000 04:39:54 am"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Wed, 16 Feb 2000 00:48:18 -0500 (EST)
CC: Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
... this time all parser changes make it into ecpg's parser
Do you have a pretty good way to track changes in gram.y? Let me know
if you want some help (though I won't be able to for a week or so).
I told him to keep a copy of the gram.y he uses, and merge changes from
the current version against the copy he has that matched the current
ecpg.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 16 01:03: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 BAA61354
for <hackers@postgreSQL.org>; Wed, 16 Feb 2000 01:02: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 GAA11799;
Wed, 16 Feb 2000 06:10:29 GMT
Sender: lockhart@hub.org
Message-ID: <38AA3F55.D70E5F12@alumni.caltech.edu>
Date: Wed, 16 Feb 2000 06:10: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: Tom Lane <tgl@sss.pgh.pa.us>
CC: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Almost there on column aliases
References: <38A3A7DB.6A684EF@alumni.caltech.edu>
<18707.950251267@sss.pgh.pa.us>
<38A3B745.E720A4AC@alumni.caltech.edu>
<18803.950253638@sss.pgh.pa.us>
<38A432D2.D6998E5B@alumni.caltech.edu>
<19051.950545044@sss.pgh.pa.us>
<38A8368B.68AF6CDA@alumni.caltech.edu>
<22598.950555491@sss.pgh.pa.us>
<38A8C61D.90557A4B@alumni.caltech.edu>
<11110.950603587@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I tried, but failed, to refrain from remarking about the horrible
style of the function declaration --- either it's static (which
looks like the right answer here) or it should be declared in
a header file. The above method of preventing gcc from telling
you how horrible your style is is just, well, never mind.
Uh, Tom, it is unused code, and I use this kind of thing while doing
development. I did warn about some crufty stuff, and glad you agree :/
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Wed Feb 16 01:27:15 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 BAA65031
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 01:26:29 -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 BAA01848
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 01:26:22 -0500 (EST)
To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] parser changes
In-reply-to: <200002160548.AAA00170@candle.pha.pa.us>
References: <200002160548.AAA00170@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Wed, 16 Feb 2000 00:48:18 -0500"
Date: Wed, 16 Feb 2000 01:26:22 -0500
Message-ID: <1845.950682382@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
... this time all parser changes make it into ecpg's parser
Do you have a pretty good way to track changes in gram.y? Let me know
if you want some help (though I won't be able to for a week or so).
I told him to keep a copy of the gram.y he uses, and merge changes from
the current version against the copy he has that matched the current
ecpg.
It seems to me that this whole business of tracking a hand-maintained
modified copy of gram.y is wrong. There ought to be a way for ecpg to
just incorporate the backend grammar by reference, plus a few rules
on top for ecpg-specific constructs.
I will freely admit that I have no idea what's standing in the way of
that ... but it seems like we ought to try to work towards the goal
of not having a synchronization problem in the first place, rather
than spending effort on minimizing the synchronization error. Perhaps
that means tweaking or subdividing the backend grammar, but if so it'd
be effort well spent.
It's probably too late to do anything in this line for 7.0, but
I suggest we think about it for future releases.
regards, tom lane
From bouncefilter Wed Feb 16 01:37:15 2000
Received: from hu.tm.ee (ppp809.tele2.ee [212.107.37.109])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA65836
for <hackers@postgreSQL.org>; Wed, 16 Feb 2000 01:36:13 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id D43D93B14; Wed, 16 Feb 2000 08:44:15 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38AA473F.4279EE67@tm.ee>
Date: Wed, 16 Feb 2000 08:44:15 +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: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
Cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] IBM sues Informix over DB patents
References: <20000215183957.A5657@rice.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"Ross J. Reedstrom" wrote:
Anyone see this little news item? It showed up in my
paper copy of InfoWorld today.http://www.infoworld.com/articles/hn/xml/00/02/14/000214hnpatent.xml
It caught my eye, and I'm forwarding it here, since Informix's Universal
DB now incorporates the old Illustra code. Since stepping on patents
has always been one of the open source software nightmare scenarios,
it's be nice to know which patents are involved.(BTW, I was checking out Informix's DataBlade technology: turns out it's
just like pgsql's user extensible types and functions, with pretty PR
and training tools - and a little better integration packaging. The basic
API is so similar, I woudn't be suprised if it's a direct descendant)
It very likely is, as Illustra (which introduced the name DataBlades) was
a direct descendant of old Postgres 4.2.
They moved independantly from postquel to SQL but the engine they
started from was the same.
------------------
Hannu
From bouncefilter Wed Feb 16 02:16:52 2000
Received: from feivel.fam-meskes.de (h-62.96.159.133.host.de.colt.net
[62.96.159.133]) by hub.org (8.9.3/8.9.3) with ESMTP id CAA68853
for <pgsql-hackers@postgresql.org>;
Wed, 16 Feb 2000 02:15:56 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 01B062BBA2; Wed, 16 Feb 2000 08:12:04 +0100 (CET)
Date: Wed, 16 Feb 2000 08:12:04 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] parser changes
Message-ID: <20000216081204.A1592@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
References: <200002160548.AAA00170@candle.pha.pa.us>
<1845.950682382@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <1845.950682382@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Wed, Feb 16, 2000 at 01:26:22AM -0500
Sender: michael@fam-meskes.de
On Wed, Feb 16, 2000 at 01:26:22AM -0500, Tom Lane wrote:
Do you have a pretty good way to track changes in gram.y? Let me know
if you want some help (though I won't be able to for a week or so).
Right now I'm up-to-date. But I have yet to finish my own todo for 7.0.
I told him to keep a copy of the gram.y he uses, and merge changes from
the current version against the copy he has that matched the current
ecpg.
That's exactly how I do it. I run diff from time to tim and add the changes
to my version by hand.
It seems to me that this whole business of tracking a hand-maintained
modified copy of gram.y is wrong. There ought to be a way for ecpg to
just incorporate the backend grammar by reference, plus a few rules
on top for ecpg-specific constructs.
I would love this. But frankly I don't see how we can accomblish this. After
all ECPG has to print out the statment word by word while the backend puts
it into internal structure.
It's probably too late to do anything in this line for 7.0, but
I suggest we think about it for future releases.
Any ideas anyone?
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 Feb 16 02:16:50 2000
Received: from feivel.fam-meskes.de (h-62.96.159.133.host.de.colt.net
[62.96.159.133]) by hub.org (8.9.3/8.9.3) with ESMTP id CAA68852
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 02:15:55 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id AD1AC2BBA3; Wed, 16 Feb 2000 08:14:22 +0100 (CET)
Date: Wed, 16 Feb 2000 08:14:22 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] function question yet again
Message-ID: <20000216081422.A1623@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
References: <20000215131439.A2553@fam-meskes.de>
<38A91179.AB924F0A@mascari.com>
<20000215152620.A11746@fam-meskes.de>
<38A96C2F.6796050A@mascari.com> <24028.950650165@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <24028.950650165@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Tue, Feb 15, 2000 at 04:29:25PM -0500
Sender: michael@fam-meskes.de
On Tue, Feb 15, 2000 at 04:29:25PM -0500, Tom Lane wrote:
SPI is the recommended interface for server-side addon code, I think.
Okay, I see. That means my try to use ECPG to create a function is not
supposed to work. Gheez, I would have liked it.
Bear in mind that libpq is not present in the backend. If you load
a library containing your code + libpq and then try to do something
via libpq, what will happen is that libpq will contact the postmaster,
fire up a new backend, and send all your queries to that other backend.
Probably not quite what you had in mind, and I could imagine it leading
to deadlock problems against your own backend. (But I don't see why it
would cause the particular error Michael is complaining of; that still
looks like it might be a newline-versus-carriage-return kind of bug.)
Right. Since the function does only a select and noone else is working on
that database it shouldn't deadlock either.
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 Feb 16 03:59:20 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA78852
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 03:58:32 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id TAA10314
for <pgsql-hackers@postgreSQL.org>; Wed, 16 Feb 2000 19:58:25 +1100
Sender: chris@tech.com.au
Message-ID: <38AA66B0.C796CF4F@bitmead.com>
Date: Wed, 16 Feb 2000 19:58:24 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Interbase
References: <200002152157.QAA16126@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Does MySQL have the team size we have? I don't see them
progressing at our speed.
MySQL is mostly written by one guy who knows it all inside out. That has
its advantages and disadvantages.
From bouncefilter Wed Feb 16 04:03:16 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 EAA79298
for <pgsql-hackers@postgresql.org>;
Wed, 16 Feb 2000 04:02:58 -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 12L0MF-00005m-00; Wed, 16 Feb 2000 12:02:51 +0300
Date: Wed, 16 Feb 2000 09:02:51 +0000 (GMT)
From: Oleg Broytmann <phd@phd.russ.ru>
X-Sender: phd@fep132.fep.ru
Reply-To: phd2@earthling.net
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Postgres meets InterBase (ZDNet)
Message-ID: <Pine.LNX.4.21.0002160900200.345-100000@fep132.fep.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi!
The article
http://www.zdnet.com/enterprise/stories/linux/news/0,6423,2436153,00.html
mentions Interbase will be released under Mozilla Public License 1.1.
Oleg.
----
Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net
Programmers don't die, they just GOSUB without RETURN.
From bouncefilter Wed Feb 16 04:15:27 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 EAA80786
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 04:14: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
EAA03501;
Wed, 16 Feb 2000 04:11:18 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002160911.EAA03501@candle.pha.pa.us>
Subject: Re: [HACKERS] Interbase
In-Reply-To: <38AA66B0.C796CF4F@bitmead.com> from Chris at "Feb 16,
2000 07:58:24 pm"
To: Chris <chris@bitmead.com>
Date: Wed, 16 Feb 2000 04:11:18 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Does MySQL have the team size we have? I don't see them
progressing at our speed.MySQL is mostly written by one guy who knows it all inside out. That has
its advantages and disadvantages.
That's what I thought. That will keep us ahead of them.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 16 04:21:17 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA81357
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 04:21:14 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id UAA10589
for <pgsql-hackers@postgreSQL.org>; Wed, 16 Feb 2000 20:21:06 +1100
Sender: chris@tech.com.au
Message-ID: <38AA6C01.DB03B000@bitmead.com>
Date: Wed, 16 Feb 2000 20:21:05 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pghackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] vnunet.com Inprise/Borland spins off Interbase database
as separate company
References: <38AA2204.5FD74243@austin.rr.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
This comment caught my eye...
But another joint founder, Don DePalma, has
expressed concern at the open source plan.
Because of the complexity of Interbase, he
claimed: "You really don't want non-experts
mucking about with it.
Gee, looks like Interbase internals are too
hard for us dumb geeks (because all open-source
programmers are uni-students right?). Better
stick to postgresql I guess :-)
From bouncefilter Wed Feb 16 06:52:19 2000
Received: from feivel.fam-meskes.de (p3E9B98BA.dip0.t-ipconnect.de
[62.155.152.186]) by hub.org (8.9.3/8.9.3) with ESMTP id GAA92910
for <pgsql-hackers@postgresql.org>;
Wed, 16 Feb 2000 06:51:47 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id D04D62BD54; Wed, 16 Feb 2000 11:11:27 +0100 (CET)
Date: Wed, 16 Feb 2000 11:11:27 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: psql compile problems
Message-ID: <20000216111127.A10763@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
Sender: michael@fam-meskes.de
I just looked into the code and found that the file pgsql/common.c includes
interfaces/libpq/c.h instead of include/c.h. I changed the CFLAGS setting in
the Makefile to append -I$(LIBPQDIR) instead of insert it and it compiles
fine.
BTW the file common.c includes c.h twice, directly and via common.h.
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 Feb 16 06:52:18 2000
Received: from feivel.fam-meskes.de (p3E9B98BA.dip0.t-ipconnect.de
[62.155.152.186]) by hub.org (8.9.3/8.9.3) with ESMTP id GAA92911
for <pgsql-hackers@postgresql.org>;
Wed, 16 Feb 2000 06:51:47 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 09AE72BD55; Wed, 16 Feb 2000 11:15:14 +0100 (CET)
Date: Wed, 16 Feb 2000 11:15:14 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: ERROR: Unable to identify an operator '=' for types 'numeric' and
'float8'
Message-ID: <20000216111514.A11496@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
Sender: michael@fam-meskes.de
Why isn't this casted automatically?
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 Feb 16 05:42:17 2000
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA88026
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 05:37:07 -0500 (EST) (envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.3/8.9.3) with SMTP id NAA14224
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 13:36:50 +0300 (GMT)
Date: Wed, 16 Feb 2000 13:36:50 +0300 (GMT)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: pgsql-hackers@postgreSQL.org
Subject: postgres on notebook
Message-ID: <Pine.GSO.3.96.SK.1000216132552.11346H-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Silly question,
I've got nice ThinkPad 390E with 128Mb RAM and install Linux+Postgres
6.5.3. Everything work like a charm except strange behaivour when
notebook wake up after suspend mode. I noticed
a lot of [postmaster] in ps output. Is it normal ?
Usually I see like now:
4513 ? S 0:00 /usr/local/pgsql/bin/postmaster -i -B 1024 -N 32 -S -
4941 ? S 0:00 /usr/local/pgsql/bin/postgres localhost httpd discove
4943 ? S 0:00 /usr/local/pgsql/bin/postgres localhost httpd polit_d
4944 ? S 0:00 /usr/local/pgsql/bin/postgres localhost httpd voting
4945 ? S 0:00 /usr/local/pgsql/bin/postgres localhost httpd discove
4946 ? S 0:00 /usr/local/pgsql/bin/postgres localhost httpd polit_d
4947 ? S 0:00 /usr/local/pgsql/bin/postgres localhost httpd voting
4948 ? S 0:00 /usr/local/pgsql/bin/postgres localhost httpd discove
4949 ? S 0:00 /usr/local/pgsql/bin/postgres localhost httpd polit_d
4950 ? S 0:00 /usr/local/pgsql/bin/postgres localhost httpd voting
I have apache+modperl running with persistent connection with postgres using
DBI/Apache::DBI. After wake up, all these stuff seems work ok,
but probably [postmaster] processes doesn't works, at least I've seen
new postgres processes with much more PID's appearing (Apache::DBI should
take care about that). I didn't take much attention yet and just asking
if there are something special with Postgres interaction with
Linux running on notebook (apm stuff)
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
From bouncefilter Wed Feb 16 07:14:19 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 HAA94487
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 07:13:22 -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 NAA12094;
Wed, 16 Feb 2000 13:13:19 +0100
Date: Wed, 16 Feb 2000 13:13:19 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: pgsql-hackers <pgsql-hackers@postgreSQL.org>
cc: Bruce Momjian <pgman@candle.pha.pa.us>
Subject: TODO: Cache most recent query plan
Message-ID: <Pine.LNX.3.96.1000216131111.28508B-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
In TODO is:
CACHE:
* Cache most recent query plan(s) [prepare]
!--> I'm working on this.
TODO.detail (Jan's idea):
I can think of the following construct:
PREPARE optimizable-statement;
That one will run parser/rewrite/planner, create a new memory
context with a unique identifier and saves the querytree's
and plan's in it. Parameter values are identified by the
usual $n notation. The command returns the identifier.
EXECUTE QUERY identifier [value [, ...]];
then get's back the prepared plan and querytree by the id,
creates an executor context with the given values in the
parameter array and calls ExecutorRun() for them.
.... etc (cut).
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 Feb 16 08:10:19 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 IAA99134;
Wed, 16 Feb 2000 08:09: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
IAA15614;
Wed, 16 Feb 2000 08:08:55 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002161308.IAA15614@candle.pha.pa.us>
Subject: Re: [HACKERS] psql compile problems
In-Reply-To: <20000216111127.A10763@fam-meskes.de> from Michael Meskes at "Feb
16, 2000 11:11:27 am"
To: Michael Meskes <meskes@postgreSQL.org>
Date: Wed, 16 Feb 2000 08:08:55 -0500 (EST)
CC: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I just looked into the code and found that the file pgsql/common.c includes
interfaces/libpq/c.h instead of include/c.h. I changed the CFLAGS setting in
the Makefile to append -I$(LIBPQDIR) instead of insert it and it compiles
fine.BTW the file common.c includes c.h twice, directly and via common.h.
I have cleaned up include file use in psql. It now uses the standard
postgres.h includes and does not use redundant includes as much.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 16 08:33:19 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA01799
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 08:33:16 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id AAA13923
for <pgsql-hackers@postgreSQL.org>; Thu, 17 Feb 2000 00:33:11 +1100
Sender: chris@tech.com.au
Message-ID: <38AAA714.70E32799@bitmead.com>
Date: Thu, 17 Feb 2000 00:33:08 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] TODO: Cache most recent query plan
References: <Pine.LNX.3.96.1000216131111.28508B-100000@ara.zf.jcu.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Karel Zak - Zakkr wrote:
In TODO is:
CACHE:
* Cache most recent query plan(s) [prepare]
I havn't been following what this is about, but
any implementation of caching query plans should
be careful about pg_class.relhasindex and
pg_class.relhassubclass, otherwise reuse of
query plans could give incorrect results, _maybe_,
depending on what you are planning here.
--
Chris Bitmead
mailto:chris@bitmead.com
From bouncefilter Wed Feb 16 09:08:20 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 JAA08981
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 09:07:22 -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 OAA17030;
Wed, 16 Feb 2000 14:13:33 GMT
Sender: lockhart@hub.org
Message-ID: <38AAB08C.D76ED537@alumni.caltech.edu>
Date: Wed, 16 Feb 2000 14:13: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: Oleg Bartunov <oleg@sai.msu.su>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postgres on notebook
References: <Pine.GSO.3.96.SK.1000216132552.11346H-100000@ra>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I have apache+modperl running with persistent connection with postgres using
DBI/Apache::DBI. After wake up, all these stuff seems work ok,
but probably [postmaster] processes doesn't works, at least I've seen
new postgres processes with much more PID's appearing (Apache::DBI should
take care about that). I didn't take much attention yet and just asking
if there are something special with Postgres interaction with
Linux running on notebook (apm stuff)
There should be none afaik. But I'll try testing on my laptop sometime
soon (not running apache, but I can leave a backend connected to a
psql session and see that it responds after waking up).
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Wed Feb 16 09:07:21 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 JAA08932;
Wed, 16 Feb 2000 09:06:57 -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 OAA17036;
Wed, 16 Feb 2000 14:14:36 GMT
Sender: lockhart@hub.org
Message-ID: <38AAB0CC.F0EB8570@alumni.caltech.edu>
Date: Wed, 16 Feb 2000 14:14:36 +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: Michael Meskes <meskes@postgresql.org>
CC: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] ERROR: Unable to identify an operator '=' for types
'numeric' and 'float8'
References: <20000216111514.A11496@fam-meskes.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Why isn't this casted automatically?
Oversight. Will look at it.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Wed Feb 16 09:30:22 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 JAA12966;
Wed, 16 Feb 2000 09:30:19 -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 JAA02507;
Wed, 16 Feb 2000 09:30:15 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ERROR: Unable to identify an operator '=' for types
'numeric' and 'float8'
In-reply-to: <38AAB0CC.F0EB8570@alumni.caltech.edu>
References: <20000216111514.A11496@fam-meskes.de>
<38AAB0CC.F0EB8570@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Wed, 16 Feb 2000 14:14:36 +0000"
Date: Wed, 16 Feb 2000 09:30:14 -0500
Message-ID: <2504.950711414@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
Why isn't this casted automatically?
Oversight. Will look at it.
I believe it's the problem I complained of before: TypeCategory()
doesn't think NUMERIC is a numeric type...
regards, tom lane
From bouncefilter Wed Feb 16 09:46:21 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 JAA25835;
Wed, 16 Feb 2000 09:46:17 -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 JAA02617;
Wed, 16 Feb 2000 09:46:08 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ERROR: Unable to identify an operator '=' for types
'numeric' and 'float8'
In-reply-to: <38AAB865.87615603@alumni.caltech.edu>
References: <20000216111514.A11496@fam-meskes.de>
<38AAB0CC.F0EB8570@alumni.caltech.edu>
<2504.950711414@sss.pgh.pa.us>
<38AAB865.87615603@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Wed, 16 Feb 2000 14:47:01 +0000"
Date: Wed, 16 Feb 2000 09:46:08 -0500
Message-ID: <2614.950712368@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
One hesitation I have is the performance hit in mixing FLOAT and
NUMERIC; I (probably) don't want to make NUMERIC the "best" numeric
type, since it is potentially so slow.
I concur --- I'd be inclined to leave FLOAT8 as the top of the
hierarchy. But NUMERIC could be stuck in there between int and float,
no? (int-vs-numeric ops certainly must be promoted to numeric...)
regards, tom lane
From bouncefilter Wed Feb 16 09:40:21 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 JAA15130;
Wed, 16 Feb 2000 09:39: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 OAA17102;
Wed, 16 Feb 2000 14:47:01 GMT
Sender: lockhart@hub.org
Message-ID: <38AAB865.87615603@alumni.caltech.edu>
Date: Wed, 16 Feb 2000 14:47: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: Tom Lane <tgl@sss.pgh.pa.us>
CC: Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ERROR: Unable to identify an operator '=' for types
'numeric' and 'float8'
References: <20000216111514.A11496@fam-meskes.de>
<38AAB0CC.F0EB8570@alumni.caltech.edu>
<2504.950711414@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Why isn't this casted automatically?
Oversight. Will look at it.
I believe it's the problem I complained of before: TypeCategory()
doesn't think NUMERIC is a numeric type...
Right. The "oversight" is a long standing one, and somewhat
intentional.
One hesitation I have is the performance hit in mixing FLOAT and
NUMERIC; I (probably) don't want to make NUMERIC the "best" numeric
type, since it is potentially so slow. I'll have to look to see what
happens in INT/FLOAT mixed arithmetic and make sure it doesn't end up
doing it in NUMERIC instead.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Wed Feb 16 10:07:25 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 KAA32401;
Wed, 16 Feb 2000 10:07: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 KAA02743;
Wed, 16 Feb 2000 10:07:06 -0500 (EST)
To: Michael Meskes <meskes@postgreSQL.org>
cc: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] parser changes
In-reply-to: <20000216081204.A1592@fam-meskes.de>
References: <200002160548.AAA00170@candle.pha.pa.us>
<1845.950682382@sss.pgh.pa.us> <20000216081204.A1592@fam-meskes.de>
Comments: In-reply-to Michael Meskes <meskes@postgreSQL.org>
message dated "Wed, 16 Feb 2000 08:12:04 +0100"
Date: Wed, 16 Feb 2000 10:07:06 -0500
Message-ID: <2737.950713626@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Michael Meskes <meskes@postgreSQL.org> writes:
It seems to me that this whole business of tracking a hand-maintained
modified copy of gram.y is wrong. There ought to be a way for ecpg to
just incorporate the backend grammar by reference, plus a few rules
on top for ecpg-specific constructs.
I would love this. But frankly I don't see how we can accomblish this. After
all ECPG has to print out the statment word by word while the backend puts
it into internal structure.
Any ideas anyone?
Ah, your point is that the actions have to be different even if the
yacc grammar is the same. Hmm. A few ideas off the top of the head:
1. Create a tool that strips the backend's actions out of gram.y
and inserts ecpg's actions to produce a gram.y file for ecpg, all
automatically. This could probably be done with a perl script,
although it might require tweaking gram.y to have a more uniform
layout convention for its actions. (You'd also need to figure out
how to identify which ecpg action code snippet to insert for each
rule, which is not so easy.)
2. Revise gram.y so that all it does is call functions that are
defined in another file; then ecpg and backend use the same gram.y,
but link it to different sets of action subroutines.
3. Use the backend's gram.y as it stands, and rewrite ecpg to
reverse-list the statements from the parsetree constructed by the
grammar. (You could steal most of the logic from ruleutils.c.)
Aside from the work involved, the major problem with any of these
approaches is that practically any change in or around the backend's
gram.y would instantly break ecpg; backend and ecpg source would
have to be maintained in strict synchrony or the system wouldn't
even compile. Perhaps that would be good discipline ;-) but I doubt
there will be much enthusiasm for it among the backend developers.
The current way at least allows ecpg development to proceed at its
own schedule.
Still, it seems like you might want to think about building some
kind of tool to help you with keeping the files in sync. For example,
it'd probably be easier to diff ecpg and backend grammar files if
you made a script that just strips out the action parts.
regards, tom lane
From bouncefilter Wed Feb 16 10:20:21 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 KAA34041
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 10:20: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 KAA02826;
Wed, 16 Feb 2000 10:19:49 -0500 (EST)
To: Chris <chris@bitmead.com>
cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] TODO: Cache most recent query plan
In-reply-to: <38AAA714.70E32799@bitmead.com>
References: <Pine.LNX.3.96.1000216131111.28508B-100000@ara.zf.jcu.cz>
<38AAA714.70E32799@bitmead.com>
Comments: In-reply-to Chris <chris@bitmead.com>
message dated "Thu, 17 Feb 2000 00:33:08 +1100"
Date: Wed, 16 Feb 2000 10:19:48 -0500
Message-ID: <2823.950714388@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Chris <chris@bitmead.com> writes:
* Cache most recent query plan(s) [prepare]
I havn't been following what this is about, but
any implementation of caching query plans should
be careful about pg_class.relhasindex and
pg_class.relhassubclass, otherwise reuse of
query plans could give incorrect results, _maybe_,
depending on what you are planning here.
Well, of course the cached plan would only be good as long as you
weren't changing the database schema underneath it. I'm not sure
how far the system ought to go to prevent the user from continuing
to use a no-longer-valid plan ... exact detection of trouble seems
impractical, but I'm not thrilled with a "let the programmer beware"
approach either.
Also, assuming that we do have some trouble detection mechanism, should
we reject subsequent attempts to use the cached plan, or automatically
re-do the plan on next use? If we kept around source or querytree form
of the original query, it ought to be possible to re-make the plan.
This would let us adopt a fairly simple trouble-detection mechanism that
would err in the direction of re-planning too much; say just replan on
any relcache flush for the relevant tables & indices. (If we're going
to raise an error, that test would be much too prone to raise errors
unnecessarily.)
This seems closely related to Jan's TODO item about recompiling rules
when the DB schema changes, too.
regards, tom lane
From bouncefilter Wed Feb 16 10:44:22 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 KAA37640
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 10:44:17 -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 KAA02923;
Wed, 16 Feb 2000 10:43:35 -0500 (EST)
To: Philip Warner <pjw@rhyme.com.au>
cc: "Hiroshi Inoue" <Inoue@tpf.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
In-reply-to: <3.0.5.32.20000215190809.034d1b10@mail.rhyme.com.au>
References: <000301bf774f$feb8aa20$2801007e@tpf.co.jp>
<000301bf774f$feb8aa20$2801007e@tpf.co.jp>
<3.0.5.32.20000215190809.034d1b10@mail.rhyme.com.au>
Comments: In-reply-to Philip Warner <pjw@rhyme.com.au>
message dated "Tue, 15 Feb 2000 19:08:09 +1100"
Date: Wed, 16 Feb 2000 10:43:35 -0500
Message-ID: <2920.950715815@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Philip Warner <pjw@rhyme.com.au> writes:
A possible answer is to define OFFSET/LIMIT in DECLARE CURSOR as
being simply a hint to the optimizer about how much of the query
result will actually get fetched.
This seems a good approach until cursors are fixed. But is there a plan to
make cursors support LIMIT properly? Do you know why they ignore the LIMIT
clause?
Should they obey LIMIT? MOVE/FETCH seems like a considerably more
flexible interface, so I'm not quite sure why anyone would want to
use LIMIT in a cursor.
Still, it seems kind of inconsistent that cursors ignore LIMIT.
I don't know for sure why it was done that way.
regards, tom lane
From bouncefilter Wed Feb 16 10:44:23 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 KAA37633
for <hackers@postgreSQL.org>; Wed, 16 Feb 2000 10:44:09 -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 PAA20777;
Wed, 16 Feb 2000 15:48:32 GMT
Sender: lockhart@hub.org
Message-ID: <38AAC6D0.2B0AB8C@alumni.caltech.edu>
Date: Wed, 16 Feb 2000 15:48: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>
CC: Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Almost there on column aliases
References: <38A3A7DB.6A684EF@alumni.caltech.edu>
<18707.950251267@sss.pgh.pa.us>
<38A3B745.E720A4AC@alumni.caltech.edu>
<18803.950253638@sss.pgh.pa.us>
<38A432D2.D6998E5B@alumni.caltech.edu>
<19051.950545044@sss.pgh.pa.us>
<38A8368B.68AF6CDA@alumni.caltech.edu>
<22598.950555491@sss.pgh.pa.us>
<38A8C61D.90557A4B@alumni.caltech.edu>
<23664.950648530@sss.pgh.pa.us> <38A9C751.7365FA7@jpl.nasa.gov>
<28639.950652834@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
BTW, the rule regress test is presently failing because I modified
ruleutils.c to dump the Attr list if it is not null, rather than
only if the refname is different from the relname:
I'm currently (2000-02-16 15:40 GMT) seeing the rules test
blank-filling the "bpchar" fields. Do you see that?
istm that the column aliases (rte->ref->attrs) should not be written out
if the table alias (rte->ref->relname) is not written.Hmm. If it's not possible to specify column aliases without specifying
a table-name alias, then that's OK ... but I thought table aliases were
optional.
I've just looked it up in the Date book: table aliases are optional in
general, but column aliases require a table alias. The bnf looks like
table [ [ AS ] range-variable [ ( column-commalist ) ] ]
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Wed Feb 16 10:57:21 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 KAA39268
for <pgsql-hackers@postgresql.org>;
Wed, 16 Feb 2000 10:57: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 KAA06974;
Wed, 16 Feb 2000 10:57:09 -0500
Message-ID: <38AAC8CF.84958699@wgcr.org>
Date: Wed, 16 Feb 2000 10:57:03 -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: phd2@earthling.net
CC: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Postgres meets InterBase (ZDNet)
References: <Pine.LNX.4.21.0002160900200.345-100000@fep132.fep.ru>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Oleg Broytmann wrote:
Hi!
The article
http://www.zdnet.com/enterprise/stories/linux/news/0,6423,2436153,00.html
mentions Interbase will be released under Mozilla Public License 1.1.
For another good read, also check
http://www.zdnet.com/enterprise/stories/linux/news/0,6423,2436155,00.html
Excerpting:
"However, PC Week Labs cautions that MySQL shouldn't be compared with
higher-end databases, such as InterBase or PostgreSQL (see Tech
Analysis). It's a fundamentally different product with different design
goals."
The author then goes on to compare MySQL to Paradox or FoxPro.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Wed Feb 16 11:01:22 2000
Received: from ns1.aktrad.ru (ns1.aktrad.ru [195.218.140.4])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA39886
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 11:00:37 -0500 (EST) (envelope-from hook@aktrad.ru)
Received: from sloth (sloth.aktrad.ru [195.218.140.13])
by ns1.aktrad.ru (8.9.3/8.9.3) with SMTP id TAA86733
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 19:00:03 +0300 (MSK)
Message-ID: <080b01bf7896$e6e184b0$0d8cdac3@aktrad.ru>
From: "Gene Sokolov" <hook@aktrad.ru>
To: "PostgreSQL Hacker" <pgsql-hackers@postgreSQL.org>
References: <20000216111514.A11496@fam-meskes.de>
<38AAB0CC.F0EB8570@alumni.caltech.edu>
<2504.950711414@sss.pgh.pa.us>
<38AAB865.87615603@alumni.caltech.edu>
<2614.950712368@sss.pgh.pa.us>
Subject: Re: [HACKERS] ERROR: Unable to identify an operator '=' for types
'numeric' and 'float8'
Date: Wed, 16 Feb 2000 19:00:05 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="koi8-r"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
One hesitation I have is the performance hit in mixing FLOAT and
NUMERIC; I (probably) don't want to make NUMERIC the "best" numeric
type, since it is potentially so slow.I concur --- I'd be inclined to leave FLOAT8 as the top of the
hierarchy. But NUMERIC could be stuck in there between int and float,
no? (int-vs-numeric ops certainly must be promoted to numeric...)
If you cast NUMERIC to FLOAT8, then you would loose precision and it would
be counterintuitive type promotion (at least for a C programmer). If someone
wants speed over correctness, he can always explicitly cast NUMERIC to
FLOAT8. Seems like "correct" should take precedence over "fast", at least as
long as there is a way to do "fast".
Gene Sokolov.
From bouncefilter Wed Feb 16 11:37:23 2000
Received: from candle.pha.pa.us (s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA45306;
Wed, 16 Feb 2000 11:36: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
LAA28300;
Wed, 16 Feb 2000 11:03:29 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002161603.LAA28300@candle.pha.pa.us>
Subject: Re: [HACKERS] parser changes
In-Reply-To: <2737.950713626@sss.pgh.pa.us> from Tom Lane at "Feb 16,
2000 10:07:06 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed, 16 Feb 2000 11:03:29 -0500 (EST)
CC: Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Still, it seems like you might want to think about building some
kind of tool to help you with keeping the files in sync. For example,
it'd probably be easier to diff ecpg and backend grammar files if
you made a script that just strips out the action parts.
Let me know if you need help with that.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 16 11:14:22 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA41941;
Wed, 16 Feb 2000 11:13:53 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Svala.DoCS.UU.SE (e99re41@Svala.DoCS.UU.SE [130.238.9.166])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id RAA15050;
Wed, 16 Feb 2000 17:13:45 +0100 (MET)
Received: from localhost (e99re41@localhost) by Svala.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id RAA16459;
Wed, 16 Feb 2000 17:13:44 +0100
X-Authentication-Warning: Svala.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Wed, 16 Feb 2000 17:13:44 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql compile problems
In-Reply-To: <200002161308.IAA15614@candle.pha.pa.us>
Message-ID: <Pine.GSO.4.02A.10002161711010.16403-100000@Svala.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 16 Feb 2000, Bruce Momjian wrote:
I just looked into the code and found that the file pgsql/common.c includes
interfaces/libpq/c.h instead of include/c.h. I changed the CFLAGS setting in
the Makefile to append -I$(LIBPQDIR) instead of insert it and it compiles
fine.BTW the file common.c includes c.h twice, directly and via common.h.
I have cleaned up include file use in psql. It now uses the standard
postgres.h includes and does not use redundant includes as much.
Actually, the point of including c.h (plus postgres_ext.h) rather than
postgres.h was to not have access to the backend internal stuff, so as to
keep the separation clean. But it doesn't really matter to me. Also, on my
system at least, there were no redundant includes. I actually went through
each library call and put in exactly the includes the man page mentioned.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Wed Feb 16 11:17:22 2000
Received: from feivel.fam-meskes.de (p3E9B986A.dip0.t-ipconnect.de
[62.155.152.106]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA42235
for <pgsql-hackers@postgresql.org>;
Wed, 16 Feb 2000 11:16:52 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 424512BD58; Wed, 16 Feb 2000 17:16:34 +0100 (CET)
Date: Wed, 16 Feb 2000 17:16:34 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: DESCRIPTORS
Message-ID: <20000216171634.A1933@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
Sender: michael@fam-meskes.de
Hi,
I just committed a patch Christof Petig send me to add DESCRIPTORS to ecpg.
Please test this patch. From the first look it needs some cleanup as does
the rest of ecpg. But other than that it seems to work fine. I will try to
clean up the sources some but wanted to get this one out before we go beta.
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 Feb 16 14:29:24 2000
Received: from feivel.fam-meskes.de (h-62.96.161.38.host.de.colt.net
[62.96.161.38]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA05298
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 14:27:56 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id A6FF32BD58; Wed, 16 Feb 2000 17:34:27 +0100 (CET)
Date: Wed, 16 Feb 2000 17:34:27 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] parser changes
Message-ID: <20000216173427.A2337@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
References: <200002160548.AAA00170@candle.pha.pa.us>
<1845.950682382@sss.pgh.pa.us> <20000216081204.A1592@fam-meskes.de>
<2737.950713626@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <2737.950713626@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Wed, Feb 16, 2000 at 10:07:06AM -0500
Sender: michael@fam-meskes.de
On Wed, Feb 16, 2000 at 10:07:06AM -0500, Tom Lane wrote:
...
Aside from the work involved, the major problem with any of these
approaches is that practically any change in or around the backend's
gram.y would instantly break ecpg; backend and ecpg source would
That means everyone who changes gram.y nowadays would then have to change
the corresponding ecpg function as well. Nice idea. :-)
there will be much enthusiasm for it among the backend developers.
I'm afraid you're right on this one.
Still, it seems like you might want to think about building some
kind of tool to help you with keeping the files in sync. For example,
it'd probably be easier to diff ecpg and backend grammar files if
you made a script that just strips out the action parts.
It's not that difficult to read and apply a context diff by hand. After all
the changes are mostly moderately.
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 Feb 16 11:42:22 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 LAA46190;
Wed, 16 Feb 2000 11:41:34 -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
LAA02621;
Wed, 16 Feb 2000 11:39:48 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002161639.LAA02621@candle.pha.pa.us>
Subject: Re: [HACKERS] psql compile problems
In-Reply-To: <Pine.GSO.4.02A.10002161711010.16403-100000@Svala.DoCS.UU.SE>
from
Peter Eisentraut at "Feb 16, 2000 05:13:44 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Wed, 16 Feb 2000 11:39:48 -0500 (EST)
CC: Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Actually, the point of including c.h (plus postgres_ext.h) rather than
postgres.h was to not have access to the backend internal stuff, so as to
keep the separation clean. But it doesn't really matter to me. Also, on my
system at least, there were no redundant includes. I actually went through
each library call and put in exactly the includes the man page mentioned.
Yes, I suspected that was your purpose. I couldn't find any other areas
where c.h was used, so I figured I may as well make it standard, and if
we want to make it separate, we would have to do most of bin and
interfaces, and that would be a separate job.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 16 11:56:23 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 LAA49035;
Wed, 16 Feb 2000 11:55: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
LAA03111;
Wed, 16 Feb 2000 11:52:11 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002161652.LAA03111@candle.pha.pa.us>
Subject: Re: [HACKERS] Postgres meets InterBase (ZDNet)
In-Reply-To: <38AAC8CF.84958699@wgcr.org> from Lamar Owen at "Feb 16,
2000 10:57:03 am"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Wed, 16 Feb 2000 11:52:11 -0500 (EST)
CC: phd2@earthling.net, PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
webmaster@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Oleg Broytmann wrote:
Hi!
The article
http://www.zdnet.com/enterprise/stories/linux/news/0,6423,2436153,00.html
mentions Interbase will be released under Mozilla Public License 1.1.For another good read, also check
http://www.zdnet.com/enterprise/stories/linux/news/0,6423,2436155,00.htmlExcerpting:
"However, PC Week Labs cautions that MySQL shouldn't be compared with
higher-end databases, such as InterBase or PostgreSQL (see Tech
Analysis). It's a fundamentally different product with different design
goals."The author then goes on to compare MySQL to Paradox or FoxPro.
We should get a link to this on our web page.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 16 12:34:23 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 MAA56270
for <hackers@postgresql.org>; Wed, 16 Feb 2000 12:33:47 -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 RAA28058
for <hackers@postgresql.org>; Wed, 16 Feb 2000 17:41:23 GMT
Sender: lockhart@hub.org
Message-ID: <38AAE143.82611E33@alumni.caltech.edu>
Date: Wed, 16 Feb 2000 17:41:23 +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: Date/time types: big change
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I've just committed changes to "reunify" the date/time types.
"timestamp" and "interval" are now the two primary date/time types for
users. Also, I've changed the default date style to "ISO" (not just in
time for Y2K, but we'll be ready for "Y3K").
Also, I made some changes to have NUMERIC be a "known" type for
purposes of implicit type coersion, but have not tested to see if the
underlying conversion functions are available.
initdb required (and enforced by a catalog version change).
Regression tests pass, except for the rules test due to ongoing rules
formatting work.
- Thomas
The detailed change log:
Make NUMERIC a known native type for purposes of type coersion. Not
tested.
Make ISO date style (e.g. "2000-02-16 09:33") the default.
Implement "date/time grand unification".
Transform datetime and timespan into timestamp and interval.
Deprecate datetime and timespan, though translate to new types in
gram.y.
Transform all datetime and timespan catalog entries into new types.
Make "INTERVAL" reserved word allowed as a column identifier in
gram.y.
Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as
utility
routines for all date/time types.
date.{h,c} now deals with date, time types.
timestamp.{h,c} now deals with timestamp, interval types.
nabstime.{h,c} now deals with abstime, reltime, tinterval types.
All regression tests pass except for rules.sql (unrelated).
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Wed Feb 16 13:38:27 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA01213
for <hackers@postgreSQL.org>; Wed, 16 Feb 2000 13:38:05 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Svala.DoCS.UU.SE (e99re41@Svala.DoCS.UU.SE [130.238.9.166])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id TAA25478;
Wed, 16 Feb 2000 19:37:58 +0100 (MET)
Received: from localhost (e99re41@localhost) by Svala.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id TAA16737;
Wed, 16 Feb 2000 19:37:57 +0100
X-Authentication-Warning: Svala.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Wed, 16 Feb 2000 19:37:57 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Date/time types: big change
In-Reply-To: <38AAE143.82611E33@alumni.caltech.edu>
Message-ID: <Pine.GSO.4.02A.10002161931360.16403-100000@Svala.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 16 Feb 2000, Thomas Lockhart wrote:
I've just committed changes to "reunify" the date/time types.
"timestamp" and "interval" are now the two primary date/time types for
users. Also, I've changed the default date style to "ISO" (not just in
time for Y2K, but we'll be ready for "Y3K").
I still don't like our Y2038 status. ;)
Anyway, the question I have is what did you do with functions such as
datetimein() or comparison functions and such for the old types? Did you
remove them? What if some, say, user-defined trigger function uses them?
The reason I'm asking is that I would like to see the floating point types
converted to SQL in a similar fashion, but when I rename, say, float4eq to
realeq it might break user applications. Or not? This is all hypothetical
of course.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Wed Feb 16 13:56:25 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 NAA03745
for <hackers@postgreSQL.org>; Wed, 16 Feb 2000 13:56:12 -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
NAA05756;
Wed, 16 Feb 2000 13:55:14 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002161855.NAA05756@candle.pha.pa.us>
Subject: Re: [HACKERS] Date/time types: big changeu
In-Reply-To: <38AAE143.82611E33@alumni.caltech.edu> from Thomas Lockhart at
"Feb 16, 2000 05:41:23 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Wed, 16 Feb 2000 13:55:14 -0500 (EST)
CC: Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I've just committed changes to "reunify" the date/time types.
"timestamp" and "interval" are now the two primary date/time types for
users. Also, I've changed the default date style to "ISO" (not just in
time for Y2K, but we'll be ready for "Y3K").
I think we need a consensus on this. I think this may be a problem for
some people. Comments?
test=> create table x ( y date);
CREATE
test=> insert into x values ('02/01/99');
INSERT 18697 1
test=> select * from x;
y
------------
02-01-1999
(1 row)
test=> set datestyle to 'iso';
SET VARIABLE
test=> select * from x;
y
------------
1999-02-01
(1 row)
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 16 15:31:25 2000
Received: from relayer.zd.com (relayer.zd.com [155.40.130.200])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA10106
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 15:30:38 -0500 (EST)
(envelope-from Timothy_Dyck@zd.com)
Received: from mailer.zd.com ([155.40.32.223])
by relayer.zd.com (PMDF V5.2-32 #37280)
with SMTP id <0FQ100KLCHIBHU@relayer.zd.com> for
pgsql-hackers@postgreSQL.org; Wed, 16 Feb 2000 15:18:28 -0500 (EST)
Received: by mailer.zd.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998))
id 85256887.006F1E0C ; Wed, 16 Feb 2000 15:13:41 -0500
Date: Wed, 16 Feb 2000 15:11:16 -0500
From: Timothy Dyck <Timothy_Dyck@zd.com>
Subject: re: SQL compliance, was Re: [HACKERS] follow-up on PC Week Labs
benchmark results
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Cc: pgsql-hackers@postgreSQL.org
Message-id: <85256887.006F1089.00@mailer.zd.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-disposition: inline
X-Lotus-FromDomain: ZIFF-DAVIS@INET
You had inquired earlier about "when we would support complete SQL92"
(give or take a few words). What areas of entry level SQL92 are we
missing in your opinion (or should we wait for the article)?
Well, what I look for on the language side is complete SQL-92 entry level
compliance, plus common language extensions like outer joins, cast, case,
cube, rollup, a datetime data type, add table constraint and alter table.
Also, I look for a stored procedure language. Basically, parity with the
commercial databases. :)
The key measure I'd look for with SQL compliance is passing the NIST FIPS
127 SQL92 test. NIST discontinued its testing policy, which was a bad thing
for the industry, but the test may still be available from NIST. The spec
itself still is available for free; I ordered a copy a few weeks ago.
-Tim Dyck
From bouncefilter Wed Feb 16 16:26:31 2000
Received: from relayer.zd.com (relayer.zd.com [155.40.130.200])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA19527
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 16:25:54 -0500 (EST)
(envelope-from Timothy_Dyck@zd.com)
Received: from mailer.zd.com ([155.40.32.223])
by relayer.zd.com (PMDF V5.2-32 #37280)
with SMTP id <0FQ100LFKIC702@relayer.zd.com> for
pgsql-hackers@postgreSQL.org; Wed, 16 Feb 2000 15:31:25 -0500 (EST)
Received: by mailer.zd.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998))
id 85256887.0070C2CB ; Wed, 16 Feb 2000 15:31:38 -0500
Date: Wed, 16 Feb 2000 15:25:15 -0500
From: Timothy Dyck <Timothy_Dyck@zd.com>
Subject: PC Week PostgreSQL benchmark results posted online
To: pgsql-hackers@postgreSQL.org
Message-id: <85256887.0070C00B.00@mailer.zd.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-disposition: inline
X-Lotus-FromDomain: ZIFF-DAVIS@INET
FYI, the story is available online at:
http://www.zdnet.com/pcweek/stories/news/0,4153,2436153,00.html
As I think I have mentioned, I would like to review PostgreSQL 7.0 when it
goes gold, so if someone could let me know when it is available, that
would be much appreciated.
Regards,
Tim Dyck
Senior Analyst
PC Week Labs
From bouncefilter Wed Feb 16 17:09:26 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 RAA46387
for <hackers@postgreSQL.org>; Wed, 16 Feb 2000 17:09:21 -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 RAA04551;
Wed, 16 Feb 2000 17:09:08 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Date/time types: big changeu
In-reply-to: <200002161855.NAA05756@candle.pha.pa.us>
References: <200002161855.NAA05756@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Wed, 16 Feb 2000 13:55:14 -0500"
Date: Wed, 16 Feb 2000 17:09:08 -0500
Message-ID: <4548.950738948@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Also, I've changed the default date style to "ISO" (not just in
time for Y2K, but we'll be ready for "Y3K").
I think we need a consensus on this. I think this may be a problem for
some people. Comments?
Good point. Perhaps there should be a way to select the default date
style at configure or initdb time. I don't mind if the "default default"
is ISO, but if I had apps that were dependent on the old default setting
I'd sure be annoyed by this change...
Has anyone thought much about the fact that beginning next year,
heuristics to guess which field is the year will become nearly useless?
Quick, when is '01/02/03'? I suspect a lot of people who got away with
not thinking hard about datestyles will suddenly realize that they need
to set the default datestyle to whatever they are accustomed to using.
regards, tom lane
From bouncefilter Wed Feb 16 17:05:26 2000
Received: from hu.tm.ee (ppp799.tele2.ee [212.107.37.99])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA45756
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 17:04:35 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1])
by hu.tm.ee (Postfix) with ESMTP id 750AA3A41
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 00:12:43 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38AB20DA.EAA7B9B6@tm.ee>
Date: Thu, 17 Feb 2000 00:12:42 +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" <pgsql-hackers@postgreSQL.org>
Subject: FYI: BNF for SQL93 and SQL-3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Doing a Google search for SQL standards, I found a
wonderful page of links to SQL info, including the BNF
specs for SQL92 and SQL3. Not exactly gram.y but hopefully
close.
Could be helpful in deciphering what the standards say.
See: http://www.contrib.andrew.cmu.edu/~shadow/sql.html
---------
Hannu
From bouncefilter Wed Feb 16 17:15:26 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 RAA47239
for <hackers@postgreSQL.org>; Wed, 16 Feb 2000 17:14:54 -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
RAA14254;
Wed, 16 Feb 2000 17:13:42 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002162213.RAA14254@candle.pha.pa.us>
Subject: Re: [HACKERS] Date/time types: big changeu
In-Reply-To: <4548.950738948@sss.pgh.pa.us> from Tom Lane at "Feb 16,
2000 05:09:08 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed, 16 Feb 2000 17:13:42 -0500 (EST)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Also, I've changed the default date style to "ISO" (not just in
time for Y2K, but we'll be ready for "Y3K").I think we need a consensus on this. I think this may be a problem for
some people. Comments?Good point. Perhaps there should be a way to select the default date
style at configure or initdb time. I don't mind if the "default default"
is ISO, but if I had apps that were dependent on the old default setting
I'd sure be annoyed by this change...Has anyone thought much about the fact that beginning next year,
heuristics to guess which field is the year will become nearly useless?
Quick, when is '01/02/03'? I suspect a lot of people who got away with
not thinking hard about datestyles will suddenly realize that they need
to set the default datestyle to whatever they are accustomed to using.
Wow, that is an excellent point. I was doing it for 2000, and was
thinking, gee, that's not too hard. I can see it getting much more
confusing next year, as you said.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 16 17:31:27 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 RAA49830;
Wed, 16 Feb 2000 17:30:34 -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
RAA14635;
Wed, 16 Feb 2000 17:29:33 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002162229.RAA14635@candle.pha.pa.us>
Subject: Re: [HACKERS] FYI: BNF for SQL93 and SQL-3
In-Reply-To: <38AB20DA.EAA7B9B6@tm.ee> from Hannu Krosing at "Feb 17,
2000 00:12:42 am"
To: Hannu Krosing <hannu@tm.ee>
Date: Wed, 16 Feb 2000 17:29:33 -0500 (EST)
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>,
webmaster@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Doing a Google search for SQL standards, I found a
wonderful page of links to SQL info, including the BNF
specs for SQL92 and SQL3. Not exactly gram.y but hopefully
close.Could be helpful in deciphering what the standards say.
This is terrific. We need this on our web page.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 16 17:47:27 2000
Received: from acheron.rime.com.au (root@albatr.lnk.telstra.net
[139.130.54.222]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA51964
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 17:47:24 -0500 (EST)
(envelope-from pjw@rhyme.com.au)
Received: from oberon (Oberon.rime.com.au [203.8.195.100])
by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id JAA00977;
Thu, 17 Feb 2000 09:33:31 +1100
Message-Id: <3.0.5.32.20000217093443.03588e50@mail.rhyme.com.au>
X-Sender: pjw@mail.rhyme.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 17 Feb 2000 09:34:43 +1100
To: Tom Lane <tgl@sss.pgh.pa.us>
From: Philip Warner <pjw@rhyme.com.au>
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Cc: "Hiroshi Inoue" <Inoue@tpf.co.jp>, pgsql-hackers@postgreSQL.org
In-Reply-To: <2920.950715815@sss.pgh.pa.us>
References: <3.0.5.32.20000215190809.034d1b10@mail.rhyme.com.au>
<000301bf774f$feb8aa20$2801007e@tpf.co.jp>
<000301bf774f$feb8aa20$2801007e@tpf.co.jp>
<3.0.5.32.20000215190809.034d1b10@mail.rhyme.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 10:43 16/02/00 -0500, Tom Lane wrote:
Philip Warner <pjw@rhyme.com.au> writes:
A possible answer is to define OFFSET/LIMIT in DECLARE CURSOR as
being simply a hint to the optimizer about how much of the query
result will actually get fetched.This seems a good approach until cursors are fixed. But is there a plan to
make cursors support LIMIT properly? Do you know why they ignore the LIMIT
clause?Should they obey LIMIT? MOVE/FETCH seems like a considerably more
flexible interface, so I'm not quite sure why anyone would want to
use LIMIT in a cursor.
I agree; but see below.
Still, it seems kind of inconsistent that cursors ignore LIMIT.
I don't know for sure why it was done that way.
It's the inconsistency that bothers me: if I run a SELECT statement, then
put it in a cursor, I should get the same rows returned. Ths current
behaviour should probably be considered a bug.
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
From bouncefilter Wed Feb 16 17:59:27 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 RAA53232;
Wed, 16 Feb 2000 17:58:30 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (max03-073.enterprise.net [194.72.196.73])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id WAA15044;
Wed, 16 Feb 2000 22:58:14 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 XAA21280;
Wed, 16 Feb 2000 23:00:44 GMT
Message-Id: <200002162300.XAA21280@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)
X-URL: http://www.lfix.co.uk/oliver
X-face:
"xUFVDj+ZJtL_IbURmI}!~xAyPC"Mrk=MkAm&tPQnNq(FWxv49R}\>0oI8VM?O2VY+N7@F-
KMLl*!h}B)u@TW|B}6<X<J|}QsVlTi:RA:O7Abc(@D2Y/"J\S,
b1!<&<B/J}b.Ii9@B]H6V!+#sE0Q
_+=`K$5TI|4I0-=Cp%pt~L#QYydO'iBXR~\tT?uftep9n9AF`@SzTwsw6uqJ}pL,
h(cZi}T#PB"#!k
p^e=Z.K~fuw$l?]lUV)?R]U}l; f*~Ol)#fpKR)Yt}XOr6BI\_Jjr0!@GMnpCTnTym4f; c{;
Ms=0{`D Lq9MO6{wj%s-*N"G,g
To: pgsql-hackers@postgresql.org, pgsql-interfaces@postgresql.org
cc: Constantin Teodorescu <teo@flex.ro>
Subject: pgaccess and multibyte-enabled libpq
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 16 Feb 2000 23:00:42 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
I sent this report to Constantin Teodorescu, as author of pgaccess,
but it now occurs to me that it is probably something to be handled
in libpgtcl instead.
---------------------------------------------------------------------
I have had a bug-report on pgaccess (from PostgreSQL 6.5.3) when used
with multi-byte encoding and with Tcl 8.2.
Your website says that Tcl/Tk 8.0 or higher is needed.
However, there are problems with multibyte-encoding with Tcl8.2 and
I don't see any reference to this in "What's New".
At 8.1, Tcl introduced internationalisation. Everything is reduced
to Unicode internally. If someone uses pgaccess with (say) KOI-8 as
the default encoding for the whole machine, and with a database that
uses KOI-8 encoding, Tcl translates KOI-8 user input to Unicode before
using the data. It then sends the data to the backend in UNICODE, but
does not tell the backend that this is what is happening.
The user may have PGCLIENTENCODING set to KOI8, or may be depending on
his default environment, but Tcl is doing its own thing.
I think that pgaccess needs to translate back to the native encoding
before it sends data to the backend; it also needs to translate data
from the backend to Unicode before using or displaying it.
---------------------------------------------------------------------
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"But as many as received him, to them gave he power to
become the sons of God, even to them that believe on
his name" John 1:12
From bouncefilter Wed Feb 16 18:18:28 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 SAA56207
for <hackers@postgreSQL.org>; Wed, 16 Feb 2000 18:17:53 -0500 (EST)
(envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (max01-072.enterprise.net [194.72.195.72])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id XAA18526;
Wed, 16 Feb 2000 23:17:48 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 XAA27647;
Wed, 16 Feb 2000 23:20:26 GMT
Message-Id: <200002162320.XAA27647@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)
X-URL: http://www.lfix.co.uk/oliver
X-face:
"xUFVDj+ZJtL_IbURmI}!~xAyPC"Mrk=MkAm&tPQnNq(FWxv49R}\>0oI8VM?O2VY+N7@F-
KMLl*!h}B)u@TW|B}6<X<J|}QsVlTi:RA:O7Abc(@D2Y/"J\S,
b1!<&<B/J}b.Ii9@B]H6V!+#sE0Q
_+=`K$5TI|4I0-=Cp%pt~L#QYydO'iBXR~\tT?uftep9n9AF`@SzTwsw6uqJ}pL,
h(cZi}T#PB"#!k
p^e=Z.K~fuw$l?]lUV)?R]U}l; f*~Ol)#fpKR)Yt}XOr6BI\_Jjr0!@GMnpCTnTym4f; c{;
Ms=0{`D Lq9MO6{wj%s-*N"G,g
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Date/time types: big changeu
In-reply-to: Message from Tom Lane <tgl@sss.pgh.pa.us>
of Wed, 16 Feb 2000 17:09:08 EST. <4548.950738948@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: multipart/mixed ;
boundary="==_Exmh_-16810423740"
Date: Wed, 16 Feb 2000 23:20:26 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
This is a multipart MIME message.
--==_Exmh_-16810423740
Content-Type: text/plain; charset=us-ascii
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Also, I've changed the default date style to "ISO" (not just in
time for Y2K, but we'll be ready for "Y3K").I think we need a consensus on this. I think this may be a problem for
some people. Comments?Good point. Perhaps there should be a way to select the default date
style at configure or initdb time. I don't mind if the "default default"
is ISO, but if I had apps that were dependent on the old default setting
I'd sure be annoyed by this change...Has anyone thought much about the fact that beginning next year,
heuristics to guess which field is the year will become nearly useless?
Quick, when is '01/02/03'? I suspect a lot of people who got away with
not thinking hard about datestyles will suddenly realize that they need
to set the default datestyle to whatever they are accustomed to using.
I have code to let the installer choose the default datestyle in Debian's installation script for PostgreSQL. It makes its own best guess on
the basis of the timezone and then asks the user with its own guess as
the presented default.
See the attached script; I don't know how generalisable the timezone
guessing would be.
--==_Exmh_-16810423740
Content-Type: text/plain ; name="postinst"; charset=us-ascii
Content-Description: postinst
Content-Disposition: attachment; filename="postinst"
#!/bin/sh
set -e
# postgresql Debian package - post-installation script
#
guessdatestyle() {
# Guess the postgresql datestyle to use for a given timezone (from glibc)
# make sure TZ is set and exported
TZ=`cat /etc/timezone`
export TZ
# find the timezone offset from UTC
tzno=`date '+%z'`
# Find the name of the zone - strip off unwanted header directories
x=`echo $TZ | cut -d/ -f1`
case $x in SystemV | posix | right )
x=`echo $TZ | cut -d/ -f2-4`
;;
* )
x=$TZ
;;
esac
# What country does this zone belong to (if undefined, set it to __)
tzcountry=`grep $x /usr/share/zoneinfo/zone.tab | head -1 | cut -c1-2`
if [ -z "$tzcountry" ]
then
tzcountry=__
fi
# Guess the timezone
case $tzcountry in US )
# US date format
GuessDateStyle=US
;;
AR )
# Argentina
GuessDateStyle=SQL
;;
CA )
# Canada has no standard
GuessDateStyle=ISO
;;
DE )
# Germany has a style to itself
GuessDateStyle=GERMAN
;;
__ )
# No country, so see if the zone is a region or country name
x=$TZ
while echo $x | grep -q /
do
y=`dirname $x`
case $y in SystemV | posix | right )
y=`basename $x`
;;
esac
x=$y
done
case $x in Africa | Canada | Indian | Mexico | America | Chile | GB | Iran | Mideast | Antarctica | Cuba | Israel | NZ | Singapore | Arctic | Jamaica | Asia | Japan | Navajo | Turkey | Atlantic | Kwajalein | Australia | Egypt | Libya | US | Brazil | Eire | Pacific | Hongkong | Poland | Europe | Iceland | Portugal)
# try to guess the zone from the UTC offset and
# the zone abbreviation
if [ -z "$GuessDateStyle" ]
then
GuessDateStyle=EURO
if [ "$LANG" = de_DE ]
then
GuessDateStyle=GERMAN
elif [ $tzno -le -200 -a $tzno -gt -1200 ]
then
tzn=`date '+%Z'`
case $tzn in ADT | AST | AKDT | AKST | CDT | CST | EDT | EST | HADT | HAST | HST | MDT | MST | NDT | PDT | PST)
GuessDateStyle=US
;;
esac
fi
fi
;;
* )
# Not a country or region so use ISO
GuessDateStyle=ISO
;;
esac
;;
* )
# The rest of the world uses normal European format
GuessDateStyle=EURO
;;
esac
}
# Put the ~/.profile in the postgres home directory
# If there is not already a database, create one
SHELL=/bin/sh
TMPFILE=`mktemp /tmp/pg.XXXXXX` || exit 1
trap "rm -f ${TMPFILE}" 0
. /etc/postgresql/postmaster.init
# If the preinst script set the flag file (that points PGDATA to
# /var/postgres/data), read it and then delete it.
if [ -f /var/lib/postgres/dpkg-postinst-flag ]
then
. /var/lib/postgres/dpkg-postinst-flag
rm /var/lib/postgres/dpkg-postinst-flag
cp /etc/postgresql/postmaster.init ${TMPFILE}
sed "/^# POSTGRES_DATA=/s|^.*$|POSTGRES_DATA=${POSTGRES_DATA}|" <${TMPFILE} >/etc/postgresql/postmaster.init
${TMPFILE}
fi
PGDATA=${POSTGRES_DATA:=/var/lib/postgres/data}
PGBASE=/usr/lib/postgresql
PGLIB=${PGBASE}/lib
PATH=${PATH}:${PGBASE}/bin
export PGDATA PGLIB PATH
PGHOME=${POSTGRES_HOME:=`dirname ${PGDATA}`}
if [ `dirname $PGHOME` = / ]
then
echo -n "In /etc/postgresql/postmaster.init, POSTGRES_HOME is configured as
$PGHOME, which is unacceptable! (If POSTGRES_HOME is not defined,
it is set to the parent directory of POSTGRES_DATA.)
POSTGRES_HOME should be at least two levels below /, and POSTGRES_DATA
should be at least 3 levels below /.
Press return to continue "
read x
exit 1
fi
if [ ! -d "${PGHOME}" -a ! -f "${PGHOME}" ]
then
echo Creating missing home directory ${PGHOME} for postgres
install -m 700 -o postgres -g postgres -d ${PGHOME}
fi
if [ ! -d "${PGHOME}" ]
then
echo Cannot create home directory ${PGHOME} for postgres
exit 1
fi
# Make sure that /etc/passwd's home directory exists
PSWDHOME=`grep 'postgres:' /etc/passwd | cut -f6 -d:`
if [ ! -e ${PSWDHOME} ]
then
echo "The home directory given for postgres in /etc/passwd (${PSWDHOME})"
echo does not exist
echo "(Home directory from /etc/postgresql/postmaster.init is ${PGHOME})"
exit 1
fi
if [ ${PSWDHOME} != ${PGHOME} ]
then
echo Home directory for postgres in /etc/passwd is ${PSWDHOME}
echo Home directory from /etc/postgresql/postmaster.init is ${PGHOME}
echo -n Press the return key to continue
read x
fi
PGSHELL=`grep -s '^postgres:' /etc/passwd | awk -F: '{print $7}'`
if [ -z "${PGSHELL}" ]
then
PGSHELL=/bin/sh
fi
PGSHELL=`basename ${PGSHELL}`
case ${PGSHELL} in
bash)
PROFILE=.bash_profile
;;
sh | ksh)
PROFILE=.profile
;;
csh | tcsh)
PROFILE=.login
;;
*)
PROFILE=.profile
;;
esac
install -m 700 -o postgres -g postgres -d ${PGDATA}
grep -q -s postmaster.init ${PGHOME}/${PROFILE} ||
(echo Updating ${PGHOME}/${PROFILE} ...
echo . /etc/postgresql/postmaster.init >>${PGHOME}/${PROFILE}
if [ ${PROFILE} = .login ]
then
# C-shell syntax...
echo setenv PATH /bin:/usr/bin:${PGBASE}/bin >>${PGHOME}/${PROFILE}
echo setenv PGDATA \${POSTGRES_DATA:-/var/lib/postgres/data} >>${PGHOME}/${PROFILE}
echo setenv PGLIB ${PGLIB} >>${PGHOME}/${PROFILE}
else
echo PATH=/bin:/usr/bin:${PGBASE}/bin >>${PGHOME}/${PROFILE}
echo PGDATA=\${POSTGRES_DATA:-/var/lib/postgres/data} >>${PGHOME}/${PROFILE}
echo PGLIB=${PGLIB} >>${PGHOME}/${PROFILE}
echo export PGLIB PGDATA >>${PGHOME}/${PROFILE}
fi)
chown -R postgres.postgres ${PGDATA} ${PGHOME} /var/lib/postgres /var/run/postgresql
chmod 755 /var/run/postgresql
chmod 700 ${PGDATA}
# Make sure we have the shared library (from libpgsql)
if [ ! -f /usr/lib/libpq.so.2 ]
then
echo The shared library /usr/lib/libpq.so.2 is not present. Package
echo libpgsql must be installed before we can continue.
exit 1
fi
if [ ! -f ${PGDATA}/PG_VERSION ]
then
echo "PostgreSQL databases can be created with any one of a number of different
character encodings. Please choose the default encoding, which will be used
for all newly-created databases in the absence of a specific encoding
specification. The choices are:
SQL_ASCII ASCII
EUC_JP Japanese EUC
EUC_CN Chinese EUC
EUC_KR Korean EUC
EUC_TW Taiwan EUC
UNICODE Unicode(UTF-8)
MULE_INTERNAL Mule internal
LATIN1 ISO 8859-1 English and some European languages
LATIN2 ISO 8859-2 English and some European languages
LATIN3 ISO 8859-3 English and some European languages
LATIN4 ISO 8859-4 English and some European languages
LATIN5 ISO 8859-5 English and some European languages
KOI8 KOI8-R
WIN Windows CP1251
ALT Windows CP866
"
ok=
while [ -z "$ok" ]
do
echo -n "Enter default encoding (UNICODE): "
read Encoding
if [ -z "${Encoding}" ]
then
Encoding=UNICODE
fi
case ${Encoding} in SQL_ASCII | EUC_JP | EUC_CN | EUC_KR | EUC_TW | UNICODE | MULE_INTERNAL | LATIN1 | LATIN2 | LATIN3 | LATIN4 | LATIN5 | KOI8 | WIN | ALT )
ok=true
;;
*)
echo Invalid response, choose one of SQL_ASCII EUC_JP EUC_CN EUC_KR EUC_TW UNICODE MULE_INTERNAL LATIN1 LATIN2 LATIN3 LATIN4 LATIN5 KOI8 WIN ALT
;;
esac
done
echo Now installing the PostgreSQL database files in ${PGDATA}
echo su postgres -c "cd ${PGHOME}; . ./${PROFILE}; initdb -e ${Encoding} -l ${PGLIB} -r ${PGDATA} -u postgres"
su postgres -c "cd ${PGHOME}; . ./${PROFILE}; initdb -e ${Encoding} -l ${PGLIB} -r ${PGDATA} -u postgres"
echo PostgreSQL database now installed.
echo Use /usr/bin/createdb to create a specific database and
echo /usr/bin/createuser to enable other users to connect to a
echo PostgreSQL database.
echo
echo In the first instance, these commands must be run by the
echo user \'postgres\'.
echo
fi
if [ "$1" = configure ]
then
if [ -z "$2" -o "$2" = "<unknown>" ]
then
guessdatestyle
cp /etc/postgresql/postmaster.init ${TMPFILE}
echo "The date style affects how dates, times and timezone information is
presented to the user; the backend has a default setting, though the user can
override it in any session. These are the available date styles:
Style Date Datetime
-------------------------------------------------------
ISO 1999-07-17 1999-07-17 07:09:18+01
SQL 17/07/1999 17/07/1999 07:09:19.00 BST
POSTGRES 17-07-1999 Sat 17 Jul 07:09:19 1999 BST
GERMAN 17.07.1999 17.07.1999 07:09:19.00 BST
NONEURO 07-17-1999 Sat Jul 17 07:09:19 1999 BST
US 07-17-1999 Sat Jul 17 07:09:19 1999 BST
EURO 17-07-1999 Sat 17 Jul 07:09:19 1999 BST"
ok=
while [ -z "$ok" ]
do
echo -n "Choose your default date style ($GuessDateStyle): "
read ans
if [ -z "$ans" ]
then
ans=$GuessDateStyle
fi
case $ans in
ISO|SQL|POSTGRES|GERMAN|NONEURO|US|EURO)
sed -e "/PGDATESTYLE/s/^.*$/PGDATESTYLE=$ans/" <${TMPFILE} \
/etc/postgresql/postmaster.init
ok=true
;;
*)
echo "Invalid response ($ans);
answer must be one of ISO SQL POSTGRES GERMAN NONEURO US EURO"
;;
esac
done
rm ${TMPFILE}
fi
fi
# Make a symbolic link to the authorisation file
if [ ! -L ${PGDATA}/pg_hba.conf ]
then
ln -sf /etc/postgresql/pg_hba.conf ${PGDATA}/pg_hba.conf
fi
# Make a symbolic link to the ident map
if [ ! -L ${PGDATA}/pg_ident.conf ]
then
ln -sf /etc/postgresql/pg_ident.conf ${PGDATA}/pg_ident.conf
fi
echo
echo The file /etc/postgresql/postgresql.env provides the normal set-up for
echo an ordinary user running PostgreSQL. It is automatically read by the
echo wrapper script for PostgreSQL user commands.
echo
#
# We may need to tidy up /etc/crontab from previous violations of policy
if grep -qs '^#-- postgresql begin *$' /etc/crontab
then
TMP=`mktemp /tmp/pg.XXXXXX` || exit 1
awk 'BEGIN {found=0}
/^#-- postgresql begin *$/ {found = 1}
/^#-- postgresql end *$/ {found = -1}
{if (!found) print}
{if (found == -1) found=0}
END {if (found) exit 1}' /etc/crontab >$TMP &&
if [ -f $TMP ]
then
mv $TMP /etc/crontab
fi
fi
# Make sure the log file exists with the correct ownership
LOGFILE=${POSTGRES_LOG:-/var/log/postgres.log}
touch $LOGFILE
chown postgres.postgres $LOGFILE
#
# These bits would be added by debhelper if we didn't need to tweak the
# last item
update-rc.d postgresql defaults >/dev/null
set +e
/etc/init.d/postgresql restart ||
if [ $? -ne 255 ]
then
exit $?
fi
# Only do the next bit if the postmaster is running
if ps --User postgres | grep -v grep | grep -q postmaster
then
# take a little nap while the postmaster sorts itself out
sleep 5
#
# set usecatupd to false for all users except superusers
# set it to true for superusers (temporary expedient at 6.5.1-4)
(
cd $PGHOME
su postgres -c "psql -c \"update pg_shadow set usecatupd = 'f' where usesuper = 'f'\" template1"
su postgres -c "psql -c \"update pg_shadow set usecatupd = 't' where usesuper = 't'\" template1"
)
fi
if [ "$1" = "configure" ]
then
if [ -d /usr/doc -a ! -e /usr/doc/postgresql -a -d /usr/share/doc/postgresql ]
then
ln -sf ../share/doc/postgresql /usr/doc/postgresql
fi
fi
exit 0
--==_Exmh_-16810423740
Content-Type: text/plain; charset=us-ascii
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"But as many as received him, to them gave he power to
become the sons of God, even to them that believe on
his name" John 1:12
--==_Exmh_-16810423740--
From bouncefilter Wed Feb 16 18:16:26 2000
Received: from hu.tm.ee (ppp760.tele2.ee [212.107.37.60])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA55977
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 18:16:19 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1])
by hu.tm.ee (Postfix) with ESMTP id CAAF23B5A
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 01:24:24 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38AB31A8.BBF76824@tm.ee>
Date: Thu, 17 Feb 2000 01:24:24 +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" <pgsql-hackers@postgreSQL.org>
Subject: FYI: OO features of Oracle 8 and Informix
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I also found a comparison of current (as of may-June 98 ;) OO support
for the big guys
http://galaxy.uci.agh.edu.pl/~vahe/orcl_inf.htm
Most links to www.oracle.com at the bottom are to pages saying :
"An application error has occured. Please try again." ;-p
-------------
Hannu
From bouncefilter Wed Feb 16 18:26:34 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA57160
for <pgsql-hackers@postgresql.org>;
Wed, 16 Feb 2000 18:25:40 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62389 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S5209AbQBPXYu>;
Thu, 17 Feb 2000 00:24:50 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12LDqw-0000dq-00
for pgsql-hackers@postgresql.org; Thu, 17 Feb 2000 00:27:26 +0100
Date: Thu, 17 Feb 2000 00:27:26 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Maximum columns for optimum performance (fwd)
Message-ID: <Pine.LNX.4.21.0002170026540.1328-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
Can anybody comment on this?
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
---------- Forwarded message ----------
Date: Wed, 16 Feb 2000 11:16:48 -0600
From: Jude Weaver <exec@shreve.net>
To: Peter Eisentraut <peter_e@gmx.net>
Subject: Maximum columns for optimum performance
One of our tables have 476 columns and only 12 records or rows in it. We are
coding in Java. When we compile and run against this table it is super slow.
Is there a maximum number of columns past which performance suffers? Would we
be better off building several smaller tables with fewer columns instead of
one big table? Does the number of columns in a table affect speed?
From bouncefilter Wed Feb 16 18:38:27 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 SAA58675
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 18:37:29 -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
SAA18813;
Wed, 16 Feb 2000 18:36:15 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002162336.SAA18813@candle.pha.pa.us>
Subject: psql password prompt
In-Reply-To: <200002162315.PAA19810@james.com> from Scott Williams at "Feb 16,
2000 03:15:59 pm"
To: Scott Williams <scott@james.com>
Date: Wed, 16 Feb 2000 18:36:15 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Peter E. can you look at this? I see simple prompt doing:
fputs(prompt, stdout);
which I think should be stderr. Peter, can you check on those?
Does it still make sense to send the following to
pgsql-bugs@postgresql.org?- Scott Williams
Subject: pg_dump -u prompts for username/password on stdout rather than stderr
----------------------------------------------------------------------
Your name : Scott Williams
Your email address : Scott@James.comSystem Configuration
---------------------
Architecture (example: Intel Pentium) : i586
Operating System (example: Linux 2.0.26 ELF) : Linux 2.2.10
PostgreSQL version (example: PostgreSQL-6.5.3): PostgreSQL-6.5.3
Compiler used (example: gcc 2.8.0) : egcs-2.91.66 19990314 (egcs-1.1.2 release)Please enter a FULL description of your problem:
------------------------------------------------When running pg_dump with the -u switch, it prompts me on stdout for
the username and password, rather than stderr. Unfortunately this
causes a bit of confusion when doingpg_dump -o -u some_db >dump_file
since it puts the prompt in the dump_file rather than to the screen,
making dump_file syntacticly invalid. Of course the work around is
to use the `-f' flag. However, redirecting pg_dump's stdout to a
file using `>' is what's shown under `Usage' in the pg_dump chapter
of the `PostgreSQL User's Guide'Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
----------------------------------------------------------------------If you know how this problem might be fixed, list the solution below:
---------------------------------------------------------------------
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 16 18:46:27 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 SAA59839
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 18:46:10 -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 IAA02637; Thu, 17 Feb 2000 08:45:13 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>, "Philip Warner" <pjw@rhyme.com.au>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Solution for LIMIT cost estimation
Date: Thu, 17 Feb 2000 08:51:21 +0900
Message-ID: <000401bf78d8$ba187fa0$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: <2920.950715815@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]Philip Warner <pjw@rhyme.com.au> writes:
A possible answer is to define OFFSET/LIMIT in DECLARE CURSOR as
being simply a hint to the optimizer about how much of the query
result will actually get fetched.This seems a good approach until cursors are fixed. But is
there a plan to
make cursors support LIMIT properly? Do you know why they
ignore the LIMIT
clause?
Should they obey LIMIT? MOVE/FETCH seems like a considerably more
flexible interface, so I'm not quite sure why anyone would want to
use LIMIT in a cursor.
You are right.
What I want is to tell optimizer the hint whether all_rows(total throughput)
is needed or first_rows(constant response time) is needed.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Wed Feb 16 19:36:27 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 TAA66261
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 19:36:18 -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 JAA02660 for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 09:36:16 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: create database doesn't work well in MULTIBYTE mode
Date: Thu, 17 Feb 2000 09:42:24 +0900
Message-ID: <000501bf78df$dbb55f00$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
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Hi
I have a crash while creating regression database in pararell regression
test.
Seems it's due to the following change.
@@ -2638,7 +2705,14 @@
n->dbname = $3;
n->dbpath = $5;
#ifdef MULTIBYTE
- n->encoding = $6;
+ if ($6 != NULL) {
+ n->encoding = pg_char_to_encoding($6);
+ if (n->encoding < 0) {
+ elog(ERROR, "Encoding name '%s' is invalid", $6);
+ }
+ } else {
+ n->encoding = GetTemplateEncoding();
+ }
#else
n->encoding = 0;
#endifWhy ?
$6 is an ival not an str.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Wed Feb 16 20:39:29 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 UAA92328
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 20:38:48 -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 UAA05259;
Wed, 16 Feb 2000 20:38:38 -0500 (EST)
To: Jude Weaver <exec@shreve.net>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Maximum columns for optimum performance (fwd)
In-reply-to: <Pine.LNX.4.21.0002170026540.1328-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0002170026540.1328-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Thu, 17 Feb 2000 00:27:26 +0100"
Date: Wed, 16 Feb 2000 20:38:38 -0500
Message-ID: <5256.950751518@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> forwards:
One of our tables have 476 columns and only 12 records or rows in it. We are
coding in Java. When we compile and run against this table it is super slow.
Is there a maximum number of columns past which performance suffers?
What exactly are you finding to be super slow? It's hard to tell from
this report whether the performance problem is in the backend or the
Java client interface (or even in your application code...)
While I can think of places that have loops over columns, I wouldn't
have thought that any of them are remarkably time-critical. It
probably depends on just what sort of query you are doing ... so a
specific example of a slow query would be helpful, along with the
details of the table declaration.
regards, tom lane
From bouncefilter Wed Feb 16 21:38:29 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id VAA05020
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 21:37:42 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
NAA26380 for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 13:37:08 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0kxOyC;
Thu Feb 17 13:37:00 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
NAA27701 for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 13:36:59 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdn.VlM_; Thu Feb 17 13:36:27 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id NAA11668
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 13:36:26 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
NAA12998 for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 13:35:45 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38AB5E48.CD2282E5@nimrod.itg.telecom.com.au>
Date: Thu, 17 Feb 2000 13:34:48 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] FYI: BNF for SQL93 and SQL-3
References: <38AB20DA.EAA7B9B6@tm.ee>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hannu Krosing wrote:
Doing a Google search for SQL standards, I found a
wonderful page of links to SQL info, including the BNF
specs for SQL92 and SQL3. Not exactly gram.y but hopefully
close.
How official is this? I get the feeling this might
be one guy's interpretation because it seems like
it is missing stuff.
From bouncefilter Wed Feb 16 21:32:29 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 VAA03840;
Wed, 16 Feb 2000 21:32:06 -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 LAA02738; Thu, 17 Feb 2000 11:31:15 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>,
"Thomas Lockhart" <lockhart@alumni.caltech.edu>
Cc: "Michael Meskes" <meskes@postgreSQL.org>,
"PostgreSQL Hacker" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] ERROR: Unable to identify an operator '=' for types
'numeric' and 'float8'
Date: Thu, 17 Feb 2000 11:37:23 +0900
Message-ID: <000601bf78ef$ebc90580$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: <2614.950712368@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 LaneThomas Lockhart <lockhart@alumni.caltech.edu> writes:
One hesitation I have is the performance hit in mixing FLOAT and
NUMERIC; I (probably) don't want to make NUMERIC the "best" numeric
type, since it is potentially so slow.I concur --- I'd be inclined to leave FLOAT8 as the top of the
hierarchy. But NUMERIC could be stuck in there between int and float,
no? (int-vs-numeric ops certainly must be promoted to numeric...)
Is this topic related to the fact that 1.1 is an FLOAT8 constant in
PostgreSQL ?
I've not understood at all why it's OK.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Wed Feb 16 21:42:29 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id VAA06025
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 21:42:21 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
NAA00032 for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 13:41:49 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0LUmwa;
Thu Feb 17 13:41:28 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
NAA02895 for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 13:41:28 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0YqQ_D; Thu Feb 17 13:40:49 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id NAA15037
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 13:40:48 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
NAA13094 for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 13:40:07 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38AB5F4E.AD384832@nimrod.itg.telecom.com.au>
Date: Thu, 17 Feb 2000 13:39:10 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: psql problem
References: <200002162336.SAA18813@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I was noticing that psql now exits on ctrl-C. This is much
better than the previous behaviour where it kinda got
muddled up and you could destroy your database if
a half-completed command was in its buffer.
But wouldn't it be better if it was like /bin/sh and
popped you back to a fresh prompt or something?
From bouncefilter Wed Feb 16 22:12: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 WAA12840;
Wed, 16 Feb 2000 22:12:20 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12LHCo-0003kgC; Thu, 17 Feb 100 04:02 MET
Message-Id: <m12LHCo-0003kgC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] ERROR: Unable to identify an operator '=' for types
'numeric' and 'float8'
In-Reply-To: <000601bf78ef$ebc90580$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Feb 17, 2000 11:37:23 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Thu, 17 Feb 2000 04:02:14 +0100 (CET)
CC: Tom Lane <tgl@sss.pgh.pa.us>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Reply-To: Jan Wieck <wieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset iso-2022-jp unsupported, skipping...]
:-{
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom LaneThomas Lockhart <lockhart@alumni.caltech.edu> writes:
One hesitation I have is the performance hit in mixing FLOAT and
NUMERIC; I (probably) don't want to make NUMERIC the "best" numeric
type, since it is potentially so slow.I concur --- I'd be inclined to leave FLOAT8 as the top of the
hierarchy. But NUMERIC could be stuck in there between int and float,
no? (int-vs-numeric ops certainly must be promoted to numeric...)Is this topic related to the fact that 1.1 is an FLOAT8 constant in
PostgreSQL ?
I've not understood at all why it's OK.
IMHO a value floating around should be kept NUMERIC or in
it's string representation until it's finally clear where it
is dropped (int2/4/8, float4/8, numeric or return to client).
This surely has an impact on performance, but from my PoV
beeing correct has a higher priority. If you want
performance, buy well sized hardware depending on application
and workload. If you want reliability, choose the right
software.
Don't force it, use a bigger hammer!
Jan
BTW: I still intend to redo the NUMERIC type somewhere in the
future. Just haven't found the time though.
--
#======================================================================#
# 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 Feb 16 22:24: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 WAA15859;
Wed, 16 Feb 2000 22:24:14 -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 WAA13033;
Wed, 16 Feb 2000 22:23:46 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "Thomas Lockhart" <lockhart@alumni.caltech.edu>,
"Michael Meskes" <meskes@postgreSQL.org>,
"PostgreSQL Hacker" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ERROR: Unable to identify an operator '=' for types
'numeric' and 'float8'
In-reply-to: <000601bf78ef$ebc90580$2801007e@tpf.co.jp>
References: <000601bf78ef$ebc90580$2801007e@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Thu, 17 Feb 2000 11:37:23 +0900"
Date: Wed, 16 Feb 2000 22:23:46 -0500
Message-ID: <13030.950757826@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
I concur --- I'd be inclined to leave FLOAT8 as the top of the
hierarchy. But NUMERIC could be stuck in there between int and float,
no? (int-vs-numeric ops certainly must be promoted to numeric...)
Is this topic related to the fact that 1.1 is an FLOAT8 constant in
PostgreSQL ?
No, not directly. At least I don't think the question of how constants
are handled forces our decision about which direction the default
promotion should go.
I've not understood at all why it's OK.
There's a really, really crude hack in scan.l that prevents a long
numeric constant from being converted to FLOAT8. Otherwise we'd lose
precision from making the value float8 and later converting it to
numeric (after type analysis had discovered the necessity for it to
be numeric). I think this is pretty ugly, not to say inconsistent,
since the parser's behavior can change depending on how many digits
you type:
regression=# select * from num_data where val = 12345678901234.56;
ERROR: Unable to identify an operator '=' for types 'numeric' and 'float8'
You will have to retype this query using an explicit cast
regression=# select * from num_data where val = 12345678901234.567;
id | val
----+-----
(0 rows)
The second case works because it's treated exactly like
select * from num_data where val = '12345678901234.567';
and here, the resolution of an UNKNOWN-type string constant saves
the day.
I proposed a while back that T_Float tokens ought to carry the value in
string form, rather than actually converting it to float, so that we
behave consistently while taking no precision risks until the target
type is known for certain. Thomas seems not to want to do it that way,
for some reason.
regards, tom lane
From bouncefilter Wed Feb 16 22:31: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 WAA18114
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 22:30:51 -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 WAA13065;
Wed, 16 Feb 2000 22:30:28 -0500 (EST)
To: chris@bitmead.com
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql problem
In-reply-to: <38AB5F4E.AD384832@nimrod.itg.telecom.com.au>
References: <200002162336.SAA18813@candle.pha.pa.us>
<38AB5F4E.AD384832@nimrod.itg.telecom.com.au>
Comments: In-reply-to Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
message dated "Thu, 17 Feb 2000 13:39:10 +1100"
Date: Wed, 16 Feb 2000 22:30:28 -0500
Message-ID: <13062.950758228@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
I was noticing that psql now exits on ctrl-C.
Ugh. So now, if you type control-C while a query is in progress,
you get a cancel request sent, as you intended. Type it a tenth of
a second too late, however, and you get booted out of psql instead.
I think this is lousy human engineering, even though I'm sure Peter
thought it was a good idea at the time. If we trap control-C we
should trap it all the time, not create a delay-dependent behavior.
This is much better than the previous behaviour where it kinda got
muddled up and you could destroy your database if a half-completed
command was in its buffer.
What? Are you saying that control-C doesn't do a \r (reset the
query buffer)? That's probably true, and I agree that it should...
regards, tom lane
From bouncefilter Wed Feb 16 22:35:29 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 WAA19355
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 22:35:10 -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
WAA23228;
Wed, 16 Feb 2000 22:34:02 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002170334.WAA23228@candle.pha.pa.us>
Subject: Re: [HACKERS] psql problem]
In-Reply-To: <38AB5F4E.AD384832@nimrod.itg.telecom.com.au> from Chris Bitmead
at "Feb 17, 2000 01:39:10 pm"
To: chris@bitmead.com
Date: Wed, 16 Feb 2000 22:34:02 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I was noticing that psql now exits on ctrl-C. This is much
better than the previous behaviour where it kinda got
muddled up and you could destroy your database if
a half-completed command was in its buffer.
Yes, ^C exits if you are at a prompt, and terminates the current query
if you are running one. Very nice.
But wouldn't it be better if it was like /bin/sh and
popped you back to a fresh prompt or something?
You mean reprinted the prompt?
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 16 22:37:30 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 WAA19955
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 22:37: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
WAA23346;
Wed, 16 Feb 2000 22:36:22 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002170336.WAA23346@candle.pha.pa.us>
Subject: Re: [HACKERS] psql problem
In-Reply-To: <13062.950758228@sss.pgh.pa.us> from Tom Lane at "Feb 16,
2000 10:30:28 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed, 16 Feb 2000 22:36:22 -0500 (EST)
CC: chris@bitmead.com, PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
I was noticing that psql now exits on ctrl-C.
Ugh. So now, if you type control-C while a query is in progress,
you get a cancel request sent, as you intended. Type it a tenth of
a second too late, however, and you get booted out of psql instead.I think this is lousy human engineering, even though I'm sure Peter
thought it was a good idea at the time. If we trap control-C we
should trap it all the time, not create a delay-dependent behavior.
Yes, I figured that would be an issue. Not sure if I like it or not.
Of course, ^D exits you if you are not in a query.
This is much better than the previous behaviour where it kinda got
muddled up and you could destroy your database if a half-completed
command was in its buffer.What? Are you saying that control-C doesn't do a \r (reset the
query buffer)? That's probably true, and I agree that it should...
Looks like it works fine:
test=> select * from pg_class, pg_proc;
^C
Cancel request sent
ERROR: Query was cancelled.
test=>
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 16 23:03: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 XAA28386
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 23:02:52 -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 XAA13341;
Wed, 16 Feb 2000 23:02:21 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: chris@bitmead.com, PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql problem
In-reply-to: <200002170336.WAA23346@candle.pha.pa.us>
References: <200002170336.WAA23346@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Wed, 16 Feb 2000 22:36:22 -0500"
Date: Wed, 16 Feb 2000 23:02:21 -0500
Message-ID: <13338.950760141@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
What? Are you saying that control-C doesn't do a \r (reset the
query buffer)? That's probably true, and I agree that it should...
Looks like it works fine:
test=> select * from pg_class, pg_proc;
^C
Cancel request sent
ERROR: Query was cancelled.
test=>
No, I think Chris was complaining about the behavior with an
incomplete query in the buffer. I can't show it with current
sources since psql is exiting on ^C, but 6.5 works like this:
play=> foobar
play-> ^C
CANCEL request sent
<-- return typed here to get a prompt
play-> select 2+2;
ERROR: parser: parse error at or near "foobar"
play=>
Notice the prompt correctly shows that I still have stuff in the
query buffer after ^C. I think Chris is saying that ^C should
flush the buffer like \r does ... and I agree.
regards, tom lane
From bouncefilter Thu Feb 17 06:32:36 2000
Received: from smtp.kdt.de (ns2.kdt.de [195.8.224.2])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA28104;
Thu, 17 Feb 2000 06:31:41 -0500 (EST)
(envelope-from christof.petig@wtal.de)
Received: from gateway.petig.de (line0280lf.kdt.de [195.8.240.30])
by smtp.kdt.de (8.8.8/8.8.8) with ESMTP id MAA24808;
Thu, 17 Feb 2000 12:31:39 +0100
Received: from wtal.de (christof@[192.168.230.9])
by gateway (8.8.8/8.8.8) with ESMTP id MAA05868;
Thu, 17 Feb 2000 12:26:49 +0100
Sender: christof@to.wtal.de
Message-ID: <38AB7428.ECFB7471@wtal.de>
Date: Thu, 17 Feb 2000 05:08:08 +0100
From: Christof Petig <christof.petig@wtal.de>
Organization: Adolf Petig GmbH. & Co. KG
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.7 i586)
X-Accept-Language: de
MIME-Version: 1.0
To: Michael Meskes <meskes@postgreSQL.org>
CC: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] function question yet again
References: <20000215131439.A2553@fam-meskes.de>
<38A91179.AB924F0A@mascari.com>
<20000215152620.A11746@fam-meskes.de>
<38A96C2F.6796050A@mascari.com> <24028.950650165@sss.pgh.pa.us>
<20000216081422.A1623@fam-meskes.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Michael Meskes wrote:
On Tue, Feb 15, 2000 at 04:29:25PM -0500, Tom Lane wrote:
SPI is the recommended interface for server-side addon code, I think.
Okay, I see. That means my try to use ECPG to create a function is not
supposed to work. Gheez, I would have liked it.
It should be possible to create a SPI based libecpg.so! Though I don't
know if it is worth the effort (besides getting portable server code
(WOW)!) Hmmm. I come to like this idea.
I don't have any ideas on the deadlock, though.
Christof
From bouncefilter Wed Feb 16 23:48:31 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id XAA40964
for <pgsql-hackers@postgreSQL.org>;
Wed, 16 Feb 2000 23:48:01 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
PAA22894 for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 15:47:29 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdpIFSG_;
Thu Feb 17 15:46:50 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
PAA19653 for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 15:46:49 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0uRp3c; Thu Feb 17 15:45:47 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id PAA06158
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 15:45:46 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
PAA16162 for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 15:45:06 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38AB7C96.F0F1F37F@nimrod.itg.telecom.com.au>
Date: Thu, 17 Feb 2000 15:44:07 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql problem
References: <200002170336.WAA23346@candle.pha.pa.us>
<13338.950760141@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
There are two issues. One is what happens when there is something
in the buffer and I hit ^C. Intuitively I think I should get back to
a "sane" state ready for a new query. I mean I start off typing
a long query, then I change my mind I want ^C to get me a
clear prompt.
What used to happen is it says "CANCEL request sent". Then I
think "ok I'll put in a different query". but that doesn't work.
Maybe \r was the correct command but I never took the time
to learn that.
The other issue is what happens if I'm just at a prompt, I don't
think it should exit on ^C. Basicly this is because I'm familiar
with the way /bin/sh works and I wish psql had the same semantics.
Tom Lane wrote:
What? Are you saying that control-C doesn't do a \r (reset the
query buffer)? That's probably true, and I agree that it should...Looks like it works fine:
test=> select * from pg_class, pg_proc;
^C
Cancel request sent
ERROR: Query was cancelled.
test=>No, I think Chris was complaining about the behavior with an
incomplete query in the buffer. I can't show it with current
sources since psql is exiting on ^C, but 6.5 works like this:play=> foobar
play-> ^C
CANCEL request sent
<-- return typed here to get a prompt
play-> select 2+2;
ERROR: parser: parse error at or near "foobar"
play=>Notice the prompt correctly shows that I still have stuff in the
query buffer after ^C. I think Chris is saying that ^C should
flush the buffer like \r does ... and I agree.regards, tom lane
From bouncefilter Thu Feb 17 00:41:42 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 AAA52732
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 00:41:31 -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
AAA25566;
Thu, 17 Feb 2000 00:40:32 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002170540.AAA25566@candle.pha.pa.us>
Subject: Re: [HACKERS] create database doesn't work well in MULTIBYTE mode
In-Reply-To: <000501bf78df$dbb55f00$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Feb 17, 2000 09:42:24 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Thu, 17 Feb 2000 00:40:32 -0500 (EST)
CC: pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I have a crash while creating regression database in pararell regression
test.
Seems it's due to the following change.@@ -2638,7 +2705,14 @@ n->dbname = $3; n->dbpath = $5; #ifdef MULTIBYTE - n->encoding = $6; + if ($6 != NULL) { + n->encoding = pg_char_to_encoding($6); + if (n->encoding < 0) { + elog(ERROR, "Encoding name '%s' is invalid", $6); + } + } else { + n->encoding = GetTemplateEncoding(); + } #else n->encoding = 0; #endifWhy ?
$6 is an ival not an str.
Not sure what to recommend here, but you clearly have found a problem.
Try it as a string, and if that works, patch it.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 17 00:59:35 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 AAA56310
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 00:58:49 -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 OAA02863; Thu, 17 Feb 2000 14:57:54 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] create database doesn't work well in MULTIBYTE mode
Date: Thu, 17 Feb 2000 15:04:03 +0900
Message-ID: <000a01bf790c$cade54c0$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: <200002170540.AAA25566@candle.pha.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Thursday, February 17, 2000 2:41 PMI have a crash while creating regression database in pararell regression
test.
Seems it's due to the following change.@@ -2638,7 +2705,14 @@ n->dbname = $3; n->dbpath = $5; #ifdef MULTIBYTE - n->encoding = $6; + if ($6 != NULL) { + n->encoding =pg_char_to_encoding($6);
+ if (n->encoding < 0) {
+ elog(ERROR,"Encoding name '%s' is invalid", $6);
+ } + } else { + n->encoding =GetTemplateEncoding();
+ }
#else
n->encoding = 0;
#endifWhy ?
$6 is an ival not an str.Not sure what to recommend here, but you clearly have found a problem.
Try it as a string, and if that works, patch it.
$6 is already converted from string to ival in another place.
It seems to me that this change is unnecessary.
I don't understand why this was changed recently.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Thu Feb 17 00:54:31 2000
Received: from localhost (IDENT:root@hectic-3.jpl.nasa.gov [128.149.68.205])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA55516
for <hackers@postgreSQL.org>; Thu, 17 Feb 2000 00:54:07 -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 GAA01252;
Thu, 17 Feb 2000 06:04:45 GMT
Sender: lockhart@hub.org
Message-ID: <38AB8F7D.F164A256@alumni.caltech.edu>
Date: Thu, 17 Feb 2000 06:04:45 +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: Peter Eisentraut <peter_e@gmx.net>
CC: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Date/time types: big change
References: <Pine.GSO.4.02A.10002161931360.16403-100000@Svala.DoCS.UU.SE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I've just committed changes to "reunify" the date/time types.
"timestamp" and "interval" are now the two primary date/time types for
users. Also, I've changed the default date style to "ISO" (not just in
time for Y2K, but we'll be ready for "Y3K").I still don't like our Y2038 status. ;)
Yeah. Like the ntp rfc doc says: "we'll expect the solution to appear
before it is needed" or something to that effect.
Anyway, the question I have is what did you do with functions such as
datetimein() or comparison functions and such for the old types? Did you
remove them? What if some, say, user-defined trigger function uses them?
Then they are SOL. I had originally implemented datetime and timespan
as an experiment to see if a floating point number could behave well
enough to represent dates (I was worried about rounding and the
.999999 problem, especially with the wide range of platforms we
support).
So it turns out that they work. In the meantime, someone contributed a
timestamp type, but did not fully implement it and chose a 4 byte
representation, which is fundamentally flawed imho.
I've been waiting a year or two to do this upgrade, and the major rev
bump is the time and place to do it.
One reason why I didn't carry along both datetime *and* timestamp is
the large number of related functions and operators. It would have
significantly increased the size of the catalogs (mostly because
timestamp didn't have much to start with).
The reason I'm asking is that I would like to see the floating point types
converted to SQL in a similar fashion, but when I rename, say, float4eq to
realeq it might break user applications. Or not? This is all hypothetical
of course.
Lots of work for not much gain imho. For the date/time stuff, it made
sense because timestamp needed to be replaced. There isn't the same
underlying need for the floating point types afaik.
On the other hand, 7.0 (or 8.0, but that may be another 4 years ;) is
the time to do it. Does anyone else see this as an issue?
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Feb 17 01:12:32 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 BAA59121
for <hackers@postgreSQL.org>; Thu, 17 Feb 2000 01:12:30 -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 BAA13660;
Thu, 17 Feb 2000 01:12:15 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Date/time types: big changeu
In-reply-to: <38AB91BF.7510F467@alumni.caltech.edu>
References: <200002161855.NAA05756@candle.pha.pa.us>
<4548.950738948@sss.pgh.pa.us>
<38AB91BF.7510F467@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Thu, 17 Feb 2000 06:14:23 +0000"
Date: Thu, 17 Feb 2000 01:12:14 -0500
Message-ID: <13657.950767934@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
But, I'd have no objection to a configure or initdb option; I *would*
suggest that the old default (and it is the default mostly because
original Postgres95 had no other styles implemented) is a relatively
poor choice, and that ISO should be the default choice in the absence
of an explicit configure or initdb switch.
As I said, I have no objection to making ISO the new "standard default";
I just think some people will need a way to change the default in their
installations.
regards, tom lane
From bouncefilter Thu Feb 17 01:07:32 2000
Received: from localhost (IDENT:root@hectic-3.jpl.nasa.gov [128.149.68.205])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA58328
for <hackers@postgreSQL.org>; Thu, 17 Feb 2000 01:07:06 -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 GAA01264;
Thu, 17 Feb 2000 06:14:23 GMT
Sender: lockhart@hub.org
Message-ID: <38AB91BF.7510F467@alumni.caltech.edu>
Date: Thu, 17 Feb 2000 06:14:23 +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: Bruce Momjian <pgman@candle.pha.pa.us>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Date/time types: big changeu
References: <200002161855.NAA05756@candle.pha.pa.us>
<4548.950738948@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Also, I've changed the default date style to "ISO" (not just in
time for Y2K, but we'll be ready for "Y3K").I think we need a consensus on this. I think this may be a problem for
some people. Comments?Good point. Perhaps there should be a way to select the default date
style at configure or initdb time. I don't mind if the "default default"
is ISO, but if I had apps that were dependent on the old default setting
I'd sure be annoyed by this change...
I've been talking about this for quite some time, but there *really*
is no excuse to not go to the ISO date/time standard. Every other date
style is prone to misinterpretation, and the ISO standard is commonly
used in other instances where reliable date reporting is needed.
I've waited until a major rev to do this, and the groundwork has been
there for a year or two. There are some good summaries of the issues
on the web.
But, I'd have no objection to a configure or initdb option; I *would*
suggest that the old default (and it is the default mostly because
original Postgres95 had no other styles implemented) is a relatively
poor choice, and that ISO should be the default choice in the absence
of an explicit configure or initdb switch.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Feb 17 01:31:32 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id BAA65829
for <hackers@postgreSQL.org>; Thu, 17 Feb 2000 01:31:23 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
RAA21651 for <hackers@postgreSQL.org>;
Thu, 17 Feb 2000 17:30:51 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdsj18h_;
Thu Feb 17 17:30:28 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
RAA02004 for <hackers@postgreSQL.org>;
Thu, 17 Feb 2000 17:30:27 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd.SPTY_; Thu Feb 17 17:29:53 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id RAA07860
for <hackers@postgreSQL.org>; Thu, 17 Feb 2000 17:29:52 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
RAA18804
for <hackers@postgreSQL.org>; Thu, 17 Feb 2000 17:29:12 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38AB94FD.EFF0B473@nimrod.itg.telecom.com.au>
Date: Thu, 17 Feb 2000 17:28:13 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] libpq
References: <38A2AE00.9EB1BE9B@bitmead.com> <15283.950196239@sss.pgh.pa.us>
<38A396B0.BF0509A5@nimrod.itg.telecom.com.au>
<18587.950249454@sss.pgh.pa.us>
<38A3ADE3.AAE1FC7D@nimrod.itg.telecom.com.au>
<19512.950281813@sss.pgh.pa.us> <38A6A3AE.CAF01A62@bitm
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I posted this about a week ago, and it passed without comment.
Does this mean I'm so far off track that no-one cares to comment,
or I got it so right that no comment was needed?
Quick summary: I want to work on libpq, partly to implement
my OO plans in libpq, and partly to implement the streaming
interface. But I'm concerned that a lower-level interface
will give better control and better efficiency.
Also, this is a fair amount of hacking. I have heard talk of
"when we go to using corba" and such. I could look at doing
this at the same time, but remain to be convinced of the benefit.
What would be the method? something like sequence<Attribute> ?
I would have thought this would be a big protocol overhead. I
also would have thought that the db protocol for a database
would be sufficiently simple and static that corba would be
overkill. Am I wrong?
Chris Bitmead wrote:
100 bytes, or even 50 bytes seems like a huge price to pay. If I'm
retrieving 10 byte tuples that's a 500% or 1000% overhead.There are other issues too. Like if I want to be able to populate
a C++ object without the overhead of copying, I need to know
in advance the type of tuple I'm getting back. So I need something
like a nextClass() API.Here is what I'm imagining (in very rough terms with details glossed
over).
How would you do this with the PGresult idea?...class Base {
int c;
}
class Sub1 : Base {
int b;
}
class Sub2 : Base {
int c;
}
#define OFFSET (class, field) (&((class *)NULL)->field)
struct FieldPositions f1[] = { { "a", OFFSET(Sub1,a) }, { "b",
OFFSET(Sub1,b)} };
struct FieldPositions f2[] = { { "a", OFFSET(Sub1, c) }, { "c",
OFFSET(Sub2, c) } };PGresult *q = PQexecStream("SELECT ** from Base");
List<Base> results;
for (;;) {
PGClass *class = PQnextClass(q);
if (PQresultStatus(q) == ERROR)
processError(q);
else if (PQresultStatus(q) == NO_MORE)
break;
if (strcmp(class->name) == "Sub1") {
results.add(PQnextObject(q, new Sub1, FieldPositions(f1)));
else if (strcmp(class->name) == "Sub2") {
results.add(PQnextObject(q, new Sub2, FieldPositions(f2)));
}Of course in a full ODBMS front end, some of the above code would
be generated or something.In this case PQnextObject is populating memory supplied by the
programmer.
There is no overhead whatsoever, nor can there be because we are
supplying
memory for the fields we care about.In this case we don't even need to store tuple descriptors because
the C++ object has it's vtbl which is enough. If we cared about
tuple descriptors though we could hang onto the PGClass and do
something like PQgetValue(class, object, "fieldname"), which
would be useful for some language interfaces no doubt.A basic C example would look like this...
PGresult *q = PQexecStream("SELECT ** from Base");
for (;;) {
PGClass *class = PQnextClass(q);
if (PQresultStatus(q) == ERROR)
processError(q);
else if (PQresultStatus(q) == NO_MORE)
break;
PGobject *obj = PQnextObject(q, NULL, NULL);
for (int c = 0; c < PQnColumns(class); c++) {
printf("%s: %s, ", PQcolumnName(class, c), PQcolumnValue(class, c,
obj));
printf("\n");
}The points to note here are:
(1) Yes, the error message stuff comes from PGresult as it does now.
(2) You don't have a wasteful new PGresult for every time you get
the next result.
(3) You are certainly not required to store a whole lot of PGresults
just because you want to cache tuples.
(4) Because the tuple descriptor is explicit (PGClass*) you can
keep it or not as you please. If you are doing pure relational
with fixed number of columns, there is ZERO overhead per tuple
because you only need keep one pointer to the PGClass. This is
even though you retrieve results one at a time.
(5) Because of (4) I can't see the need for any API to support
getting multiple tuples at a time since it is trivially implemented
in terms of nextObject with no overhead.While a PGresult interface like you described could be built, I can't
see that
it fulfills all the requirements that I would have. It could be
trivially
built on top of the above building blocks, but it doesn't sound fine
enough
grained for me. If you disagree, tell me how you'd do it.Tom Lane wrote:
Chris <chris@bitmead.com> writes:
All I mean to say is that it is often desirable to have control over
when each individual object is destroyed, rather than having to destroy
each batch at once.Right, so if you really want to destroy retrieved tuples one at a time,
you request only one per retrieved PGresult. I claim that the other
case where you want them in small batches (but not necessarily only one
at a time) is at least as interesting; therefore the mechanism should
not be limited to the exactly-one-at-a-time case. Once you allow for
the other requirements, you have something that looks enough like a
PGresult that it might as well just *be* a PGresult.The result status and query status is only temporarily interesting. Once
I know the tuple arrived safely I don't care much about the state of
affairs at that moment, and don't care to waste memory on a structure
that has space for all these error fields.Let's see (examines PGresult declaration). Four bytes for the
resultStatus, four for the errMsg pointer, 40 for cmdStatus,
out of a struct that is going to occupy close to 100 bytes on
typical hardware --- and that's not counting the tuple descriptor
data and the tuple(s) proper. You could easily reduce the cmdStatus
overhead by making it a pointer to an allocated string instead of
an in-line array, if the 40 bytes were really bothering you. So the
above seems a pretty weak argument for introducing a whole new datatype
and a whole new set of access functions for it. Besides which, you
haven't explained how it is that you are going to avoid the need to
be able to represent error status in a PGObject. The function that
fetches the next tuple(s) in a query has to be able to return an
error status, and that has to be distinguishable from "successful
end of query" and from "no more data available yet".The other thing about PGobject idea is that when I do a real OO database
idea, is that getNextObject will optionally populate user-supplied data
instead.And that can't be done from a PGresult because?
So far, the *only* valid reason you've given for inventing a new
datatype, rather than just using PGresult for the purpose, is to save a
few bytes by eliminating unnecessary fields. That seems a pretty weak
argument (even assuming that the fields are unnecessary, which I doubt).
Having to support and document a whole set of essentially-identical
access functions for both PGresult and PGObject is the overhead that
we ought to be worried about, ISTM. Don't forget that it's not just
libpq we are talking about, either; this additional API will also have
to propagate into libpq++, libpgtcl, the perl5 and python modules,
etc etc etc.regards, tom lane
From bouncefilter Thu Feb 17 01:30:34 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 BAA64290
for <hackers@postgreSQL.org>; Thu, 17 Feb 2000 01:29:47 -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 BAA13792;
Thu, 17 Feb 2000 01:29:40 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Peter Eisentraut <peter_e@gmx.net>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Date/time types: big change
In-reply-to: <38AB8F7D.F164A256@alumni.caltech.edu>
References: <Pine.GSO.4.02A.10002161931360.16403-100000@Svala.DoCS.UU.SE>
<38AB8F7D.F164A256@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Thu, 17 Feb 2000 06:04:45 +0000"
Date: Thu, 17 Feb 2000 01:29:40 -0500
Message-ID: <13789.950768980@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
The reason I'm asking is that I would like to see the floating point types
converted to SQL in a similar fashion, but when I rename, say, float4eq to
realeq it might break user applications. Or not? This is all hypothetical
of course.
Lots of work for not much gain imho. For the date/time stuff, it made
sense because timestamp needed to be replaced. There isn't the same
underlying need for the floating point types afaik.
On the other hand, 7.0 (or 8.0, but that may be another 4 years ;) is
the time to do it. Does anyone else see this as an issue?
I think it's too late in the 7.0 cycle to start thinking about renaming
the numeric types. While you implemented the date/time changes at
almost the last minute, the changes had been discussed and agreed to
long ago, and you knew exactly what you needed to do. I don't think
that constitutes a precedent for a hurried revision of the numeric
types...
We've already postponed 7.0 beta twice. Seems to me it's time to
start raising the bar for what we will accept into this revision.
regards, tom lane
From bouncefilter Thu Feb 17 01:22:31 2000
Received: from localhost (IDENT:root@hectic-3.jpl.nasa.gov [128.149.68.205])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA61474
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 01:22:06 -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 GAA01285
for <pgsql-hackers@postgreSQL.org>; Thu, 17 Feb 2000 06:32:48 GMT
Sender: lockhart@hub.org
Message-ID: <38AB9610.C863108C@alumni.caltech.edu>
Date: Thu, 17 Feb 2000 06:32:48 +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: pgsql-hackers@postgreSQL.org
Subject: Re: SQL compliance,
was Re: [HACKERS] follow-up on PC Week Labsbenchmark results
References: <85256887.006F108A.00@mailer.zd.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
You had inquired earlier about "when we would support complete SQL92"
(give or take a few words). What areas of entry level SQL92 are we
missing in your opinion (or should we wait for the article)?Well, what I look for on the language side is complete SQL-92 entry level
compliance, plus common language extensions like outer joins, cast, case,
cube, rollup, a datetime data type, add table constraint and alter table.
Also, I look for a stored procedure language. Basically, parity with the
commercial databases. :)
I've since seen the article in the latest issue of PCWeek. The article
was not at all clear on the *specific* features which would disqualify
Postgres from having SQL92 entry level compliance (for most commercial
RDBMSes this is the only level they attain), and I was amused to note
that although InterBase was lauded for SQL92 compliance, the author
did encourage them to consider supporting the SQL92 comment delimiter
("--") in their next release :))
Since InterBase has not been released as Open Source, and since we
will have a 7.0 release *before* Inprise does try the Open Source
thing, it would be nice to have those things happen before annointing
it as the "one true Open Source RDBMS" (tm). But frankly PCWeek has
been far more aggressively clueless in the past, and all in all they
are coming much closer to a balanced view of the world over the last
few months.
It's nice seeing Postgres mentioned at all (though in this article
none of the titles or subtitles mentioned us; you had to look at the
content), and we've still got a long way to go to completely overcome
the FUD-based criticisms of Open Source which were more clearly
apparent in PCWeek until very recently.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Feb 17 02:02:32 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 CAA71760
for <hackers@postgresql.org>; Thu, 17 Feb 2000 02:01:35 -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 CAA14081;
Thu, 17 Feb 2000 02:01:21 -0500 (EST)
To: chris@bitmead.com
cc: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] libpq
In-reply-to: <38AB94FD.EFF0B473@nimrod.itg.telecom.com.au>
References: <38A2AE00.9EB1BE9B@bitmead.com> <15283.950196239@sss.pgh.pa.us>
<38A396B0.BF0509A5@nimrod.itg.telecom.com.au>
<18587.950249454@sss.pgh.pa.us>
<38A3ADE3.AAE1FC7D@nimrod.itg.telecom.com.au>
<19512.950281813@sss.pgh.pa.us> <38A6A3AE.CAF01A62@bitm
<38AB94FD.EFF0B473@nimrod.itg.telecom.com.au>
Comments: In-reply-to Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
message dated "Thu, 17 Feb 2000 17:28:13 +1100"
Date: Thu, 17 Feb 2000 02:01:21 -0500
Message-ID: <14078.950770881@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
I posted this about a week ago, and it passed without comment.
Does this mean I'm so far off track that no-one cares to comment,
or I got it so right that no comment was needed?
I haven't looked at it because I am trying to finish up other stuff
before we go beta. Will get back to you later. I imagine other
people are in deadline mode also...
regards, tom lane
From bouncefilter Thu Feb 17 02:04:32 2000
Received: from localhost (IDENT:root@hectic-3.jpl.nasa.gov [128.149.68.205])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA72257;
Thu, 17 Feb 2000 02:04: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 HAA03297;
Thu, 17 Feb 2000 07:14:27 GMT
Sender: lockhart@hub.org
Message-ID: <38AB9FD2.92869E92@alumni.caltech.edu>
Date: Thu, 17 Feb 2000 07:14: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: Tom Lane <tgl@sss.pgh.pa.us>
CC: Hiroshi Inoue <Inoue@tpf.co.jp>, Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ERROR: Unable to identify an operator '=' for types
'numeric' and 'float8'
References: <000601bf78ef$ebc90580$2801007e@tpf.co.jp>
<13030.950757826@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I proposed a while back that T_Float tokens ought to carry the value in
string form, rather than actually converting it to float, so that we
behave consistently while taking no precision risks until the target
type is known for certain. Thomas seems not to want to do it that way,
for some reason.
Hmm. We should then carry *all* numeric types as strings farther into
the backend, probably deeper than gram.y? Some of the input validation
happens as early as gram.y now, so I guess we would need to do some
conversion at that point for some contexts, and leave the numeric
stuff as a string in other contexts. No fair only doing it for float8;
int4 has the same trouble.
Just seems like a can of worms, but it is definitely (?) the right
solution since at the moment the early interpretation of numerics can
lead to loss of info or precision deeper in the code.
This could be a minor-release kind of improvement...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Feb 17 02:25:32 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 CAA75784
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 02:25: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 CAA14932
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 02:25:13 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: Definitional issue for INET types
Date: Thu, 17 Feb 2000 02:25:13 -0500
Message-ID: <14929.950772313@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
I tried fixing some of the known problems with comparison of INET values
(cf. thread "uniqueness not always correct" on 11/11/99, among others),
and was surprised to discover that my changes affected the results of
the inet regress test. Specifically, the regress test exercises all the
inet comparison operators on the two data values
'10.1.2.3/8'::inet '10.0.0.0/32'::cidr
The old code believes that the first of these is greater, while my
revised code thinks the second is greater.
Now, my understanding of things is that '10.1.2.3/8' is just an
unreasonably verbose way of writing '10/8', because if you write /8
you are saying that only the first 8 bits mean anything. So it seems
to me that we are really comparing '10/8' and '10.0.0.0/32', and the
former should be considered the lesser in the same way that 'ab'
comes before 'abc' in dictionaries.
Is the regress test's expected output wrong, or have I missed
something?
regards, tom lane
From bouncefilter Thu Feb 17 02:28:32 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 CAA76268
for <hackers@postgreSQL.org>; Thu, 17 Feb 2000 02:28:13 -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 CAA14950;
Thu, 17 Feb 2000 02:28:04 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Almost there on column aliases
In-reply-to: <38AAC6D0.2B0AB8C@alumni.caltech.edu>
References: <38A3A7DB.6A684EF@alumni.caltech.edu>
<18707.950251267@sss.pgh.pa.us>
<38A3B745.E720A4AC@alumni.caltech.edu>
<18803.950253638@sss.pgh.pa.us>
<38A432D2.D6998E5B@alumni.caltech.edu>
<19051.950545044@sss.pgh.pa.us>
<38A8368B.68AF6CDA@alumni.caltech.edu>
<22598.950555491@sss.pgh.pa.us>
<38A8C61D.90557A4B@alumni.caltech.edu>
<23664.950648530@sss.pgh.pa.us> <38A9C751.7365FA7@jpl.nasa.gov>
<28639.950652834@sss.pgh.pa.us>
<38AAC6D0.2B0AB8C@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Wed, 16 Feb 2000 15:48:32 +0000"
Date: Thu, 17 Feb 2000 02:28:04 -0500
Message-ID: <14947.950772484@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
I'm currently (2000-02-16 15:40 GMT) seeing the rules test
blank-filling the "bpchar" fields. Do you see that?
No ...
regards, tom lane
From bouncefilter Thu Feb 17 02:39:32 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 CAA78704;
Thu, 17 Feb 2000 02:39:02 -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 CAA14992;
Thu, 17 Feb 2000 02:38:47 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>, Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ERROR: Unable to identify an operator '=' for types
'numeric' and 'float8'
In-reply-to: <38AB9FD2.92869E92@alumni.caltech.edu>
References: <000601bf78ef$ebc90580$2801007e@tpf.co.jp>
<13030.950757826@sss.pgh.pa.us>
<38AB9FD2.92869E92@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Thu, 17 Feb 2000 07:14:26 +0000"
Date: Thu, 17 Feb 2000 02:38:46 -0500
Message-ID: <14988.950773126@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
I proposed a while back that T_Float tokens ought to carry the value in
string form, rather than actually converting it to float,
No fair only doing it for float8; int4 has the same trouble.
Au contraire: int representation has no risk of loss of precision.
It does risk overflow, but we can detect that reliably, and in fact
scan.l already takes care of that scenario.
If we allow ints to retain their current representation, then the
manipulations currently done in gram.y don't need to change. All
that's needed is to invoke the proper typinput function after we've
decided what type we really want to convert a T_Float to. T_Float
would act kind of like UNKNOWN-type string constants, except that
the knowledge that the string looks numeric-ish could be used in
type selection heuristics.
regards, tom lane
From bouncefilter Thu Feb 17 04:22:34 2000
Received: from hu.tm.ee (ppp840.tele2.ee [212.107.37.140])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA01585
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 04:22:13 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id C8D9C3A24; Thu, 17 Feb 2000 11:30:20 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38ABBFAC.FAEBB799@tm.ee>
Date: Thu, 17 Feb 2000 11:30:20 +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: chris@bitmead.com
Cc: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] FYI: BNF for SQL93 and SQL-3
References: <38AB20DA.EAA7B9B6@tm.ee>
<38AB5E48.CD2282E5@nimrod.itg.telecom.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Chris Bitmead wrote:
Hannu Krosing wrote:
Doing a Google search for SQL standards, I found a
wonderful page of links to SQL info, including the BNF
specs for SQL92 and SQL3. Not exactly gram.y but hopefully
close.How official is this? I get the feeling this might
be one guy's interpretation because it seems like
it is missing stuff.
I guess it is lifted from the standard as it was in september 1993.
OTOH, the SQL3 standard is still not final.
-----------
Hannu
From bouncefilter Thu Feb 17 05:57:35 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 FAA21638
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 05:56:53 -0500 (EST) (envelope-from vev@michvhf.com)
Received: (qmail 23014 invoked by uid 1001); 17 Feb 2000 10:56:54 -0000
Date: Thu, 17 Feb 2000 05:56:54 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, chris@bitmead.com,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql problem
In-Reply-To: <13338.950760141@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.05.10002170555230.22914-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 16 Feb 2000, Tom Lane wrote:
What? Are you saying that control-C doesn't do a \r (reset the
query buffer)? That's probably true, and I agree that it should...Looks like it works fine:
test=> select * from pg_class, pg_proc;
^C
Cancel request sent
ERROR: Query was cancelled.
test=>No, I think Chris was complaining about the behavior with an
incomplete query in the buffer. I can't show it with current
sources since psql is exiting on ^C, but 6.5 works like this:
Actually from reading Chris' note, he said that it was 'better than
previous behaviour'. Note the key word was *previous*.
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 Feb 17 06:17:36 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA25227
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 06:17:27 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Oxe.DoCS.UU.SE (e99re41@Oxe.DoCS.UU.SE [130.238.9.101])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id MAA09808;
Thu, 17 Feb 2000 12:17:14 +0100 (MET)
Received: from localhost (e99re41@localhost) by Oxe.DoCS.UU.SE (8.6.12/8.6.12)
with SMTP id MAA02952; Thu, 17 Feb 2000 12:17:11 +0100
X-Authentication-Warning: Oxe.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 17 Feb 2000 12:17:09 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: chris@bitmead.com
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql problem
In-Reply-To: <38AB5F4E.AD384832@nimrod.itg.telecom.com.au>
Message-ID: <Pine.GSO.4.02A.10002171213250.2933-100000@Oxe.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 17 Feb 2000, Chris Bitmead wrote:
I was noticing that psql now exits on ctrl-C.
But wouldn't it be better if it was like /bin/sh and
popped you back to a fresh prompt or something?
I have, in fact, been muddling with this. If demand is there (apparently),
I can speed up the muddling.
For all of those that pretend to never have heard of this behaviour, I
explicitly announced it and even got several positive responses.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Feb 17 06:21:36 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA25872
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 06:21:15 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Oxe.DoCS.UU.SE (e99re41@Oxe.DoCS.UU.SE [130.238.9.101])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id MAA10187;
Thu, 17 Feb 2000 12:21:06 +0100 (MET)
Received: from localhost (e99re41@localhost) by Oxe.DoCS.UU.SE (8.6.12/8.6.12)
with SMTP id MAA02958; Thu, 17 Feb 2000 12:21:04 +0100
X-Authentication-Warning: Oxe.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 17 Feb 2000 12:21:03 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, chris@bitmead.com,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql problem
In-Reply-To: <13338.950760141@sss.pgh.pa.us>
Message-ID: <Pine.GSO.4.02A.10002171218580.2933-100000@Oxe.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 16 Feb 2000, Tom Lane wrote:
No, I think Chris was complaining about the behavior with an
incomplete query in the buffer. I can't show it with current
sources since psql is exiting on ^C, but 6.5 works like this:play=> foobar
play-> ^C
CANCEL request sent
<-- return typed here to get a prompt
Actually, I have an idea why that is, too. The signal handler should tell
readline that input is done. At the time you press return there, it's
still reading input.
play-> select 2+2;
ERROR: parser: parse error at or near "foobar"
play=>
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Feb 17 06:25:36 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA26566
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 06:25:22 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Oxe.DoCS.UU.SE (e99re41@Oxe.DoCS.UU.SE [130.238.9.101])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id MAA10536;
Thu, 17 Feb 2000 12:25:18 +0100 (MET)
Received: from localhost (e99re41@localhost) by Oxe.DoCS.UU.SE (8.6.12/8.6.12)
with SMTP id MAA02969; Thu, 17 Feb 2000 12:25:17 +0100
X-Authentication-Warning: Oxe.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 17 Feb 2000 12:25:16 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Scott Williams <scott@james.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql password prompt
In-Reply-To: <200002162336.SAA18813@candle.pha.pa.us>
Message-ID: <Pine.GSO.4.02A.10002171224450.2933-100000@Oxe.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 16 Feb 2000, Bruce Momjian wrote:
Peter E. can you look at this? I see simple prompt doing:
fputs(prompt, stdout);
which I think should be stderr. Peter, can you check on those?
Will be fixed.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Feb 17 06:49:37 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA31419
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 06:49:09 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Oxe.DoCS.UU.SE (e99re41@Oxe.DoCS.UU.SE [130.238.9.101])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id MAA12490;
Thu, 17 Feb 2000 12:49:02 +0100 (MET)
Received: from localhost (e99re41@localhost) by Oxe.DoCS.UU.SE (8.6.12/8.6.12)
with SMTP id MAA03008; Thu, 17 Feb 2000 12:48:59 +0100
X-Authentication-Warning: Oxe.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 17 Feb 2000 12:48:57 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Hiroshi Inoue <Inoue@tpf.co.jp>
cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] create database doesn't work well in MULTIBYTE mode
In-Reply-To: <000501bf78df$dbb55f00$2801007e@tpf.co.jp>
Message-ID: <Pine.GSO.4.02A.10002171247310.2933-100000@Oxe.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Good point. Thomas? ;)
As the one who wrote the seemingly correct code, I say revert this part.
On Thu, 17 Feb 2000, Hiroshi Inoue wrote:
I have a crash while creating regression database in pararell
regression test. Seems it's due to the following change.@@ -2638,7 +2705,14 @@ n->dbname = $3; n->dbpath = $5; #ifdef MULTIBYTE - n->encoding = $6; + if ($6 != NULL) { + n->encoding = pg_char_to_encoding($6); + if (n->encoding < 0) { + elog(ERROR, "Encoding name '%s' is invalid", $6); + } + } else { + n->encoding = GetTemplateEncoding(); + } #else n->encoding = 0; #endifWhy ?
$6 is an ival not an str.Regards.
Hiroshi Inoue
Inoue@tpf.co.jp************
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Feb 17 07:00:36 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA33558
for <hackers@postgreSQL.org>; Thu, 17 Feb 2000 07:00:27 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Oxe.DoCS.UU.SE (e99re41@Oxe.DoCS.UU.SE [130.238.9.101])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id NAA13464;
Thu, 17 Feb 2000 13:00:19 +0100 (MET)
Received: from localhost (e99re41@localhost) by Oxe.DoCS.UU.SE (8.6.12/8.6.12)
with SMTP id NAA03020; Thu, 17 Feb 2000 13:00:18 +0100
X-Authentication-Warning: Oxe.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 17 Feb 2000 13:00:17 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Date/time types: big change
In-Reply-To: <13789.950768980@sss.pgh.pa.us>
Message-ID: <Pine.GSO.4.02A.10002171258480.2933-100000@Oxe.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 17 Feb 2000, Tom Lane wrote:
I think it's too late in the 7.0 cycle to start thinking about renaming
the numeric types.
I didn't mean that this should happen now or even soon. It was more of a
policy/practice inquiry.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Feb 17 07:10:36 2000
Received: from anubis.inm.de (anubis.inm.de [195.20.81.9])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA35257
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 07:09:54 -0500 (EST) (envelope-from sevo@ip23.net)
Received: from ip23.net (umbriel [195.20.81.11]) by anubis.inm.de
(980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id NAA60488;
Thu, 17 Feb 2000 13:07:59 +0100 (CET)
Message-ID: <38ABE49F.142BC894@ip23.net>
Date: Thu, 17 Feb 2000 13:07:59 +0100
From: Sevo Stille <sevo@ip23.net>
Reply-To: sevo@ip23.net
Organization: IP23
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: de,en,en-GB,en-US
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Definitional issue for INET types
References: <14929.950772313@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Now, my understanding of things is that '10.1.2.3/8' is just an
unreasonably verbose way of writing '10/8', because if you write /8
you are saying that only the first 8 bits mean anything.
Not really. In a classed view on a network, the /8 is undefined - and
worse, there is no real concept of a address consisting of a
network/netmask tuple. /8 might imply that 10.1.2.3 is in the class A
segment, it might be considered a 255.0.0.0 netmask with any possible
interpretation of the latter, or it might be entirely ignored. For
::cidr vs. ::cidr the answer is clear - apply the masks and match then,
which would make 10/8 lesser by all means.
So it seems
to me that we are really comparing '10/8' and '10.0.0.0/32', and the
former should be considered the lesser in the same way that 'ab'
comes before 'abc' in dictionaries.Is the regress test's expected output wrong, or have I missed
something?
Tough question. There are some nasty details differing between classed
network notation and CIDR notation, and we certainly cannot reconcile
them all in operators. As the significant digits are meaningless in
classed notation, they might either be ignored or interpreted according
to any rule applying to classed netmasks, which really depends on the
context of the network device - a router, firewall or audit tool might
each have different semantics and requirements.
I'll see whether I can figure out something consistent for the inet data
type. As it is right now, we might just as well drop it - it is both
synonymous to cidr and to a cidr /32 host, which simply can't be.
Personally, I don't think we would lose any functionality if we drop it,
as long as we have functions that return classed network structures like
the base address and a networks subnettable range.
Sevo
--
Sevo Stille
sevo@ip23.net
From bouncefilter Thu Feb 17 07:11:36 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA35430
for <pgsql-hackers@postgresql.org>;
Thu, 17 Feb 2000 07:10:59 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Oxe.DoCS.UU.SE (e99re41@Oxe.DoCS.UU.SE [130.238.9.101])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id NAA14260;
Thu, 17 Feb 2000 13:10:52 +0100 (MET)
Received: from localhost (e99re41@localhost) by Oxe.DoCS.UU.SE (8.6.12/8.6.12)
with SMTP id NAA03033; Thu, 17 Feb 2000 13:10:50 +0100
X-Authentication-Warning: Oxe.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 17 Feb 2000 13:10:49 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Definitional issue for INET types
In-Reply-To: <14929.950772313@sss.pgh.pa.us>
Message-ID: <Pine.GSO.4.02A.10002171305400.2933-100000@Oxe.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 17 Feb 2000, Tom Lane wrote:
'10.1.2.3/8'::inet '10.0.0.0/32'::cidr
The old code believes that the first of these is greater, while my
revised code thinks the second is greater.
I think we can flip a three-sided coin here:
1) '10.1.2.3/8'::inet is not a valid inet input value, sort of in the same
way as 10.5 is not a valid integer.
2) You coerce '10.1.2.3/8'::inet to essentially '10.0.0.0/8'::inet on
input. (In some parts, implicit data mangling that loses information is
not considered good practice.)
3) You can't compare inet and cidr because they're two different (albeit
similar) things. If you want to compare them you have to explicitly cast
inet to cidr or vice versa according to 1) or 2).
In any case I believe you revised code has a very good point.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Feb 17 09:10:43 2000
Received: from rage.hub.org (root@nat195.216.mpoweredpc.net [142.177.195.216])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA64186
for <pgsql-hackers@postgresql.org>;
Thu, 17 Feb 2000 09:10:22 -0500 (EST) (envelope-from jeffm@pgsql.com)
Received: from localhost (jeffm@localhost)
by rage.hub.org (8.9.3/8.9.3) with ESMTP id KAA52225
for <pgsql-hackers@postgresql.org>;
Thu, 17 Feb 2000 10:10:35 -0400 (AST) (envelope-from jeffm@pgsql.com)
X-Authentication-Warning: rage.hub.org: jeffm owned process doing -bs
Date: Thu, 17 Feb 2000 10:10:35 -0400 (AST)
From: "Jeff MacDonald <jeff@pgsql.com>" <jeffm@pgsql.com>
X-Sender: jeffm@rage.hub.org
Reply-To: Jeff MacDonald <jeff@pgsql.com>
To: pgsql-hackers@postgresql.org
Subject: PC Week PostgreSQL benchmark results posted online (fwd)
Message-ID: <Pine.BSF.4.10.10002171009160.10395-100000@rage.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi Guys,
Tim Dyck asked me to forward this on to the list.
*****************************
FYI, the story is available online at:
http://www.zdnet.com/pcweek/stories/news/0,4153,2436153,00.html
As I think I have mentioned, I would like to review PostgreSQL 7.0 when it
goes gold, so if someone could let me know when it is available, that
would be much appreciated.
(i can handle contacting him when it comes out.)
Regards,
Tim Dyck
Senior Analyst
PC Week Labs
From bouncefilter Thu Feb 17 09:33:44 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 JAA68750
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 09:33:16 -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 OAA04217;
Thu, 17 Feb 2000 14:43:35 GMT
Sender: lockhart@hub.org
Message-ID: <38AC0917.DA4EDB67@alumni.caltech.edu>
Date: Thu, 17 Feb 2000 14:43:35 +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: Peter Eisentraut <peter_e@gmx.net>, Hiroshi Inoue <Inoue@tpf.co.jp>
CC: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] create database doesn't work well in MULTIBYTE mode
References: <Pine.GSO.4.02A.10002171247310.2933-100000@Oxe.DoCS.UU.SE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Good point. Thomas? ;)
As the one who wrote the seemingly correct code, I say revert this part.
OK, so just a simple assignment to $6 is what is needed? I vaguely
remember a merging problem here, and obviously chose the wrong block
of code to retain. Amazing that the desired code is actually simpler
:)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Feb 17 09:44:44 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 JAA71398;
Thu, 17 Feb 2000 09:44: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 OAA04230;
Thu, 17 Feb 2000 14:51:52 GMT
Sender: lockhart@hub.org
Message-ID: <38AC0B08.31CFAC8@alumni.caltech.edu>
Date: Thu, 17 Feb 2000 14:51: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: Tom Lane <tgl@sss.pgh.pa.us>
CC: Hiroshi Inoue <Inoue@tpf.co.jp>, Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ERROR: Unable to identify an operator '=' for types
'numeric' and 'float8'
References: <000601bf78ef$ebc90580$2801007e@tpf.co.jp>
<13030.950757826@sss.pgh.pa.us>
<38AB9FD2.92869E92@alumni.caltech.edu>
<14988.950773126@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
No fair only doing it for float8; int4 has the same trouble.
Au contraire: int representation has no risk of loss of precision.
It does risk overflow, but we can detect that reliably, and in fact
scan.l already takes care of that scenario.
Right, but why bother doing it there and then having to propagate the
"int4 or string" code into the backend? Right now, we mark it as an
string constant of unknown characteristics if it is too large for an
int4, but that isn't the right thing for long numerics since we are
throwing away valuable info. And using the scan.l heuristic to filter
out large values for things like OIDs is probably cheating a bit ;)
If we allow ints to retain their current representation, then the
manipulations currently done in gram.y don't need to change. All
that's needed is to invoke the proper typinput function after we've
decided what type we really want to convert a T_Float to. T_Float
would act kind of like UNKNOWN-type string constants, except that
the knowledge that the string looks numeric-ish could be used in
type selection heuristics.
So a replacement for T_Float would carry the "long string with decimal
point" info, and a replacement for T_Integer would carry the "long
string with digits only" info. And we would continue to use T_Float
and T_Integer deeper in the backend to carry converted values.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Feb 17 09:49:44 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 JAA72605
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 09:49:04 -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 OAA04243;
Thu, 17 Feb 2000 14:59:41 GMT
Sender: lockhart@hub.org
Message-ID: <38AC0CDC.8D6121D5@alumni.caltech.edu>
Date: Thu, 17 Feb 2000 14:59: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: Jeff MacDonald <jeff@pgsql.com>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PC Week PostgreSQL benchmark results posted online
(fwd)
References: <Pine.BSF.4.10.10002171009160.10395-100000@rage.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
As I think I have mentioned, I would like to review PostgreSQL 7.0 when it
goes gold, so if someone could let me know when it is available, that
would be much appreciated.
A review of 7.0.1 would be a better choice ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Feb 17 10:02:26 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 KAA75823
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 10:01:08 -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 PAA05238;
Thu, 17 Feb 2000 15:11:19 GMT
Sender: lockhart@hub.org
Message-ID: <38AC0F97.5400498C@alumni.caltech.edu>
Date: Thu, 17 Feb 2000 15:11:19 +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: Hiroshi Inoue <Inoue@tpf.co.jp>
CC: Bruce Momjian <pgman@candle.pha.pa.us>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] create database doesn't work well in MULTIBYTE mode
References: <000a01bf790c$cade54c0$2801007e@tpf.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
$6 is already converted from string to ival in another place.
It seems to me that this change is unnecessary.
I don't understand why this was changed recently.
At the moment, if the code is compiled without MULTIBYTE enabled, it
will silently ignore any "ENCODING=" clause in a CREATE DATABASE
statement.
Wouldn't it be more appropriate to throw an elog(ERROR) in this case
(or perhaps an elog(WARN))? I've got the code ready to add in.
Comments?
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Feb 17 10:10:44 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 KAA78003
for <hackers@postgreSQL.org>; Thu, 17 Feb 2000 10:10:03 -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 PAA05262;
Thu, 17 Feb 2000 15:17:34 GMT
Sender: lockhart@hub.org
Message-ID: <38AC110E.42C81175@alumni.caltech.edu>
Date: Thu, 17 Feb 2000 15:17:34 +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: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Almost there on column aliases
References: <38A3A7DB.6A684EF@alumni.caltech.edu>
<18707.950251267@sss.pgh.pa.us>
<38A3B745.E720A4AC@alumni.caltech.edu>
<18803.950253638@sss.pgh.pa.us>
<38A432D2.D6998E5B@alumni.caltech.edu>
<19051.950545044@sss.pgh.pa.us>
<38A8368B.68AF6CDA@alumni.caltech.edu>
<22598.950555491@sss.pgh.pa.us>
<38A8C61D.90557A4B@alumni.caltech.edu>
<23664.950648530@sss.pgh.pa.us> <38A9C751.7365FA7@jpl.nasa.gov>
<28639.950652834@sss.pgh.pa.us>
<38AAC6D0.2B0AB8C@alumni.caltech.edu>
<14947.950772484@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I'm currently (2000-02-16 15:40 GMT) seeing the rules test
blank-filling the "bpchar" fields. Do you see that?
Hmm. Still seeing it; here is a snippet from a diff of
results/rules.out and expected/rules.out:
...
< rtest_emp | rtest_emp_ins | CREATE RULE rtest_emp_ins
AS ON INSERT TO rtest_emp DO
INSERT INTO rtest_emplog (ename, who, "action", newsal, oldsal)
VALUES (new.ename, getpgusername(),
'hired '::bpchar, new.salary, '$0.00'::money);
...
rtest_emp | rtest_emp_ins | CREATE RULE rtest_emp_ins
AS ON INSERT TO rtest_emp DO
INSERT INTO rtest_emplog (ename, who, "action", newsal, oldsal)
VALUES (new.ename, getpgusername(),
'hired'::bpchar, new.salary, '$0.00'::money);
...
But if you are not seeing it, then perhaps my "make clean install"
isn't sufficient; I'll try a clean checkout sometime...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Feb 17 10:42:45 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 KAA85029
for <pgsql-hackers@postgresql.org>;
Thu, 17 Feb 2000 10:41: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 KAA15632;
Thu, 17 Feb 2000 10:41:38 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Definitional issue for INET types
In-reply-to: <Pine.GSO.4.02A.10002171305400.2933-100000@Oxe.DoCS.UU.SE>
References: <Pine.GSO.4.02A.10002171305400.2933-100000@Oxe.DoCS.UU.SE>
Comments: In-reply-to Peter Eisentraut <e99re41@DoCS.UU.SE>
message dated "Thu, 17 Feb 2000 13:10:49 +0100"
Date: Thu, 17 Feb 2000 10:41:38 -0500
Message-ID: <15629.950802098@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
3) You can't compare inet and cidr because they're two different (albeit
similar) things. If you want to compare them you have to explicitly cast
inet to cidr or vice versa according to 1) or 2).
This might in fact be the right answer --- maybe CIDR and INET should
have different comparison semantics. Right now the two types seem to
share exactly the same operators, which makes me wonder why we have
both.
I don't suppose Paul Vixie is still reading this list. Someone should
contact him and ask where we went wrong. Who was our point man on the
network types to begin with?
regards, tom lane
From bouncefilter Thu Feb 17 10:49:45 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 KAA86606
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 10:49:29 -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 KAA15693;
Thu, 17 Feb 2000 10:49:19 -0500 (EST)
To: sevo@ip23.net
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Definitional issue for INET types
In-reply-to: <38ABE49F.142BC894@ip23.net>
References: <14929.950772313@sss.pgh.pa.us> <38ABE49F.142BC894@ip23.net>
Comments: In-reply-to Sevo Stille <sevo@ip23.net>
message dated "Thu, 17 Feb 2000 13:07:59 +0100"
Date: Thu, 17 Feb 2000 10:49:19 -0500
Message-ID: <15690.950802559@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Sevo Stille <sevo@ip23.net> writes:
I'll see whether I can figure out something consistent for the inet data
type. As it is right now, we might just as well drop it - it is both
synonymous to cidr and to a cidr /32 host, which simply can't be.
Personally, I don't think we would lose any functionality if we drop it,
as long as we have functions that return classed network structures like
the base address and a networks subnettable range.
Hmm. One way to throw the question into stark relief is to ask:
Is '10/8' *equal to* '10.0.0.0/32', in the sense that unique indexes
and operations like SELECT DISTINCT should consider them identical?
Does your answer differ depending on whether you assume the values
are of CIDR or INET type?
Once we have decided if they are equal or not, we can certainly manage
to come up with a sort ordering for the cases that are not equal.
regards, tom lane
From bouncefilter Thu Feb 17 10:58:47 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 KAA88298
for <hackers@postgresql.org>; Thu, 17 Feb 2000 10:57:55 -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 KAA15748;
Thu, 17 Feb 2000 10:57:37 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] Almost there on column aliases
In-reply-to: <38AAC6D0.2B0AB8C@alumni.caltech.edu>
References: <38A3A7DB.6A684EF@alumni.caltech.edu>
<18707.950251267@sss.pgh.pa.us>
<38A3B745.E720A4AC@alumni.caltech.edu>
<18803.950253638@sss.pgh.pa.us>
<38A432D2.D6998E5B@alumni.caltech.edu>
<19051.950545044@sss.pgh.pa.us>
<38A8368B.68AF6CDA@alumni.caltech.edu>
<22598.950555491@sss.pgh.pa.us>
<38A8C61D.90557A4B@alumni.caltech.edu>
<23664.950648530@sss.pgh.pa.us> <38A9C751.7365FA7@jpl.nasa.gov>
<28639.950652834@sss.pgh.pa.us>
<38AAC6D0.2B0AB8C@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Wed, 16 Feb 2000 15:48:32 +0000"
Date: Thu, 17 Feb 2000 10:57:37 -0500
Message-ID: <15745.950803057@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
I've just looked it up in the Date book: table aliases are optional in
general, but column aliases require a table alias. The bnf looks like
table [ [ AS ] range-variable [ ( column-commalist ) ] ]
OK, but that doesn't really solve my concern about rule bloat, because
if you write "FROM table alias", you'll still get a list of column names
appended to that by the system.
Here is a possible answer that I think would address both our concerns:
keep track of how many column aliases the user actually wrote (without
counting the Attr-list entries added by the system for its internal
convenience), and dump only the user-supplied aliases in rule strings.
This'd be easy enough to do with an extra field in Attr nodes.
It'd not only preserve compactness in the cases we previously handled,
but it'd make the reverse-listed display of rules more like the original
query in cases where the user did write some aliases (but not a full
set).
regards, tom lane
From bouncefilter Thu Feb 17 11:08:45 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 LAA90607
for <hackers@postgreSQL.org>; Thu, 17 Feb 2000 11:08:25 -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 LAA15822;
Thu, 17 Feb 2000 11:08:13 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Date/time types: big change
In-reply-to: <Pine.GSO.4.02A.10002171258480.2933-100000@Oxe.DoCS.UU.SE>
References: <Pine.GSO.4.02A.10002171258480.2933-100000@Oxe.DoCS.UU.SE>
Comments: In-reply-to Peter Eisentraut <e99re41@DoCS.UU.SE>
message dated "Thu, 17 Feb 2000 13:00:17 +0100"
Date: Thu, 17 Feb 2000 11:08:13 -0500
Message-ID: <15819.950803693@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
On Thu, 17 Feb 2000, Tom Lane wrote:
I think it's too late in the 7.0 cycle to start thinking about renaming
the numeric types.
I didn't mean that this should happen now or even soon. It was more of a
policy/practice inquiry.
OK, fair enough. What I'm thinking at the moment is let's wait and see
how painful or painless the transition is for the date/time types.
The number of squawks we hear about that should give us a clue whether
we want to be in a hurry to rename the numeric types...
regards, tom lane
From bouncefilter Thu Feb 17 11:12:45 2000
Received: from andie.ip23.net (andie.ip23.net [212.83.32.23])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA91356
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 11:12:02 -0500 (EST) (envelope-from sevo@ip23.net)
Received: from imap1.ip23.net (imap1.ip23.net [212.83.32.35])
by andie.ip23.net (8.9.3/8.9.3) with ESMTP id RAA14240;
Thu, 17 Feb 2000 17:11:28 +0100 (CET)
Received: from ip23.net (spc.ip23.net [212.83.32.122])
by imap1.ip23.net (8.9.3/8.9.3) with ESMTP id RAA16342;
Thu, 17 Feb 2000 17:13:23 +0100 (CET)
Sender: sevo@imap1.ip23.net
Message-ID: <38AC1DB0.81A4677A@ip23.net>
Date: Thu, 17 Feb 2000 17:11:28 +0100
From: Sevo Stille <sevo@ip23.net>
Organization: IP23
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i686)
X-Accept-Language: de, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Definitional issue for INET types
References: <14929.950772313@sss.pgh.pa.us> <38ABE49F.142BC894@ip23.net>
<15690.950802559@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Hmm. One way to throw the question into stark relief is to ask:
Is '10/8' *equal to* '10.0.0.0/32', in the sense that unique indexes
and operations like SELECT DISTINCT should consider them identical?
Does your answer differ depending on whether you assume the values
are of CIDR or INET type?
Well, in a CIDR context, they positively are different, '10.0.0.0/32' is
a host, and '10/8' is a network, and our application would positively
treat either entirely different. CIDR consistently works by
apply-mask-and-process.
In a INET context, the answer is not that easy, as net and mask have no
defined behaviour as a tuple. The mask will in some cases be a
independent entity, which presumably is why Paul Vixie made meaningless
net/mask combinations legal there. If INET is used to store e.g. a
Cisco wildcard value, the /xx part is meaningless - however, 10.1.2.3/8
would not be a shorthand for 10/8 then.
As far as ipmeter is concerned, we found out that INET is of no use for
us - even if there are some strange things you might do with odd
net/mask patterns, few of them follow any easily defined paradigm.
Personally, I am all for dropping INET, or for defining it to be
maskless (which could be done by forcing /32 for it).
Sevo
From bouncefilter Thu Feb 17 11:24:47 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 LAA94194
for <hackers@postgreSQL.org>; Thu, 17 Feb 2000 11:24:36 -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 LAA15940;
Thu, 17 Feb 2000 11:24:29 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Almost there on column aliases
In-reply-to: <38AC110E.42C81175@alumni.caltech.edu>
References: <38A3A7DB.6A684EF@alumni.caltech.edu>
<18707.950251267@sss.pgh.pa.us>
<38A3B745.E720A4AC@alumni.caltech.edu>
<18803.950253638@sss.pgh.pa.us>
<38A432D2.D6998E5B@alumni.caltech.edu>
<19051.950545044@sss.pgh.pa.us>
<38A8368B.68AF6CDA@alumni.caltech.edu>
<22598.950555491@sss.pgh.pa.us>
<38A8C61D.90557A4B@alumni.caltech.edu>
<23664.950648530@sss.pgh.pa.us> <38A9C751.7365FA7@jpl.nasa.gov>
<28639.950652834@sss.pgh.pa.us>
<38AAC6D0.2B0AB8C@alumni.caltech.edu>
<14947.950772484@sss.pgh.pa.us>
<38AC110E.42C81175@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Thu, 17 Feb 2000 15:17:34 +0000"
Date: Thu, 17 Feb 2000 11:24:28 -0500
Message-ID: <15936.950804668@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
I'm currently (2000-02-16 15:40 GMT) seeing the rules test
blank-filling the "bpchar" fields. Do you see that?
Hmm. Still seeing it; here is a snippet from a diff of
results/rules.out and expected/rules.out:
...
< rtest_emp | rtest_emp_ins | CREATE RULE rtest_emp_ins
AS ON INSERT TO rtest_emp DO
INSERT INTO rtest_emplog (ename, who, "action", newsal, oldsal)
VALUES (new.ename, getpgusername(),
'hired '::bpchar, new.salary, '$0.00'::money);
...rtest_emp | rtest_emp_ins | CREATE RULE rtest_emp_ins
AS ON INSERT TO rtest_emp DO
INSERT INTO rtest_emplog (ename, who, "action", newsal, oldsal)
VALUES (new.ename, getpgusername(),
'hired'::bpchar, new.salary, '$0.00'::money);
...
Oh, I'm sorry, I *am* seeing that. I don't think this has anything
to do with your changes; the system's been producing pre-padded
strings in those tests for a while now, at least on good days ;-).
If you look closely you'll see that the padded string has just been
pre-coerced to the length of the char() target field. I don't think
that's wrong.
The difference is normally masked from causing a comparison failure
in the regress tests because we use diff -w to look for differences.
Probably the expected file was last updated at a time when it wasn't
doing that...
regards, tom lane
From bouncefilter Thu Feb 17 11:38: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 LAA97356
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 11:38:06 -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 LAA16032;
Thu, 17 Feb 2000 11:38:01 -0500 (EST)
To: Sevo Stille <sevo@ip23.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Definitional issue for INET types
In-reply-to: <38AC1DB0.81A4677A@ip23.net>
References: <14929.950772313@sss.pgh.pa.us> <38ABE49F.142BC894@ip23.net>
<15690.950802559@sss.pgh.pa.us> <38AC1DB0.81A4677A@ip23.net>
Comments: In-reply-to Sevo Stille <sevo@ip23.net>
message dated "Thu, 17 Feb 2000 17:11:28 +0100"
Date: Thu, 17 Feb 2000 11:38:01 -0500
Message-ID: <16029.950805481@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Sevo Stille <sevo@ip23.net> writes:
Hmm. One way to throw the question into stark relief is to ask:
Is '10/8' *equal to* '10.0.0.0/32', in the sense that unique indexes
and operations like SELECT DISTINCT should consider them identical?
Does your answer differ depending on whether you assume the values
are of CIDR or INET type?
Well, in a CIDR context, they positively are different, '10.0.0.0/32' is
a host, and '10/8' is a network, and our application would positively
treat either entirely different. CIDR consistently works by
apply-mask-and-process.
OK. Now let's try you on this one: true or false?
'10.1.2.3/8'::cidr = '10/8'::cidr
(which was actually the example I meant to ask about above, but
carelessly cut-and-pasted the wrong values :-(.)
In a INET context, the answer is not that easy, as net and mask have no
defined behaviour as a tuple. The mask will in some cases be a
independent entity, which presumably is why Paul Vixie made meaningless
net/mask combinations legal there.
I think that was the idea, all right, which would seem to suggest that
we ought to compare all the bits of the IP addresses, and then compare
the bitcounts (since the bitcount is just a compact representation of a
logically separate netmask, and has nothing to do with the validity of
the IP address). But I'm not sure whether this holds good for CIDR too.
Personally, I am all for dropping INET, or for defining it to be
maskless (which could be done by forcing /32 for it).
If you don't need a mask, leave out the /32 --- or even add a column
constraint requiring it to be 32. I don't see that it's necessary
to tell other people that they can't have a mask. CIDR may be a
different story however.
regards, tom lane
From bouncefilter Thu Feb 17 12:00:49 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 LAA01463
for <hackers@postgreSQL.org>; Thu, 17 Feb 2000 11:59: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
LAA16756;
Thu, 17 Feb 2000 11:58:11 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002171658.LAA16756@candle.pha.pa.us>
Subject: Re: [HACKERS] Date/time types: big changeu
In-Reply-To: <38AB91BF.7510F467@alumni.caltech.edu> from Thomas Lockhart at
"Feb 17, 2000 06:14:23 am"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Thu, 17 Feb 2000 11:58:10 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>,
Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I've been talking about this for quite some time, but there *really*
is no excuse to not go to the ISO date/time standard. Every other date
style is prone to misinterpretation, and the ISO standard is commonly
used in other instances where reliable date reporting is needed.I've waited until a major rev to do this, and the groundwork has been
there for a year or two. There are some good summaries of the issues
on the web.But, I'd have no objection to a configure or initdb option; I *would*
suggest that the old default (and it is the default mostly because
original Postgres95 had no other styles implemented) is a relatively
poor choice, and that ISO should be the default choice in the absence
of an explicit configure or initdb switch.
Well, no one is objecting to this yet, so it may be a good choice.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 17 12:04:46 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA02641
for <pgsql-hackers@postgresql.org>;
Thu, 17 Feb 2000 12:03:50 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64228 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S5945AbQBQRCz>;
Thu, 17 Feb 2000 18:02:55 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12LUMt-0001k5-00
for pgsql-hackers@postgresql.org; Thu, 17 Feb 2000 18:05:31 +0100
Date: Thu, 17 Feb 2000 18:05:31 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: psql and Control-C
Message-ID: <Pine.LNX.4.21.0002171537260.3047-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
Some people have indicated that they don't like how psql currently handles
Control-C if no query is in progress. I consider the behaviour of the
shells desirable but, quite frankly, I don't know how to do it.
For some reason a readline'd session always wants me to press one more key
after Control-C before getting back to a clean prompt. A much bigger
problem is that if I don't use/have readline then I don't see a way to
preempt the fgets() call.
So unless someone has a hint or wants to look at it, I could offer
ignoring the signal altogether in interactive mode, and perhaps make it
stop scripts in the other case. (Leaving the query cancelling as is, of
course.)
Actually, shouldn't a Ctrl-C in a script cancel the query *and* stop the
script at all times?
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Feb 17 13:44:48 2000
Received: from feivel.fam-meskes.de (h-62.96.160.236.host.de.colt.net
[62.96.160.236]) by hub.org (8.9.3/8.9.3) with ESMTP id NAA25582
for <hackers@postgresql.org>; Thu, 17 Feb 2000 13:43:52 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 288AC2BD59; Thu, 17 Feb 2000 19:41:07 +0100 (CET)
Date: Thu, 17 Feb 2000 19:41:07 +0100
From: Michael Meskes <meskes@postgresql.org>
To: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] Date/time types: big changeu
Message-ID: <20000217194107.A1302@fam-meskes.de>
Mail-Followup-To: Postgres Hackers List <hackers@postgresql.org>
References: <200002161855.NAA05756@candle.pha.pa.us>
<4548.950738948@sss.pgh.pa.us>
<38AB91BF.7510F467@alumni.caltech.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <38AB91BF.7510F467@alumni.caltech.edu>;
from lockhart@alumni.caltech.edu on Thu, Feb 17, 2000 at
06:14:23AM +0000
Sender: michael@fam-meskes.de
On Thu, Feb 17, 2000 at 06:14:23AM +0000, Thomas Lockhart wrote:
I've been talking about this for quite some time, but there *really*
is no excuse to not go to the ISO date/time standard. Every other date
Yes, please let's go to this standard. It's an awful lot of work to fix apps
just because they expect US notation and most people in Germany cannot even
think about typing it that way.
poor choice, and that ISO should be the default choice in the absence
of an explicit configure or initdb switch.
Completely agree.
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 Thu Feb 17 13:44:47 2000
Received: from feivel.fam-meskes.de (h-62.96.160.236.host.de.colt.net
[62.96.160.236]) by hub.org (8.9.3/8.9.3) with ESMTP id NAA25600
for <hackers@postgreSQL.org>; Thu, 17 Feb 2000 13:44:02 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 81F6E2BD5A; Thu, 17 Feb 2000 19:42:33 +0100 (CET)
Date: Thu, 17 Feb 2000 19:42:33 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Date/time types: big changeu
Message-ID: <20000217194233.B1302@fam-meskes.de>
Mail-Followup-To: Postgres Hackers List <hackers@postgreSQL.org>
References: <tgl@sss.pgh.pa.us> <200002162320.XAA27647@linda.lfix.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <200002162320.XAA27647@linda.lfix.co.uk>;
from olly@lfix.co.uk on Wed, Feb 16, 2000 at 11:20:26PM +0000
Sender: michael@fam-meskes.de
On Wed, Feb 16, 2000 at 11:20:26PM +0000, Oliver Elphick wrote:
I have code to let the installer choose the default datestyle in Debian's installation script for PostgreSQL. It makes its own best guess on
the basis of the timezone and then asks the user with its own guess as
the presented default.
Yes, Oliver's script works nicely on all Debian machines.
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 Thu Feb 17 23:40:55 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 XAA58142
for <hackers@postgreSQL.org>; Thu, 17 Feb 2000 23:40:04 -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 SAA05569;
Thu, 17 Feb 2000 18:48:12 GMT
Sender: lockhart@hub.org
Message-ID: <38AC426B.D335EF52@alumni.caltech.edu>
Date: Thu, 17 Feb 2000 18:48:11 +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: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Date/time types: big changeu
References: <200002162320.XAA27647@linda.lfix.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Also, I've changed the default date style to "ISO" (not just in
time for Y2K, but we'll be ready for "Y3K").... Perhaps there should be a way to select the default date
style at configure or initdb time. I don't mind if the "default default"
is ISO, but if I had apps that were dependent on the old default setting
I'd sure be annoyed by this change...
Well, that is the joy of a major release; not all backward
compatibility is guaranteed. This has been a *documented change* for
at least a year or two; check the chapter on date/time data types for
more info.
However, istm that we could/should have more "default settings"
traveling in the pg_database table. We've got the encoding, which if
set for template1 will be set for every db. We've got the database
location, which can point to an alternate location.
Wouldn't it be reasonable to allow a "default datestyle", or something
more general to help with other defaults? Hmm, could be a text field
which allows something like "PGDATESTYLE='ISO',LANGUAGE='french',..."
so that it is extensible, but maybe that detail is a bad idea because
it is a bit fragile.
What fields would be appropriate for v7.0? The datestyle and timezone
are two obvious candidates, and if we add them now then we could make
use of them later.
Later, we can get things like
ALTER DATABASE SET DEFAULT DATESTYLE='ISO';
etc etc.
For v7.1, I'm hoping to work with Tatsuo and others to get closer to
the general character sets and collation sequences allowed by SQL92.
At that point, the MULTIBYTE hardcoded differences in the backend
might go away and we will need these configurable default values.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Feb 17 23:40: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 XAA58144
for <hackers@postgreSQL.org>; Thu, 17 Feb 2000 23:40:06 -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 TAA05608;
Thu, 17 Feb 2000 19:02:57 GMT
Sender: lockhart@hub.org
Message-ID: <38AC45E1.3B79BF9E@alumni.caltech.edu>
Date: Thu, 17 Feb 2000 19:02: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: Tom Lane <tgl@sss.pgh.pa.us>
CC: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Almost there on column aliases
References: <38A3A7DB.6A684EF@alumni.caltech.edu>
<18707.950251267@sss.pgh.pa.us>
<38A3B745.E720A4AC@alumni.caltech.edu>
<18803.950253638@sss.pgh.pa.us>
<38A432D2.D6998E5B@alumni.caltech.edu>
<19051.950545044@sss.pgh.pa.us>
<38A8368B.68AF6CDA@alumni.caltech.edu>
<22598.950555491@sss.pgh.pa.us>
<38A8C61D.90557A4B@alumni.caltech.edu>
<23664.950648530@sss.pgh.pa.us> <38A9C751.7365FA7@jpl.nasa.gov>
<28639.950652834@sss.pgh.pa.us>
<38AAC6D0.2B0AB8C@alumni.caltech.edu>
<15745.950803057@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
OK, but that doesn't really solve my concern about rule bloat, because
if you write "FROM table alias", you'll still get a list of column names
appended to that by the system.
Here is a possible answer that I think would address both our concerns:
keep track of how many column aliases the user actually wrote (without
counting the Attr-list entries added by the system for its internal
convenience), and dump only the user-supplied aliases in rule strings.
This'd be easy enough to do with an extra field in Attr nodes.
It'd not only preserve compactness in the cases we previously handled,
but it'd make the reverse-listed display of rules more like the original
query in cases where the user did write some aliases (but not a full
set).
I put the Attr node into the rte because column aliases need to travel
with the table alias. But I'm not sure how the table alias is actually
used after being transformed back and forth for rules. And I'm not
sure how we would use the column aliases beyond the parser in the
future.
How about if I have the rte->ref Attr node hold *only* the column
aliases specified by the user (which addresses your concern), and then
make a "hidden" Attr node (or list of nodes; see below) which is build
and used in the parser but which is never read or written by the
dump/transformation stuff used for rules. So I'll define a new Attr *
field, say "p_ref" which is used internally but ignored after I'm done
with it. I'm not *certain* this will work: I still have issues
regarding outer join syntax which I'm pretty sure are not addressed by
either the status quo or this new suggestion, but at least with a
"hidden field" I'd have some flexibility to muck around with how it is
defined and used.
Also, the "layered aliases" you can get with outer joins are not
handled yet, and I'm pretty sure that more work needs to be done on
the structures to get it to fly at all. e.g.
SELECT n, m FROM (t1 ta (a, b) OUTER JOIN t2 tb (a, c)) AS tj (n,
m);
cannot currently be transformed properly for rules given the info
available in the existing structures. This is true because there is no
equivalent query which allows you to specify anything like t1, ta, t2,
or tb in the target list, and there is no way currently to carry along
the "tj (n, m)" info.
Comments on any or all?
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Feb 17 14:12:51 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 OAA34347
for <hackers@postgreSQL.org>; Thu, 17 Feb 2000 14:12:06 -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 TAA05729;
Thu, 17 Feb 2000 19:19:36 GMT
Sender: lockhart@hub.org
Message-ID: <38AC49C8.EF21B38D@alumni.caltech.edu>
Date: Thu, 17 Feb 2000 19:19:36 +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: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Almost there on column aliases
References: <38A3A7DB.6A684EF@alumni.caltech.edu>
<18707.950251267@sss.pgh.pa.us>
<38A3B745.E720A4AC@alumni.caltech.edu>
<18803.950253638@sss.pgh.pa.us>
<38A432D2.D6998E5B@alumni.caltech.edu>
<19051.950545044@sss.pgh.pa.us>
<38A8368B.68AF6CDA@alumni.caltech.edu>
<22598.950555491@sss.pgh.pa.us>
<38A8C61D.90557A4B@alumni.caltech.edu>
<23664.950648530@sss.pgh.pa.us> <38A9C751.7365FA7@jpl.nasa.gov>
<28639.950652834@sss.pgh.pa.us>
<38AAC6D0.2B0AB8C@alumni.caltech.edu>
<14947.950772484@sss.pgh.pa.us>
<38AC110E.42C81175@alumni.caltech.edu>
<15936.950804668@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I'm currently (2000-02-16 15:40 GMT) seeing the rules test
blank-filling the "bpchar" fields. Do you see that?Hmm. Still seeing it; here is a snippet from a diff of
results/rules.out and expected/rules.out:Oh, I'm sorry, I *am* seeing that. I don't think this has anything
to do with your changes; the system's been producing pre-padded
strings in those tests for a while now, at least on good days ;-).
If you look closely you'll see that the padded string has just been
pre-coerced to the length of the char() target field. I don't think
that's wrong.
Ah, right; "bpchar" is "blank padded char". But would there be any
downside to removing those blank pads when doing the transformation
back to a printed query? i.e. if the outnode() functions stripped the
padding? Or maybe at that point there is not enough info to do it?
Seems like an ill-advised char(2000) or two in a table might bollux up
a lot of potential rules (even more than my extraneous column aliases
might ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Feb 17 14:46:48 2000
Received: from pille.addcom.de (h-62.96.128.34.host.de.colt.net
[62.96.128.34])
by hub.org (8.9.3/8.9.3) with SMTP id OAA41588
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 14:46:18 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: (qmail 5358 invoked from network); 17 Feb 2000 19:44:53 -0000
Received: from h-62.96.160.27.host.de.colt.net (HELO feivel.fam-meskes.de)
(62.96.160.27)
by pille.addcom.de with SMTP; 17 Feb 2000 19:44:53 -0000
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 39AE52BD57; Thu, 17 Feb 2000 20:44:05 +0100 (CET)
Date: Thu, 17 Feb 2000 20:44:05 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] function question yet again
Message-ID: <20000217204405.A3533@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
References: <20000215131439.A2553@fam-meskes.de>
<38A91179.AB924F0A@mascari.com>
<20000215152620.A11746@fam-meskes.de>
<38A96C2F.6796050A@mascari.com> <24028.950650165@sss.pgh.pa.us>
<20000216081422.A1623@fam-meskes.de> <38AB7428.ECFB7471@wtal.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <38AB7428.ECFB7471@wtal.de>;
from christof.petig@wtal.de on Thu, Feb 17, 2000 at 05:08:08AM
+0100
Sender: michael@fam-meskes.de
On Thu, Feb 17, 2000 at 05:08:08AM +0100, Christof Petig wrote:
It should be possible to create a SPI based libecpg.so! Though I don't
know if it is worth the effort (besides getting portable server code
(WOW)!) Hmmm. I come to like this idea.
I really do like this idea to. But it is not realistic to get this one
finished before 7.0 though.
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 Thu Feb 17 15:25: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 PAA50626
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 15:25:40 -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
PAA26232;
Thu, 17 Feb 2000 15:25:22 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002172025.PAA26232@candle.pha.pa.us>
Subject: Re: [HACKERS] psql and Control-C
In-Reply-To: <Pine.LNX.4.21.0002171537260.3047-100000@localhost.localdomain>
from Peter Eisentraut at "Feb 17, 2000 06:05:31 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Thu, 17 Feb 2000 15:25:22 -0500 (EST)
CC: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM950819122-24612-0_
Content-Transfer-Encoding: 7bit
--ELM950819122-24612-0_
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Charset ISO-8859-1 unsupported, filtering to ASCII...]
Some people have indicated that they don't like how psql currently handles
Control-C if no query is in progress. I consider the behaviour of the
shells desirable but, quite frankly, I don't know how to do it.For some reason a readline'd session always wants me to press one more key
after Control-C before getting back to a clean prompt. A much bigger
problem is that if I don't use/have readline then I don't see a way to
preempt the fgets() call.So unless someone has a hint or wants to look at it, I could offer
ignoring the signal altogether in interactive mode, and perhaps make it
stop scripts in the other case. (Leaving the query cancelling as is, of
course.)Actually, shouldn't a Ctrl-C in a script cancel the query *and* stop the
script at all times?
Seems we can just ignore ^C if a query is not being run. Is that OK
with everyone. Looks easy to do.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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--ELM950819122-24612-0_
Content-Type: text/plain
Content-Disposition: inline; filename="/bjm/diff"
Content-Transfer-Encoding: 7bit
--ELM950819122-24612-0_
--ELM950819122-24612-0_--
From bouncefilter Thu Feb 17 17:20:50 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 RAA79897
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 17:19:52 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12LZ7Z-0003kqC; Thu, 17 Feb 100 23:10 MET
Message-Id: <m12LZ7Z-0003kqC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] PC Week PostgreSQL benchmark results posted online
(fwd)
In-Reply-To: <Pine.BSF.4.10.10002171009160.10395-100000@rage.hub.org> from
"Jeff MacDonald <jeff@pgsql.com>" at "Feb 17, 2000 10:10:35 am"
To: Jeff MacDonald <jeff@pgsql.com>
Date: Thu, 17 Feb 2000 23:10:01 +0100 (CET)
CC: pgsql-hackers@postgreSQL.org
Reply-To: Jan Wieck <wieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Tim Dyck asked me to forward this on to the list.
*****************************
FYI, the story is available online at:
http://www.zdnet.com/pcweek/stories/news/0,4153,2436153,00.html
As I think I have mentioned, I would like to review PostgreSQL 7.0 when it
goes gold, so if someone could let me know when it is available, that
would be much appreciated.
And that'll be an interesting one. Just looked into the MSSQL
7.0 docs today. They don't have referential actions! So
something like ON UPDATE CASCADE/... must be implemented the
hard way as triggers. Need to look it up once again tomorrow
to see if constraints can be deferred or not.
On this detail, we already left at least one (and definitely
not the smallest) commercial database behind on the way to
SQL3.
Can someone take a look at Interbase, Oracle and others about
it?
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 Feb 17 18:27:56 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA92171
for <hackers@postgresql.org>; Thu, 17 Feb 2000 18:27:04 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA12804 for <hackers@postgresql.org>;
Fri, 18 Feb 2000 10:26:30 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0Z6oFZ;
Fri Feb 18 10:26:06 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA29364 for <hackers@postgresql.org>;
Fri, 18 Feb 2000 10:26:05 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdrn_Ms_; Fri Feb 18 10:25:15 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA03852
for <hackers@postgresql.org>; Fri, 18 Feb 2000 10:25:14 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
KAA02249
for <hackers@postgresql.org>; Fri, 18 Feb 2000 10:24:33 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38AC82F7.5C7C529A@nimrod.itg.telecom.com.au>
Date: Fri, 18 Feb 2000 10:23:35 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] libpq
References: <38A2AE00.9EB1BE9B@bitmead.com> <15283.950196239@sss.pgh.pa.us>
<38A396B0.BF0509A5@nimrod.itg.telecom.com.au>
<18587.950249454@sss.pgh.pa.us>
<38A3ADE3.AAE1FC7D@nimrod.itg.telecom.com.au>
<19512.950281813@sss.pgh.pa.us> <38A6A3AE.CAF01A62@bitm
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
I haven't looked at it because I am trying to finish up other stuff
before we go beta. Will get back to you later. I imagine other
people are in deadline mode also...
Ok, sure.
From bouncefilter Thu Feb 17 23:28:55 2000
Received: from Hydro.CAM.ORG (Hydro.CAM.ORG [198.168.100.7])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA55670
for <pgsql-hackers@postgresql.org>;
Thu, 17 Feb 2000 23:28:00 -0500 (EST)
(envelope-from admin@wtbwts.com)
Received: from www.pcr.ca (www.pcr.ca [207.139.158.13] (may be forged))
by Hydro.CAM.ORG (8.8.8/8.8.4) with ESMTP
id XAA08033 for <pgsql-hackers@postgresql.org>;
Thu, 17 Feb 2000 23:27:30 -0500 (EST)
Date: Thu, 17 Feb 2000 23:27:50 +0000 (GMT)
From: Marc Tardif <admin@wtbwts.com>
X-Sender: admin@server.b0x.com
To: pgsql-hackers@postgresql.org
Subject: queries on 2+ indices
Message-ID: <Pine.BSF.4.10.10002172315000.16661-100000@server.b0x.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
How does postgresql perform queries on one table using more than one
index? For example, assuming the following:
create table t1 ( f1 int, f2 int);
create index t1_f1 on t1 (f1);
create index t1_f2 on t1 (f2);
select * from t1 where f1=123 and f2=456;
By default, both indices will be btree's making them sorted. Therefore,
does postgresql retrieve all matching records from t1_f1 and t1_f2 into
intermediate tables and then performs somekind of merge sort before
retrieving the final results from t1? If so or if not, are intermediate
files created for this kind of operation or does the postgresql support
queries to multiple fields directly in its indexing system (perhaps aided
by "analyze")? Or, does this kind of operation rely much on memory?
I have tried making heads or tails out of the source code, but postgresql
is far more daunting than I had expected. Nevertheless, for future
reference, how could I find answers to questions about query management by
postgresql?
Many thanks for your excellent ordbms,
Marc Tardif
From bouncefilter Thu Feb 17 18:37:53 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA95059
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 18:37:48 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA22477; Fri, 18 Feb 2000 10:37:15 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0ogN2Z;
Fri Feb 18 10:36:57 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA14193; Fri, 18 Feb 2000 10:36:56 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdYzB15_; Fri Feb 18 10:35:50 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA13679;
Fri, 18 Feb 2000 10:35:49 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
KAA02478; Fri, 18 Feb 2000 10:35:07 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38AC8571.1306E0B8@nimrod.itg.telecom.com.au>
Date: Fri, 18 Feb 2000 10:34:09 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and Control-C
References: <Pine.LNX.4.21.0002171537260.3047-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Peter Eisentraut wrote:
Some people have indicated that they don't like how psql currently handles
Control-C if no query is in progress. I consider the behaviour of the
shells desirable but, quite frankly, I don't know how to do it.
The typical way to do this sort of thing is to longjmp back to the main
loop. And I think if you look at sig.c in bash, this is probably what
they are doing.
Actually, shouldn't a Ctrl-C in a script cancel the query *and* stop the
script at all times?
Yes.
From bouncefilter Thu Feb 17 18:42:52 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA96218
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 18:42:40 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA26648; Fri, 18 Feb 2000 10:41:56 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdIeMje_;
Fri Feb 18 10:41:33 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA20397; Fri, 18 Feb 2000 10:41:25 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdjN0p3_; Fri Feb 18 10:40:22 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA17629;
Fri, 18 Feb 2000 10:40:21 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
KAA02613; Fri, 18 Feb 2000 10:39:41 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38AC8682.6CB02FF9@nimrod.itg.telecom.com.au>
Date: Fri, 18 Feb 2000 10:38:42 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Hannu Krosing <hannu@tm.ee>
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] FYI: BNF for SQL93 and SQL-3
References: <38AB20DA.EAA7B9B6@tm.ee>
<38AB5E48.CD2282E5@nimrod.itg.telecom.com.au>
<38ABBFAC.FAEBB799@tm.ee>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I guess it is lifted from the standard as it was in september 1993.
OTOH, the SQL3 standard is still not final.
Is it progressing, or is it in disrepair?
From bouncefilter Thu Feb 17 18:40:51 2000
Received: from pmail1.gmx.net (pmail1.gmx.net [194.221.183.71])
by hub.org (8.9.3/8.9.3) with SMTP id SAA95669
for <pgsql-hackers@postgresql.org>;
Thu, 17 Feb 2000 18:40:22 -0500 (EST) (envelope-from dumont@gmx.net)
Received: (qmail 5083 invoked by uid 0); 17 Feb 2000 23:39:49 -0000
Received: from ae0b0.pppool.de (HELO planet) (213.6.224.176)
by pmail1.gmx.net with SMTP; 17 Feb 2000 23:39:49 -0000
Message-ID: <001901bf79a0$87014980$b0e006d5@planet>
From: "Herr Dumont" <dumont@gmx.net>
To: <pgsql-hackers@postgresql.org>
Subject: password change / table creation
Date: Fri, 18 Feb 2000 00:40:23 +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.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
There are two questions in the pgsql-admin mailing list which are very often
asked, but nobody seems to have a reasonable answer to these.
So I decided to post them here and I hope anyone can help me (and many
others) !
- Can a PostgreSQL user change his own password without having
"usesuper" set to 't' in pg_shadow ?
I think this should be possible with a PostgreSQL C function (or
PL/Tcl) which alters the "passwd" attribute of the pg_shadow table and
after that copies the contents of this table to the pg_pwd ASCII file
(and generates an empty pg_pwd.reload).
But I have no idea how to manipulate and copy tables within PostgreSQL
C functions.
Does anybody know if there is already such a function or any other way
to achieve the above mentioned functionality ?
- Can the Postgres superuser prevent a user from creating tables in any
database the user likes to ?
It would be good to have a way to restrict the use of the "CREATE
TABLE" SQL statement so that a user can only create tables in
databases he is explicitly allowed to.
Does anyone have an idea how to solve this problem ?
If these two features are not yet implemented I would suggest to think about
implementing them, because I (and many other people) would consider them
as important, especially in practical use.
Please let me know !
Thank you very much
RP. Dumont
From bouncefilter Thu Feb 17 18:41:51 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 SAA95853
for <hackers@postgreSQL.org>; Thu, 17 Feb 2000 18:40:56 -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 SAA17229;
Thu, 17 Feb 2000 18:40:41 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Almost there on column aliases
In-reply-to: <38AC49C8.EF21B38D@alumni.caltech.edu>
References: <38A3A7DB.6A684EF@alumni.caltech.edu>
<18707.950251267@sss.pgh.pa.us>
<38A3B745.E720A4AC@alumni.caltech.edu>
<18803.950253638@sss.pgh.pa.us>
<38A432D2.D6998E5B@alumni.caltech.edu>
<19051.950545044@sss.pgh.pa.us>
<38A8368B.68AF6CDA@alumni.caltech.edu>
<22598.950555491@sss.pgh.pa.us>
<38A8C61D.90557A4B@alumni.caltech.edu>
<23664.950648530@sss.pgh.pa.us> <38A9C751.7365FA7@jpl.nasa.gov>
<28639.950652834@sss.pgh.pa.us>
<38AAC6D0.2B0AB8C@alumni.caltech.edu>
<14947.950772484@sss.pgh.pa.us>
<38AC110E.42C81175@alumni.caltech.edu>
<15936.950804668@sss.pgh.pa.us>
<38AC49C8.EF21B38D@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Thu, 17 Feb 2000 19:19:36 +0000"
Date: Thu, 17 Feb 2000 18:40:41 -0500
Message-ID: <17226.950830841@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
Ah, right; "bpchar" is "blank padded char". But would there be any
downside to removing those blank pads when doing the transformation
back to a printed query? i.e. if the outnode() functions stripped the
padding? Or maybe at that point there is not enough info to do it?
There's not enough info to know whether trailing spaces were inserted
by the system or given by the user. I'd be pretty uncomfortable with
trying to make outfuncs.c apply a potentially semantics-changing
transformation like that. It isn't nearly smart enough to do the right
thing at present, and trying to make it smart enough seems like the
wrong direction to go in.
Seems like an ill-advised char(2000) or two in a table might bollux up
a lot of potential rules (even more than my extraneous column aliases
might ;)
Good point... of course people will be hitting other problems besides
rule length with such things, but...
Perhaps the right answer here is that addition of length-coercion
functions to an INSERT or UPDATE's targetlist entries doesn't belong
in the parser, but should be handled downstream of the rule stuff
--- right before the planner's constant-folding step seems like a
good spot. Then we wouldn't be paying for either the padding (if
the function got constant-folded out) or the function call (if not)
in the stored rule's querytree.This would also allow ruleutils.c to get rid of some grotty code it has
to try to hide said functions in the reverse-listed query. Might make
life a little easier for the rule rewriter too, I dunno.
regards, tom lane
From bouncefilter Thu Feb 17 19:05:51 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA01100
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 19:05:22 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
LAA18285 for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 11:04:48 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd04b0Tz;
Fri Feb 18 11:04:19 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
LAA22464 for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 11:04:19 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdq.NE7_; Fri Feb 18 11:03:21 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA09628
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 11:03:20 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
LAA03208 for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 11:02:41 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38AC8BE5.7AF8CF95@nimrod.itg.telecom.com.au>
Date: Fri, 18 Feb 2000 11:01:41 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and Control-C
References: <200002172025.PAA26232@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Seems we can just ignore ^C if a query is not being run. Is that OK
with everyone. Looks easy to do.
It would be a trap for new users (some old ones too) who may not know
how to escape. longjmp should be easy too, if it works.
From bouncefilter Thu Feb 17 19:12: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 TAA02526
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 19:12:24 -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
TAA14458;
Thu, 17 Feb 2000 19:11:48 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002180011.TAA14458@candle.pha.pa.us>
Subject: Re: [HACKERS] psql and Control-C
In-Reply-To: <38AC8BE5.7AF8CF95@nimrod.itg.telecom.com.au> from Chris Bitmead
at "Feb 18, 2000 11:01:41 am"
To: chris@bitmead.com
Date: Thu, 17 Feb 2000 19:11:48 -0500 (EST)
CC: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Seems we can just ignore ^C if a query is not being run. Is that OK
with everyone. Looks easy to do.It would be a trap for new users (some old ones too) who may not know
how to escape. longjmp should be easy too, if it works.
If they don't know ^D exits, they really are going to have trouble with
Unix.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 17 19:19:51 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA03853
for <pgsql-hackers@postgresql.org>;
Thu, 17 Feb 2000 19:18:52 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63170 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S4795AbQBRASI>;
Fri, 18 Feb 2000 01:18:08 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12Lb9q-0001wN-00; Fri, 18 Feb 2000 01:20:30 +0100
Date: Fri, 18 Feb 2000 01:20:30 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>, Bruce Momjian <pgman@candle.pha.pa.us>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] create database doesn't work well in MULTIBYTE mode
In-Reply-To: <38AC0F97.5400498C@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.21.0002171813320.3047-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-02-17, Thomas Lockhart mentioned:
At the moment, if the code is compiled without MULTIBYTE enabled, it
will silently ignore any "ENCODING=" clause in a CREATE DATABASE
statement.
Huh?
template1=# create database foo with encoding='LATIN1';
ERROR: Multi-byte support is not enabled
I believe that you have missed that a fair amount of work is being done in
the create_opt_encoding rule. Take a look.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Feb 17 19:23:51 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA04797
for <pgsql-hackers@postgresql.org>;
Thu, 17 Feb 2000 19:23:12 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64435 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S5848AbQBRAW0>;
Fri, 18 Feb 2000 01:22:26 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12LbEF-0001zX-00; Fri, 18 Feb 2000 01:25:03 +0100
Date: Fri, 18 Feb 2000 01:25:02 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: chris@bitmead.com
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] psql and Control-C
In-Reply-To: <38AC8571.1306E0B8@nimrod.itg.telecom.com.au>
Message-ID: <Pine.LNX.4.21.0002180124290.3047-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-02-18, Chris Bitmead mentioned:
The typical way to do this sort of thing is to longjmp back to the main
loop. And I think if you look at sig.c in bash, this is probably what
they are doing.
Don't wanna look at that GPL'd code ... ;)
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Feb 17 19:05:52 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA01209
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 19:05:35 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id QAA23419;
Thu, 17 Feb 2000 16:33:25 -0800 (PST)
Date: Thu, 17 Feb 2000 16:33:25 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: chris@bitmead.com
Cc: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and Control-C
Message-ID: <20000217163325.A21720@fw.wintelcom.net>
References: <Pine.LNX.4.21.0002171537260.3047-100000@localhost.localdomain>
<38AC8571.1306E0B8@nimrod.itg.telecom.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <38AC8571.1306E0B8@nimrod.itg.telecom.com.au>;
from chrisb@nimrod.itg.telstra.com.au on Fri, Feb 18, 2000 at
10:34:09AM +1100
* Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> [000217 16:20] wrote:
Peter Eisentraut wrote:
Some people have indicated that they don't like how psql currently handles
Control-C if no query is in progress. I consider the behaviour of the
shells desirable but, quite frankly, I don't know how to do it.The typical way to do this sort of thing is to longjmp back to the main
loop. And I think if you look at sig.c in bash, this is probably what
they are doing.Actually, shouldn't a Ctrl-C in a script cancel the query *and* stop the
script at all times?Yes.
Whoa whoa... It's a bit more complicated than you think, there's a lot
of state that gets put into libpq, i guess the simplest way would be
to do so and also cancel the transaction, but a simple longjump won't
work reliably and you'd also have to take very careful steps to make
sure you handle everything _just right_ from a signal context.
I'd rather have the inconvience of psql exiting than a not entirely
thought out mechanism for doing this properly potentially having psql
run amok on my database. :)
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
From bouncefilter Thu Feb 17 20:23:52 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id UAA17500
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 20:23:26 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
MAA02824 for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 12:22:52 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdwsRvZ_;
Fri Feb 18 12:22:09 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
MAA13751 for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 12:22:08 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdR.qa2_; Fri Feb 18 12:21:36 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id MAA24107
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 12:21:31 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
MAA05085 for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 12:20:51 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38AC9E37.2D572FAD@nimrod.itg.telecom.com.au>
Date: Fri, 18 Feb 2000 12:19:51 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and Control-C
References: <200002180011.TAA14458@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Seems we can just ignore ^C if a query is not being run. Is that OK
with everyone. Looks easy to do.It would be a trap for new users (some old ones too) who may not know
how to escape. longjmp should be easy too, if it works.If they don't know ^D exits, they really are going to have trouble with
Unix.
I mean escape from a half-typed in query, not escape from psql
altogether.
From bouncefilter Thu Feb 17 20:24:52 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id UAA17657
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 20:24:13 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
MAA03572 for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 12:23:40 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0lhkSQ;
Fri Feb 18 12:23:11 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
MAA14788 for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 12:23:10 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0Ow_Cx; Fri Feb 18 12:22:35 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id MAA25081
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 12:22:34 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
MAA05112 for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 12:21:54 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38AC9E77.19C28B36@nimrod.itg.telecom.com.au>
Date: Fri, 18 Feb 2000 12:20:55 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
CC: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and Control-C
References: <Pine.LNX.4.21.0002180124290.3047-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Peter Eisentraut wrote:
On 2000-02-18, Chris Bitmead mentioned:
The typical way to do this sort of thing is to longjmp back to the main
loop. And I think if you look at sig.c in bash, this is probably what
they are doing.Don't wanna look at that GPL'd code ... ;)
If you don't know how to interact with readline, I think you're gonna
have to look at some GPL code ;)
From bouncefilter Thu Feb 17 20:27:53 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id UAA18107
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 20:27:00 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
MAA05922 for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 12:26:27 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd00Jdyv;
Fri Feb 18 12:25:57 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
MAA18033 for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 12:25:57 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0Q9wjg; Fri Feb 18 12:25:05 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id MAA27132
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 12:25:05 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
MAA05161 for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 12:24:25 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38AC9F0D.4931DB92@nimrod.itg.telecom.com.au>
Date: Fri, 18 Feb 2000 12:23:25 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and Control-C
References: <Pine.LNX.4.21.0002171537260.3047-100000@localhost.localdomain>
<38AC8571.1306E0B8@nimrod.itg.telecom.com.au>
<20000217163325.A21720@fw.wintelcom.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Alfred Perlstein wrote:
Whoa whoa... It's a bit more complicated than you think, there's a lot
of state that gets put into libpq,
I don't think this has anything to do with libpq. This has got to do
with
psql's reading of commands _before_ they get shoved into libpq. As such
it shouldn't be that dangerous.
i guess the simplest way would be
to do so and also cancel the transaction, but a simple longjump won't
work reliably and you'd also have to take very careful steps to make
sure you handle everything _just right_ from a signal context.I'd rather have the inconvience of psql exiting than a not entirely
thought out mechanism for doing this properly potentially having psql
run amok on my database. :)--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]************
From bouncefilter Thu Feb 17 20:54:52 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA22964
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 20:53:55 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id SAA26508;
Thu, 17 Feb 2000 18:21:28 -0800 (PST)
Date: Thu, 17 Feb 2000 18:21:28 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: chris@bitmead.com
Cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and Control-C
Message-ID: <20000217182128.H21720@fw.wintelcom.net>
References: <Pine.LNX.4.21.0002180124290.3047-100000@localhost.localdomain>
<38AC9E77.19C28B36@nimrod.itg.telecom.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <38AC9E77.19C28B36@nimrod.itg.telecom.com.au>;
from chrisb@nimrod.itg.telstra.com.au on Fri, Feb 18, 2000 at
12:20:55PM +1100
* Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> [000217 17:56] wrote:
Peter Eisentraut wrote:
On 2000-02-18, Chris Bitmead mentioned:
The typical way to do this sort of thing is to longjmp back to the main
loop. And I think if you look at sig.c in bash, this is probably what
they are doing.Don't wanna look at that GPL'd code ... ;)
If you don't know how to interact with readline, I think you're gonna
have to look at some GPL code ;)
Actually, FreeBSD(*) has 'libedit' which is pretty nice, it could
be made to work under other systems and has a nice unencumbered
license. :)
-Alfred
(*)
* Copyright (c) 1992, 1993
* The Regents of the University of California. All rights reserved.
*
* This code is derived from software contributed to Berkeley by
* Christos Zoulas of Cornell University.
(*)
From bouncefilter Thu Feb 17 23:39:55 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 XAA57978
for <pgsql-hackers@postgreSQL.org>;
Thu, 17 Feb 2000 23:39:08 -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 EAA06619;
Fri, 18 Feb 2000 04:49:29 GMT
Sender: lockhart@hub.org
Message-ID: <38ACCF59.875C0222@alumni.caltech.edu>
Date: Fri, 18 Feb 2000 04:49: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: Peter Eisentraut <peter_e@gmx.net>
CC: Hiroshi Inoue <Inoue@tpf.co.jp>, Bruce Momjian <pgman@candle.pha.pa.us>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] create database doesn't work well in MULTIBYTE mode
References: <Pine.LNX.4.21.0002171813320.3047-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
At the moment, if the code is compiled without MULTIBYTE enabled, it
will silently ignore any "ENCODING=" clause in a CREATE DATABASE
statement.template1=# create database foo with encoding='LATIN1';
ERROR: Multi-byte support is not enabled
I believe that you have missed that a fair amount of work is being done in
the create_opt_encoding rule. Take a look.
Ah, thanks. I was misled (why try actually testing it? I was reading
the source ;) by some crufty code above createdb_opt_encoding (some
tabs removed for readability):
...
#ifdef MULTIBYTE
n->encoding = $6;
#else
n->encoding = 0;
#endif
...
where in fact if MULTIBYTE is not enabled and $6 is non-empty, the $6
production never returns! I'm planning on fixing this up (yacc
willing) to *not* do anything special when MULTIBYTE is on or off, but
will instead embed all of this funny business down in
createdb_opt_encoding with the other stuff already there.
So, why does the createdb_opt_encoding ($6 above) bother trying to
return "-1" when MULTIBYTE is disabled, when that -1 is ignored and
replaced with a zero anyway? Is it acceptable to return -1, as the $6
production does, or should it really be returning the zero which is
passed along??
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Feb 17 23: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 XAA60837
for <hackers@postgreSQL.org>; Thu, 17 Feb 2000 23:54: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
XAA04871;
Thu, 17 Feb 2000 23:52:39 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002180452.XAA04871@candle.pha.pa.us>
Subject: Re: [HACKERS] Date/time types: big changeu
In-Reply-To: <38AC426B.D335EF52@alumni.caltech.edu> from Thomas Lockhart at
"Feb 17, 2000 06:48:11 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Thu, 17 Feb 2000 23:52:39 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>,
Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Also, I've changed the default date style to "ISO" (not just in
time for Y2K, but we'll be ready for "Y3K").... Perhaps there should be a way to select the default date
style at configure or initdb time. I don't mind if the "default default"
is ISO, but if I had apps that were dependent on the old default setting
I'd sure be annoyed by this change...Well, that is the joy of a major release; not all backward
compatibility is guaranteed. This has been a *documented change* for
at least a year or two; check the chapter on date/time data types for
more info.
However, istm that we could/should have more "default settings"
traveling in the pg_database table. We've got the encoding, which if
set for template1 will be set for every db. We've got the database
location, which can point to an alternate location.
But we have to store this information in the database because it is
related to how the data is stored. Do the date/time fields also have
that assumption _in_ that stored data? If so, we need it stored in the
database, if not, it seems some SET command or psql startup file setting
is enough. Many people work on the same database from different
locations and may need different settings. I would only store database
settings that relate to the data, not how the data is displayed. That
stuff belongs outside the database, I think.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 17 23:55:58 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 XAA61019
for <hackers@postgresql.org>; Thu, 17 Feb 2000 23:55:10 -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
XAA04906;
Thu, 17 Feb 2000 23:53:23 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002180453.XAA04906@candle.pha.pa.us>
Subject: Re: [HACKERS] Almost there on column aliases
In-Reply-To: <38AC45E1.3B79BF9E@alumni.caltech.edu> from Thomas Lockhart at
"Feb 17, 2000 07:02:57 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Thu, 17 Feb 2000 23:53:23 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>,
Postgres Hackers List <hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
cannot currently be transformed properly for rules given the info
available in the existing structures. This is true because there is no
equivalent query which allows you to specify anything like t1, ta, t2,
or tb in the target list, and there is no way currently to carry along
the "tj (n, m)" info.Comments on any or all?
It makes my head hurt. Is that a comment?
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 18 00:13:56 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA64963
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 00:13:03 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
QAA10585 for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 16:12:29 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0JkAQQ;
Fri Feb 18 16:12:10 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
QAA23210 for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 16:12:10 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0jl9bu; Fri Feb 18 16:11:09 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id QAA00505
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 16:11:08 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
QAA10409 for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 16:10:27 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38ACD409.47846DAA@nimrod.itg.telecom.com.au>
Date: Fri, 18 Feb 2000 16:09:29 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and Control-C
References: <Pine.LNX.4.21.0002180124290.3047-100000@localhost.localdomain>
<38AC9E77.19C28B36@nimrod.itg.telecom.com.au>
<20000217182128.H21720@fw.wintelcom.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Alfred Perlstein wrote:
Actually, FreeBSD(*) has 'libedit' which is pretty nice, it could
be made to work under other systems and has a nice unencumbered
license. :)
As an option - fine, but most things these days use readline, and
I would want my ~/.inputrc to work with all apps the same way.
From bouncefilter Fri Feb 18 00:13:54 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 AAA65172
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 00:13:53 -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 AAA27801;
Fri, 18 Feb 2000 00:12:43 -0500 (EST)
To: chris@bitmead.com
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and Control-C
In-reply-to: <38AC9F0D.4931DB92@nimrod.itg.telecom.com.au>
References: <Pine.LNX.4.21.0002171537260.3047-100000@localhost.localdomain>
<38AC8571.1306E0B8@nimrod.itg.telecom.com.au>
<20000217163325.A21720@fw.wintelcom.net>
<38AC9F0D.4931DB92@nimrod.itg.telecom.com.au>
Comments: In-reply-to Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
message dated "Fri, 18 Feb 2000 12:23:25 +1100"
Date: Fri, 18 Feb 2000 00:12:43 -0500
Message-ID: <27798.950850763@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
Alfred Perlstein wrote:
Whoa whoa... It's a bit more complicated than you think, there's a lot
of state that gets put into libpq,
I don't think this has anything to do with libpq. This has got to do
with psql's reading of commands _before_ they get shoved into
libpq. As such it shouldn't be that dangerous.
Chris is right that this is not a libpq issue. psql would be set up
so that the signal-catching routine either issues a cancel request
(if a query is in progress) or attempts a longjmp (if not). If
properly implemented, there is zero chance of screwing up libpq.
However, there is some chance of screwing up libreadline --- I don't
know enough about its innards to know if it can survive losing
control at a random point. If we can confine the region where longjmp
will be attempted to just the point where the program is blocked
waiting for user input, it'd probably be pretty safe.
Something I've noticed that might or might not be related to this
issue is that if psql exits due to backend crash, it fails to save the
last few lines of command history into the history file. Not closing
down libreadline, maybe?
regards, tom lane
From bouncefilter Fri Feb 18 00:06: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 AAA63557
for <hackers@postgresql.org>; Fri, 18 Feb 2000 00:06: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 FAA06716;
Fri, 18 Feb 2000 05:16:48 GMT
Sender: lockhart@hub.org
Message-ID: <38ACD5C0.A019294E@alumni.caltech.edu>
Date: Fri, 18 Feb 2000 05:16:48 +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>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] Almost there on column aliases
References: <200002180453.XAA04906@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
It makes my head hurt. Is that a comment?
:)
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Feb 18 01:00:55 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 BAA73412
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 01:00:52 -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 BAA29252;
Fri, 18 Feb 2000 01:00:50 -0500 (EST)
To: Marc Tardif <admin@wtbwts.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] queries on 2+ indices
In-reply-to: <Pine.BSF.4.10.10002172315000.16661-100000@server.b0x.com>
References: <Pine.BSF.4.10.10002172315000.16661-100000@server.b0x.com>
Comments: In-reply-to Marc Tardif <admin@wtbwts.com>
message dated "Thu, 17 Feb 2000 23:27:50 +0000"
Date: Fri, 18 Feb 2000 01:00:49 -0500
Message-ID: <29249.950853649@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Marc Tardif <admin@wtbwts.com> writes:
How does postgresql perform queries on one table using more than one
index?
It doesn't. Simple enough, eh?
For example, assuming the following:
create table t1 ( f1 int, f2 int);
create index t1_f1 on t1 (f1);
create index t1_f2 on t1 (f2);
select * from t1 where f1=123 and f2=456;
The optimizer will attempt to guess which index is more selective
(will return fewer tuples for its part of the WHERE clause). That
index would be used for the indexscan, and the rest of the WHERE
clause would be applied as a "qpqual", ie actually evaluated as
an expression against each tuple found by the index.
As you note, there's not any really efficient way to make use of
independent indexes to evaluate an AND condition like this one.
While Postgres' approach is pretty simplistic, I'm not sure that
a more-complicated approach would actually be any faster.
If you have a multi-column index, eg
create index t1_f1_f2 on t1 (f1, f2);
then the system can and will use both clauses of the WHERE with
that single index. But again, it's not entirely clear that that's
all that much faster than just using the more-selective clause
in a smaller index. Furthermore, a multi-column index is more
specialized than single-column indexes because it is useful for
only a narrower range of queries; so you have to consider the extra
work done at insert/update to manage the extra index, and decide
if it's really a win overall for your application.
how could I find answers to questions about query management by
postgresql?
Asking questions on the mailing lists isn't a bad way to start.
Seeing what EXPLAIN says about how queries will be executed is
another nice learning tool.
There is some high-level implementation info in the SGML documentation,
and more scattered in various README files, but you won't really
understand a lot until you start burrowing into the source code.
regards, tom lane
From bouncefilter Fri Feb 18 01:09:55 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id BAA75117
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 01:09:51 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
RAA25366 for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 17:09:17 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdOXstT_;
Fri Feb 18 17:08:44 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
RAA00852 for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 17:08:44 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdsbUwE_; Fri Feb 18 17:08:28 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id RAA16505
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 17:08:28 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
RAA11749 for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 17:07:47 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38ACE178.40AB502A@nimrod.itg.telecom.com.au>
Date: Fri, 18 Feb 2000 17:06:48 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and Control-C
References: <Pine.LNX.4.21.0002171537260.3047-100000@localhost.localdomain>
<38AC8571.1306E0B8@nimrod.itg.telecom.com.au>
<20000217163325.A21720@fw.wintelcom.net>
<38AC9F0D.4931DB92@nimrod.itg.telecom.com.au>
<27798.950850763@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Something I've noticed that might or might not be related to this
issue is that if psql exits due to backend crash, it fails to save the
last few lines of command history into the history file. Not closing
down libreadline, maybe?
This is actually the gnu history library. Currently psql issues a save
command when you exit or when you enter \s. I'm not sure why gnu
history appears to require you to write the whole history at once
rather than appending to a file but anyway...
A better way of doing it might be to have psql's finishInput() passed
to atexit(), just to make sure it's always called, and have
signal handlers in place for *every* signal whose handlers call exit(),
so finishing up is done neatly.
It might even be worthwhile to write the history after every command.
BTW, is it necessary to print "\q" when you hit ctrl-d ? Seems just a
little tacky to me.
From bouncefilter Fri Feb 18 03:21:58 2000
Received: from mtu.ru (ns.mtu.ru [195.34.32.10])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA02471
for <pgsql-hackers@postgresql.org>;
Fri, 18 Feb 2000 03:21:52 -0500 (EST)
(envelope-from victor_moroz@public.mtu.ru)
Received: from public.mtu.ru (ppp109-215.dialup.mtu-net.ru [212.188.109.215])
by mtu.ru (Postfix) with ESMTP id C2E8B78775
for <pgsql-hackers@postgresql.org>;
Fri, 18 Feb 2000 11:21:46 +0300 (MSK)
Sender: root@mtu.ru
Message-ID: <38AD00E0.910126CB@public.mtu.ru>
Date: Fri, 18 Feb 2000 11:20:48 +0300
From: root <victor_moroz@public.mtu.ru>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Large object problem in 6.5.2 & 3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Recipient: pgsql-hackers@postgresql.org
RedHat 6.1, Postgresql 6.5.2 (tried on 6.5.3 - same result).
------------------------------- Code:
#include <stdio.h>
#include <pgsql/libpq-fe.h>
#include <pgsql/libpq/libpq-fs.h>
int main() {
PGconn *conn;
PGresult *res;
conn = PQsetdb(NULL, NULL, NULL, NULL, "ctlg");
if(PQstatus(conn) == CONNECTION_BAD) {
printf("Cannot connect\n");
exit(1);
}
Oid LOid;
LOid = lo_creat(conn, INV_READ | INV_WRITE);
if(LOid == 0) {
printf("Cannot create\n");
exit(1);
}
printf("Created with Oid=%d\n", LOid);
int LOfd;
LOfd = lo_open(conn, LOid, INV_READ | INV_WRITE);
printf("Opened with LOfd = %d, %s\n", LOfd, PQerrorMessage(conn));
}
----------------------------------- Result:
Created with Oid=31169
Opened with LOfd = -1, ERROR: lo_lseek: invalid large obj descriptor
(0)
----------------------------------- Debug:
FindExec: found "/usr/bin/postgres" using argv[0]
/usr/bin/postmaster: BackendStartup: pid 1012 user root db ctlg socket 4
FindExec: found "/usr/bin/postgres" using argv[0]
started: host=localhost user=root database=ctlg
InitPostgres
StartTransactionCommand
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
CommitTransactionCommand
StartTransactionCommand
CommitTransactionCommand
StartTransactionCommand
ERROR: lo_lseek: invalid large obj descriptor (0)
AbortCurrentTransaction
pq_recvbuf: unexpected EOF on client connection
proc_exit(0) [#0]
shmem_exit(0) [#0]
exit(0)
/usr/bin/postmaster: reaping dead processes...
/usr/bin/postmaster: CleanupProc: pid 1012 exited with status 0
pmdie 2
proc_exit(0) [#0]
shmem_exit(0) [#0]
exit(0)
------------------------------------------
From bouncefilter Fri Feb 18 05:28:58 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 FAA27378
for <pgsql-hackers@postgresql.org>;
Fri, 18 Feb 2000 05:28:38 -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 LAA00801;
Fri, 18 Feb 2000 11:26:17 +0100
Date: Fri, 18 Feb 2000 11:26:16 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Chris <chris@bitmead.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] TODO: Cache most recent query plan
In-Reply-To: <2823.950714388@sss.pgh.pa.us>
Message-ID: <Pine.LNX.3.96.1000218103841.29793B-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 16 Feb 2000, Tom Lane wrote:
Chris <chris@bitmead.com> writes:
* Cache most recent query plan(s) [prepare]
I havn't been following what this is about, but
any implementation of caching query plans should
be careful about pg_class.relhasindex and
pg_class.relhassubclass, otherwise reuse of
query plans could give incorrect results, _maybe_,
depending on what you are planning here.
Now, I have implemented parser part for PREPARE:
"PREPARE queryname AS SELECT * FROM aaa WHERE b = $1 WITH TYPE int4"
this allow use $1..$n values and set types of these values. (Yes, I not
sure if all keywords are right, but change it is easy..)
The PREPARE is CMD_UTILITY and plan for prepared query is create in
command/prepare.c (it is easy and not needs changes in standard "the
path of query".
Hmm, how cache it, it is a good question. If I good understand Jan's TODO
item, we not have (for PREPARE) plan-cache as across transaction/start-stop
persisten plans (example cache it to any relation).
Well, of course the cached plan would only be good as long as you
weren't changing the database schema underneath it. I'm not sure
My idea (in current time) is write PREPARE as simple, no-longer-valid, *user
controllable* cache, user problem is if he changes his tables (?).
And about plan cache implementation; I want use hash table (hash_create ..etc)
system and as hash key use 'queryname'. I not sure how memory-context
use for this cache (or create new portal..?) I see Jan's FK implementation,
he uses SPI memory context - it not bad. Comments, ideas?
how far the system ought to go to prevent the user from continuing
to use a no-longer-valid plan ... exact detection of trouble seems
impractical, but I'm not thrilled with a "let the programmer beware"
approach either.
And what if user has PREPAREd any plans and he changes DB schema drop
all prepared plans. (You change DB schema..well, your caches with PREPAREd
plans go to .... /dev/null).
Or re-do the plan as you say.
Also, assuming that we do have some trouble detection mechanism, should
we reject subsequent attempts to use the cached plan, or automatically
re-do the plan on next use? If we kept around source or querytree form
of the original query, it ought to be possible to re-make the plan.
This would let us adopt a fairly simple trouble-detection mechanism that
would err in the direction of re-planning too much; say just replan on
any relcache flush for the relevant tables & indices. (If we're going
to raise an error, that test would be much too prone to raise errors
unnecessarily.)This seems closely related to Jan's TODO item about recompiling rules
when the DB schema changes, too.regards, tom lane
Karel
From bouncefilter Fri Feb 18 06:27:59 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 GAA50701
for <hackers@postgreSQL.org>; Fri, 18 Feb 2000 06:27: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 MAA03910;
Fri, 18 Feb 2000 12:27:04 +0100
Date: Fri, 18 Feb 2000 12:27:04 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Date/time types: big change
In-Reply-To: <38AAE143.82611E33@alumni.caltech.edu>
Message-ID: <Pine.LNX.3.96.1000218120108.29793C-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
-----------------------------------------------------------------------
On Wed, 16 Feb 2000, Thomas Lockhart wrote:
I've just committed changes to "reunify" the date/time types.
"timestamp" and "interval" are now the two primary date/time types for
users. Also, I've changed the default date style to "ISO" (not just in
time for Y2K, but we'll be ready for "Y3K").Also, I made some changes to have NUMERIC be a "known" type for
purposes of implicit type coersion, but have not tested to see if the
underlying conversion functions are available.initdb required (and enforced by a catalog version change).
Regression tests pass, except for the rules test due to ongoing rules
formatting work.
Great, you fix my formatting code for timestamp. Thanks Thomas!
But conversion timestam to 'tm' struct is not Y2038 ready
(POSIX 'tm' limitation?):
test=# select to_char('Fri Feb 18 11:57:47 2038 CET'::timestamp, 'HH:MI:SS YYYY');
to_char
---------------
10:57:47 2038
(1 row)
Or simple:
test=# select 'Fri Feb 18 11:57:47 2038 CET'::timestamp;
?column?
--------------------------
Thu Feb 18 10:57:47 2038
(1 row)
Or am I something leave out?
Karel
From bouncefilter Fri Feb 18 11:42:03 2000
Received: from Hydro.CAM.ORG (Hydro.CAM.ORG [198.168.100.7])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA17580
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 11:41:23 -0500 (EST)
(envelope-from admin@wtbwts.com)
Received: from www.pcr.ca (www.pcr.ca [207.139.158.13] (may be forged))
by Hydro.CAM.ORG (8.8.8/8.8.4) with ESMTP
id LAA25807; Fri, 18 Feb 2000 11:40:18 -0500 (EST)
Date: Fri, 18 Feb 2000 11:40:40 +0000 (GMT)
From: Marc Tardif <admin@wtbwts.com>
X-Sender: admin@server.b0x.com
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] queries on 2+ indices
In-Reply-To: <29249.950853649@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.10.10002181124360.17592-100000@server.b0x.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I'm not sure I understand what is "qpqual" in your explanation. Once the
first indexscan is performed, is a temporary table created (in-file or
in-memory) containing the relevant tuples? If not, how can the remaining
part of the WHERE clause be evaluated against the previously selected
tuples during the first indexscan? Or, is the remaining part of the WHERE
clause re-evaluated again and again for each of the found tuples in the
first indexscan?
On Fri, 18 Feb 2000, Tom Lane wrote:
Marc Tardif <admin@wtbwts.com> writes:
For example, assuming the following:
create table t1 ( f1 int, f2 int);
create index t1_f1 on t1 (f1);
create index t1_f2 on t1 (f2);
select * from t1 where f1=123 and f2=456;The optimizer will attempt to guess which index is more selective
(will return fewer tuples for its part of the WHERE clause). That
index would be used for the indexscan, and the rest of the WHERE
clause would be applied as a "qpqual", ie actually evaluated as
an expression against each tuple found by the index.As you note, there's not any really efficient way to make use of
independent indexes to evaluate an AND condition like this one.
While Postgres' approach is pretty simplistic, I'm not sure that
a more-complicated approach would actually be any faster.
From bouncefilter Fri Feb 18 07:26:00 2000
Received: from zipmx11.zipmail.com.br (zipmx11.zipmail.com.br
[200.211.190.111]) by hub.org (8.9.3/8.9.3) with ESMTP id HAA67933
for <pgsql-hackers@postgresql.org>;
Fri, 18 Feb 2000 07:25:12 -0500 (EST)
(envelope-from typedeath@zipmail.com.br)
Received: by zipmx11.zipmail.com.br (Postfix, from userid 0)
id 9D45E61FE; Fri, 18 Feb 2000 10:06:16 -0300 (EST)
X-Originating-IP: [200.248.83.247]
X-Mailer: ZipMail Mailer2.0 in HTTPServer www.zipmail.com.br
From: "Mauricio da Silva Barrios" <typedeath@zipmail.com.br>
Reply-To: typedeath@zipmail.com.br
To: <pgsql-hackers@postgresql.org>
Subject:
Content-type: text/plain;
charset="iso-8859-1"
MIME-Version: 1.0
Message-Id: <20000218130616.9D45E61FE@zipmx11.zipmail.com.br>
Date: Fri, 18 Feb 2000 10:06:16 -0300 (EST)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from Quoted-Printable to 8bit by hub.org id HAA68023
subscribe
_____________________________________________________________
GUNS N' ROSES.
Eles est���o de volta no novo CD Live Era 87-93. Fundamental para entender
a hist���ria do rock dos anos 90. Fundamental comprar logo. S��� R$ 20,90 no Submarino.
PROMO������O MOUSE VERMELHO
http://www.submarino.com.br/default.asp?franq=100037
_____________________________________________________________
From bouncefilter Fri Feb 18 08:52:02 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 IAA82491
for <pgsql-hackers@postgresql.org>;
Fri, 18 Feb 2000 08:51:28 -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 OAA10156;
Fri, 18 Feb 2000 14:51:16 +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 12Lois-0003ue-00; Fri, 18 Feb 2000 14:49:34 +0000
Message-ID: <38AD4D6E.A7EB4579@sferacarta.com>
Date: Fri, 18 Feb 2000 14:47:26 +0100
From: Jose Soares <jose@sferacarta.com>
Organization: Sfera Carta
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jan Wieck <wieck@debis.com>
CC: Jeff MacDonald <jeff@pgsql.com>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] PC Week PostgreSQL benchmark results posted online
(fwd)
References: <m12LZ7Z-0003kqC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Jan Wieck wrote:
Tim Dyck asked me to forward this on to the list.
*****************************
FYI, the story is available online at:
http://www.zdnet.com/pcweek/stories/news/0,4153,2436153,00.html
As I think I have mentioned, I would like to review PostgreSQL 7.0 when it
goes gold, so if someone could let me know when it is available, that
would be much appreciated.And that'll be an interesting one. Just looked into the MSSQL
7.0 docs today. They don't have referential actions! So
something like ON UPDATE CASCADE/... must be implemented the
hard way as triggers. Need to look it up once again tomorrow
to see if constraints can be deferred or not.On this detail, we already left at least one (and definitely
not the smallest) commercial database behind on the way to
SQL3.Can someone take a look at Interbase, Oracle and others about
it?Jan
--
Borland Interbase 4.0 syntax:
contraint_def:
{ PRIMARY KEY | UNIQUE (col [, col...] )
| FOREIGN KEY (col [, col...]) REFERENCES other_table
| CHECK (<search_condition>)
}
--
Jose' Soares
Bologna, Italy Jose@sferacarta.com
From bouncefilter Fri Feb 18 09:17:03 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA86895
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 09:16:19 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Krokodil.DoCS.UU.SE (e99re41@Krokodil.DoCS.UU.SE
[130.238.9.184])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id PAA16466;
Fri, 18 Feb 2000 15:16:11 +0100 (MET)
Received: from localhost (e99re41@localhost) by Krokodil.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id PAA04811;
Fri, 18 Feb 2000 15:16:09 +0100
X-Authentication-Warning: Krokodil.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Fri, 18 Feb 2000 15:16:08 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: chris@bitmead.com
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and Control-C
In-Reply-To: <38ACE178.40AB502A@nimrod.itg.telecom.com.au>
Message-ID: <Pine.GSO.4.02A.10002181514320.4777-100000@Krokodil.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 18 Feb 2000, Chris Bitmead wrote:
BTW, is it necessary to print "\q" when you hit ctrl-d ? Seems just a
little tacky to me.
That's similar to what bash and tcsh do. If you don't like it, I'm not
married to it.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Fri Feb 18 09:20:02 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA87358
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 09:19:14 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Krokodil.DoCS.UU.SE (e99re41@Krokodil.DoCS.UU.SE
[130.238.9.184])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id PAA16716;
Fri, 18 Feb 2000 15:19:08 +0100 (MET)
Received: from localhost (e99re41@localhost) by Krokodil.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id PAA04817;
Fri, 18 Feb 2000 15:19:07 +0100
X-Authentication-Warning: Krokodil.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Fri, 18 Feb 2000 15:19:07 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: chris@bitmead.com, PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and Control-C
In-Reply-To: <27798.950850763@sss.pgh.pa.us>
Message-ID: <Pine.GSO.4.02A.10002181516500.4777-100000@Krokodil.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 18 Feb 2000, Tom Lane wrote:
However, there is some chance of screwing up libreadline --- I don't
know enough about its innards to know if it can survive losing
control at a random point. If we can confine the region where longjmp
will be attempted to just the point where the program is blocked
waiting for user input, it'd probably be pretty safe.
Readline has an official way to preempt is, namely setting rl_done to
non-zero. I can take a look how it copes with a longjmp from a signal
handler, but I wouldn't set my hopes too high.
Something I've noticed that might or might not be related to this
issue is that if psql exits due to backend crash, it fails to save the
last few lines of command history into the history file. Not closing
down libreadline, maybe?
As someone else pointed out, I might as well move write_history() into an
atexit hook.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Fri Feb 18 09:21:01 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA87612
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 09:20:30 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Krokodil.DoCS.UU.SE (e99re41@Krokodil.DoCS.UU.SE
[130.238.9.184])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id PAA16811;
Fri, 18 Feb 2000 15:20:24 +0100 (MET)
Received: from localhost (e99re41@localhost) by Krokodil.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id PAA04827;
Fri, 18 Feb 2000 15:20:22 +0100
X-Authentication-Warning: Krokodil.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Fri, 18 Feb 2000 15:20:22 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Alfred Perlstein <bright@wintelcom.net>
cc: chris@bitmead.com, PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and Control-C
In-Reply-To: <20000217182128.H21720@fw.wintelcom.net>
Message-ID: <Pine.GSO.4.02A.10002181519150.4777-100000@Krokodil.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 17 Feb 2000, Alfred Perlstein wrote:
Actually, FreeBSD(*) has 'libedit' which is pretty nice, it could
be made to work under other systems and has a nice unencumbered
license. :)
Someone else mentioned this to me when I started on this. However, there's
not even a common version among the *BSD's, let alone ports to other
platforms, so I don't see this happening anytime soon.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Fri Feb 18 09:22:01 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA87936
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 09:21:59 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Krokodil.DoCS.UU.SE (e99re41@Krokodil.DoCS.UU.SE
[130.238.9.184])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id PAA16922;
Fri, 18 Feb 2000 15:21:54 +0100 (MET)
Received: from localhost (e99re41@localhost) by Krokodil.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id PAA04831;
Fri, 18 Feb 2000 15:21:52 +0100
X-Authentication-Warning: Krokodil.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Fri, 18 Feb 2000 15:21:52 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: chris@bitmead.com
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and Control-C
In-Reply-To: <38AC9E77.19C28B36@nimrod.itg.telecom.com.au>
Message-ID: <Pine.GSO.4.02A.10002181520320.4777-100000@Krokodil.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 18 Feb 2000, Chris Bitmead wrote:
If you don't know how to interact with readline, I think you're gonna
have to look at some GPL code ;)
There's a difference between copying ideas and code from bash's sig.c (not
good) and snooping around in code to see how to interface with it (why
not).
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Fri Feb 18 09:24:01 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA88223
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 09:23:13 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Krokodil.DoCS.UU.SE (e99re41@Krokodil.DoCS.UU.SE
[130.238.9.184])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id PAA17006;
Fri, 18 Feb 2000 15:23:08 +0100 (MET)
Received: from localhost (e99re41@localhost) by Krokodil.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id PAA04835;
Fri, 18 Feb 2000 15:23:06 +0100
X-Authentication-Warning: Krokodil.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Fri, 18 Feb 2000 15:23:05 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: chris@bitmead.com
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and Control-C
In-Reply-To: <38AC9E37.2D572FAD@nimrod.itg.telecom.com.au>
Message-ID: <Pine.GSO.4.02A.10002181522060.4777-100000@Krokodil.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 18 Feb 2000, Chris Bitmead wrote:
I mean escape from a half-typed in query, not escape from psql
altogether.
If you don't read the documentation before running a program, I can't help
you. Also, the welcome message points out both \? and \q.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Fri Feb 18 09:30:03 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA89660
for <hackers@postgreSQL.org>; Fri, 18 Feb 2000 09:29:42 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Krokodil.DoCS.UU.SE (e99re41@Krokodil.DoCS.UU.SE
[130.238.9.184])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id PAA17471;
Fri, 18 Feb 2000 15:29:37 +0100 (MET)
Received: from localhost (e99re41@localhost) by Krokodil.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id PAA04839;
Fri, 18 Feb 2000 15:29:35 +0100
X-Authentication-Warning: Krokodil.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Fri, 18 Feb 2000 15:29:34 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Tom Lane <tgl@sss.pgh.pa.us>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Date/time types: big changeu
In-Reply-To: <38AC426B.D335EF52@alumni.caltech.edu>
Message-ID: <Pine.GSO.4.02A.10002181524230.4777-100000@Krokodil.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 17 Feb 2000, Thomas Lockhart wrote:
However, istm that we could/should have more "default settings"
traveling in the pg_database table. We've got the encoding, which if
set for template1 will be set for every db. We've got the database
location, which can point to an alternate location.
I don't think this should be a per database setting. Why not use an
environment variable PGDATESTYLE for it. That's easy enough for now.
Before we throw all kinds of per database defaults around, I'd like to see
some sort of a concept where exactly a "database" stands versus "schema",
etc. What happens if one day queries across databases are allowed?
For v7.1, I'm hoping to work with Tatsuo and others to get closer to
the general character sets and collation sequences allowed by SQL92.
Excellent.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Fri Feb 18 09:48:09 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA93818
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 09:47:12 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Krokodil.DoCS.UU.SE (e99re41@Krokodil.DoCS.UU.SE
[130.238.9.184])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id PAA18598;
Fri, 18 Feb 2000 15:47:07 +0100 (MET)
Received: from localhost (e99re41@localhost) by Krokodil.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id PAA04883;
Fri, 18 Feb 2000 15:47:05 +0100
X-Authentication-Warning: Krokodil.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Fri, 18 Feb 2000 15:47:05 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>, Bruce Momjian <pgman@candle.pha.pa.us>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] create database doesn't work well in MULTIBYTE mode
In-Reply-To: <38ACCF59.875C0222@alumni.caltech.edu>
Message-ID: <Pine.GSO.4.02A.10002181535130.4777-100000@Krokodil.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 18 Feb 2000, Thomas Lockhart wrote:
...
#ifdef MULTIBYTE
n->encoding = $6;
#else
n->encoding = 0;
#endif
...where in fact if MULTIBYTE is not enabled and $6 is non-empty, the $6
production never returns!
It will if you write ENCODING = DEFAULT.
Also, the rule you're looking at also covers the case CREATE DATABASE WITH
LOCATION (no ENCODING clause given). In that case, with MULTIBYTE on, $6
will be set to GetTemplateEncoding() in the create_opt_encoding: /*EMPTY*/
rule. With MULTIBYTE off, you must set encoding to 0, because that's the
default SQL_ASCII encoding, and the createdb() function (where this all
ends up), does no further interpretation on the encoding at all. Either
way you read it, I still think the previous code is completely correct as
it stands.
So, why does the createdb_opt_encoding ($6 above) bother trying to
return "-1" when MULTIBYTE is disabled, when that -1 is ignored and
replaced with a zero anyway? Is it acceptable to return -1, as the $6
production does, or should it really be returning the zero which is
passed along??
Two reasons: First, it's better to have some rule than none at all, I
thunk. Second, if someone mucks with the code and somehow we have a -1
encoding the database, we know exactly what went wrong. If you feel so
inclined, you can change it to a zero, but after all the code works
perfectly.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Fri Feb 18 09:39:03 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 JAA91948
for <hackers@postgreSQL.org>; Fri, 18 Feb 2000 09:38: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 OAA07611;
Fri, 18 Feb 2000 14:48:46 GMT
Sender: lockhart@hub.org
Message-ID: <38AD5BCE.79FE9AF4@alumni.caltech.edu>
Date: Fri, 18 Feb 2000 14:48: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: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
CC: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Date/time types: big change
References: <Pine.LNX.3.96.1000218120108.29793C-100000@ara.zf.jcu.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
But conversion timestam to 'tm' struct is not Y2038 ready
(POSIX 'tm' limitation?):
to_char
---------------
10:57:47 2038
(1 row)
Or am I something leave out?
No, that is the expected behavior. In most of the world (certainly in
the US), time zones and daylight savings time were both very nebulous
things until around the turn of the century. I recall reading that in
the US building the continental railroads in the 1860's provoked
thinking about standardizing time zone.
There are also minor changes in time zone and DST behavior in recent
history; in the US we had a year or two in the 1970's which ran DST
year round due to the oil shortage.
So, since the actual time zone behavior for years past 2038 is
uncertain, and since the Unix time support routines don't support
anything past 2038 anyway, I omit time zone calculations after
2038-01-18 and before 1901-12-14. Everything is carried as equivalent
to GMT, but no time zone adjustment is carried out.
btw, there *may* be some edge effects which are, um, unexpected; e.g.
having a time zone adjustment as you enter a date w/o an explicit tz
into the database, to which the same adjustment is *not* applied as
the date is read back out. Feel free to test it out...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Feb 18 10:25:03 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 KAA02264
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 10:24:34 -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 KAA00290;
Fri, 18 Feb 2000 10:23:49 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: chris@bitmead.com, PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and Control-C
In-reply-to: <Pine.GSO.4.02A.10002181516500.4777-100000@Krokodil.DoCS.UU.SE>
References: <Pine.GSO.4.02A.10002181516500.4777-100000@Krokodil.DoCS.UU.SE>
Comments: In-reply-to Peter Eisentraut <e99re41@DoCS.UU.SE>
message dated "Fri, 18 Feb 2000 15:19:07 +0100"
Date: Fri, 18 Feb 2000 10:23:49 -0500
Message-ID: <287.950887429@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
On Fri, 18 Feb 2000, Tom Lane wrote:
However, there is some chance of screwing up libreadline --- I don't
know enough about its innards to know if it can survive losing
control at a random point. If we can confine the region where longjmp
will be attempted to just the point where the program is blocked
waiting for user input, it'd probably be pretty safe.
Readline has an official way to preempt is, namely setting rl_done to
non-zero. I can take a look how it copes with a longjmp from a signal
handler, but I wouldn't set my hopes too high.
Oh? Maybe we don't *need* a longjmp: maybe the signal handler just
needs to do either send-a-cancel or set-rl_done depending on the
current state of a flag that's set by the main line code.
regards, tom lane
From bouncefilter Fri Feb 18 10:36: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 KAA04489
for <hackers@postgreSQL.org>; Fri, 18 Feb 2000 10:35: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 KAA00406;
Fri, 18 Feb 2000 10:35:01 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Date/time types: big changeu
In-reply-to: <Pine.GSO.4.02A.10002181524230.4777-100000@Krokodil.DoCS.UU.SE>
References: <Pine.GSO.4.02A.10002181524230.4777-100000@Krokodil.DoCS.UU.SE>
Comments: In-reply-to Peter Eisentraut <e99re41@DoCS.UU.SE>
message dated "Fri, 18 Feb 2000 15:29:34 +0100"
Date: Fri, 18 Feb 2000 10:35:01 -0500
Message-ID: <403.950888101@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
I don't think this should be a per database setting. Why not use an
environment variable PGDATESTYLE for it.
We already have that, and I wouldn't have brought up the issue if I
thought it was sufficient. The case where you really want to be able
to set a default at the database or installation level is when you have
a ton of client apps running on a bunch of different machines, and you
can't or don't want to fix them all at once. A client-side fix doesn't
get the job done for a dbadmin faced with that kind of situation.
Or were you talking about a server-side env variable? That could work
I guess, but I thought you were intent on eliminating env-var
dependencies in initdb and postmaster startup ... for good reasons ...
Before we throw all kinds of per database defaults around, I'd like to see
some sort of a concept where exactly a "database" stands versus "schema",
etc. What happens if one day queries across databases are allowed?
Presumably a client doing that would make sure to request the same
datestyle (or whatever) from each database. You're right though
that we could use some global thinking about what parameters need
to be settable from where, and what their scopes need to be.
regards, tom lane
From bouncefilter Fri Feb 18 10:39:02 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 KAA05094
for <hackers@postgreSQL.org>; Fri, 18 Feb 2000 10:38:12 -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 PAA07767;
Fri, 18 Feb 2000 15:48:29 GMT
Sender: lockhart@hub.org
Message-ID: <38AD69CD.E4511B4F@alumni.caltech.edu>
Date: Fri, 18 Feb 2000 15:48: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: Tom Lane <tgl@sss.pgh.pa.us>
CC: Peter Eisentraut <peter_e@gmx.net>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Date/time types: big changeu
References: <Pine.GSO.4.02A.10002181524230.4777-100000@Krokodil.DoCS.UU.SE>
<403.950888101@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Or were you talking about a server-side env variable?
fwiw, we've already got that one...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Feb 18 10:53: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 KAA08589
for <hackers@postgreSQL.org>; Fri, 18 Feb 2000 10:52:57 -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 KAA00556;
Fri, 18 Feb 2000 10:52:48 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Peter Eisentraut <peter_e@gmx.net>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Date/time types: big changeu
In-reply-to: <38AD69CD.E4511B4F@alumni.caltech.edu>
References: <Pine.GSO.4.02A.10002181524230.4777-100000@Krokodil.DoCS.UU.SE>
<403.950888101@sss.pgh.pa.us>
<38AD69CD.E4511B4F@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Fri, 18 Feb 2000 15:48:29 +0000"
Date: Fri, 18 Feb 2000 10:52:48 -0500
Message-ID: <552.950889168@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
Or were you talking about a server-side env variable?
fwiw, we've already got that one...
We do? (... examines code ...) By golly, you're right.
OK, I agree with Peter: this is enough to save the day for a dbadmin
who really really doesn't want to switch to default ISO datestyle,
so I withdraw my complaint.
I do, however, suggest that the backend env var needs to be documented
more prominently than it is now. One might also ask why its set of
allowed values is inconsistent with the SET command's (probably
postgres.c ought to just call a routine in variable.c, rather than
having its own parsing code)?
regards, tom lane
From bouncefilter Fri Feb 18 11:19:02 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 LAA13241
for <hackers@postgreSQL.org>; Fri, 18 Feb 2000 11:18:13 -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 QAA08027;
Fri, 18 Feb 2000 16:28:37 GMT
Sender: lockhart@hub.org
Message-ID: <38AD7335.9D4C663F@alumni.caltech.edu>
Date: Fri, 18 Feb 2000 16:28: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: Tom Lane <tgl@sss.pgh.pa.us>
CC: Peter Eisentraut <peter_e@gmx.net>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Date/time types: big changeu
References: <Pine.GSO.4.02A.10002181524230.4777-100000@Krokodil.DoCS.UU.SE>
<403.950888101@sss.pgh.pa.us>
<38AD69CD.E4511B4F@alumni.caltech.edu>
<552.950889168@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I do, however, suggest that the backend env var needs to be documented
more prominently than it is now.
Hmm, I thought it was in the Admin Guide, but in fact it shows up only
in the Data Types chapter and in the release notes. Should be added to
runtime.sgml just before (?) "Starting postmaster".
One might also ask why its set of
allowed values is inconsistent with the SET command's (probably
postgres.c ought to just call a routine in variable.c, rather than
having its own parsing code)?
I'm vaguely recalling that there was a "chicken and egg" problem with
the backend firing up... Ah, in fact I think (still from my sometimes
faulty memory) that it had to do with whether the Postgres memory
management stuff (palloc et al) was available at the time postgres.c
needed to make the call.
Feel free to review it though and make sweeping or small changes.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Feb 18 11:08:02 2000
Received: from zipmx11.zipmail.com.br (zipmx11.zipmail.com.br
[200.211.190.111]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA11312
for <pgsql-hackers@postgresql.org>;
Fri, 18 Feb 2000 11:07:03 -0500 (EST)
(envelope-from typedeath@zipmail.com.br)
Received: by zipmx11.zipmail.com.br (Postfix, from userid 0)
id 346CF7222; Fri, 18 Feb 2000 13:33:23 -0300 (EST)
X-Originating-IP: [200.248.83.221]
X-Mailer: ZipMail Mailer2.0 in HTTPServer www.zipmail.com.br
From: "Mauricio da Silva Barrios" <typedeath@zipmail.com.br>
Reply-To: typedeath@zipmail.com.br
To: <pgsql-hackers@postgresql.org>
Cc: <tgl@sss.pgh.pa.us>
Cc: <vadim@krs.ru>
Subject: Is it a bug?
Content-type: text/plain;
charset="iso-8859-1"
MIME-Version: 1.0
Message-Id: <20000218163323.346CF7222@zipmx11.zipmail.com.br>
Date: Fri, 18 Feb 2000 13:33:23 -0300 (EST)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from Quoted-Printable to 8bit by hub.org id LAA11476
Hello, people!
I'm having a problem with postgres, and I wanna know if anyone out there
might give me some help...
My problem is this:
I have a table. When I run a select over it, the result comes OK. BUT,
if I create a view with the same select, when I run a select on the view,
if the table has any data my computer explodes on my face! I have made
other views, and they work fine, but they dont have subqueries with
reference to its parent query.
Have any of you ever faced this problem, or created a view like mine that
worked? how do I overcome my troubles??
Here follow my select, my table and all things I did (not much) to
generate the crash.
If you think you might help me and want more info about my system or
postgres, mail me.
-------------------------------------------------------------------------
-------
[user@server dir]$ psql mydb
Welcome to POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of PSTGRESQL
[PostgreSQL 6.5.3 on i686-pc-linux-gnu, compiled by gcc pgcc-2.91.66]
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: mydb
mydb=> CREATE TABLE connection (
connection_id INT4 primary key,
connection_owner INT4, -- Foreign Key for users table
connection_start TIMESTAMP,
connection_end RELTIME
);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index
'connection_pkey' for table 'connection'
CREATE
mydb=> CREATE VIEW connection_last AS
SELECT * FROM connection as con_out
WHERE connection_start IN ( SELECT max(connection_start) FROM
connection as con_in
WHERE con_in.connection_owner =
con_out.connection_owner
GROUP BY connection_owner);
CREATE
mydb=> SELECT * FROM connection_last;
connection_id|connection_owner|connection_start|connection_end
-------------+----------------+----------------+--------------
(0 rows)
mydb=> INSERT INTO connection VALUES (3,'2','22-01-01','122');
INSERT 172197 1
mydb=> select * from connection;
connection_id|connection_owner|connection_start |connection_end
-------------+----------------+----------------------+---------------
3| 2|2001-01-22 00:00:00-02|@ 2 mins 2 secs
(1 row)
mydb=> SELECT * FROM connection as con_out
WHERE connection_start IN ( SELECT max(connection_start) FROM
connection as con_in
WHERE con_in.connection_owner =
con_out.connection_owner
GROUP BY connection_owner);
connection_id|connection_owner|connection_start |connection_end
-------------+----------------+----------------------+---------------
3| 2|2001-01-22 00:00:00-02|@ 2 mins 2 secs
(1 row)
mydb=> select * from connection_last;
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
We have lost the connection to the backend, so further processing is
impossible.
Terminating.
[user@server dir]$
-------------------------------------------------------------------------
-----------
_____________________________________________________________
GUNS N' ROSES.
Eles est���o de volta no novo CD Live Era 87-93. Fundamental para entender
a hist���ria do rock dos anos 90. Fundamental comprar logo. S��� R$ 20,90 no Submarino.
PROMO������O MOUSE VERMELHO
http://www.submarino.com.br/default.asp?franq=100037
_____________________________________________________________
From bouncefilter Fri Feb 18 11:09:09 2000
Received: from zipmx11.zipmail.com.br (zipmx11.zipmail.com.br
[200.211.190.111]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA11531
for <pgsql-hackers@postgresql.org>;
Fri, 18 Feb 2000 11:08:35 -0500 (EST)
(envelope-from typedeath@zipmail.com.br)
Received: by zipmx11.zipmail.com.br (Postfix, from userid 0)
id 0B4D8727E; Fri, 18 Feb 2000 13:33:51 -0300 (EST)
X-Originating-IP: [200.248.83.221]
X-Mailer: ZipMail Mailer2.0 in HTTPServer www.zipmail.com.br
From: "Mauricio da Silva Barrios" <typedeath@zipmail.com.br>
Reply-To: typedeath@zipmail.com.br
To: <pgsql-hackers@postgresql.org>
Cc: <tgl@sss.pgh.pa.us>
Cc: <vadim@krs.ru>
Subject: Is it a bug?
Content-type: text/plain;
charset="iso-8859-1"
MIME-Version: 1.0
Message-Id: <20000218163351.0B4D8727E@zipmx11.zipmail.com.br>
Date: Fri, 18 Feb 2000 13:33:51 -0300 (EST)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from Quoted-Printable to 8bit by hub.org id LAB11587
Hello, people!
I'm having a problem with postgres, and I wanna know if anyone out there
might give me some help...
My problem is this:
I have a table. When I run a select over it, the result comes OK. BUT,
if I create a view with the same select, when I run a select on the view,
if the table has any data my computer explodes on my face! I have made
other views, and they work fine, but they dont have subqueries with
reference to its parent query.
Have any of you ever faced this problem, or created a view like mine that
worked? how do I overcome my troubles??
Here follow my select, my table and all things I did (not much) to
generate the crash.
If you think you might help me and want more info about my system or
postgres, mail me.
-------------------------------------------------------------------------
-------
[user@server dir]$ psql mydb
Welcome to POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of PSTGRESQL
[PostgreSQL 6.5.3 on i686-pc-linux-gnu, compiled by gcc pgcc-2.91.66]
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: mydb
mydb=> CREATE TABLE connection (
connection_id INT4 primary key,
connection_owner INT4, -- Foreign Key for users table
connection_start TIMESTAMP,
connection_end RELTIME
);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index
'connection_pkey' for table 'connection'
CREATE
mydb=> CREATE VIEW connection_last AS
SELECT * FROM connection as con_out
WHERE connection_start IN ( SELECT max(connection_start) FROM
connection as con_in
WHERE con_in.connection_owner =
con_out.connection_owner
GROUP BY connection_owner);
CREATE
mydb=> SELECT * FROM connection_last;
connection_id|connection_owner|connection_start|connection_end
-------------+----------------+----------------+--------------
(0 rows)
mydb=> INSERT INTO connection VALUES (3,'2','22-01-01','122');
INSERT 172197 1
mydb=> select * from connection;
connection_id|connection_owner|connection_start |connection_end
-------------+----------------+----------------------+---------------
3| 2|2001-01-22 00:00:00-02|@ 2 mins 2 secs
(1 row)
mydb=> SELECT * FROM connection as con_out
WHERE connection_start IN ( SELECT max(connection_start) FROM
connection as con_in
WHERE con_in.connection_owner =
con_out.connection_owner
GROUP BY connection_owner);
connection_id|connection_owner|connection_start |connection_end
-------------+----------------+----------------------+---------------
3| 2|2001-01-22 00:00:00-02|@ 2 mins 2 secs
(1 row)
mydb=> select * from connection_last;
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
We have lost the connection to the backend, so further processing is
impossible.
Terminating.
[user@server dir]$
-------------------------------------------------------------------------
-----------
_____________________________________________________________
GUNS N' ROSES.
Eles est���o de volta no novo CD Live Era 87-93. Fundamental para entender
a hist���ria do rock dos anos 90. Fundamental comprar logo. S��� R$ 20,90 no Submarino.
PROMO������O MOUSE VERMELHO
http://www.submarino.com.br/default.asp?franq=100037
_____________________________________________________________
From bouncefilter Fri Feb 18 11:10:05 2000
Received: from zipmx11.zipmail.com.br (zipmx11.zipmail.com.br
[200.211.190.111]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA11600
for <pgsql-hackers@postgresql.org>;
Fri, 18 Feb 2000 11:09:08 -0500 (EST)
(envelope-from typedeath@zipmail.com.br)
Received: by zipmx11.zipmail.com.br (Postfix, from userid 0)
id 1404B729C; Fri, 18 Feb 2000 13:33:57 -0300 (EST)
X-Originating-IP: [200.248.83.221]
X-Mailer: ZipMail Mailer2.0 in HTTPServer www.zipmail.com.br
From: "Mauricio da Silva Barrios" <typedeath@zipmail.com.br>
Reply-To: typedeath@zipmail.com.br
To: <pgsql-hackers@postgresql.org>
Cc: <tgl@sss.pgh.pa.us>
Cc: <vadim@krs.ru>
Subject: Is it a bug?
Content-type: text/plain;
charset="iso-8859-1"
MIME-Version: 1.0
Message-Id: <20000218163357.1404B729C@zipmx11.zipmail.com.br>
Date: Fri, 18 Feb 2000 13:33:57 -0300 (EST)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from Quoted-Printable to 8bit by hub.org id LAA11758
Hello, people!
I'm having a problem with postgres, and I wanna know if anyone out there
might give me some help...
My problem is this:
I have a table. When I run a select over it, the result comes OK. BUT,
if I create a view with the same select, when I run a select on the view,
if the table has any data my computer explodes on my face! I have made
other views, and they work fine, but they dont have subqueries with
reference to its parent query.
Have any of you ever faced this problem, or created a view like mine that
worked? how do I overcome my troubles??
Here follow my select, my table and all things I did (not much) to
generate the crash.
If you think you might help me and want more info about my system or
postgres, mail me.
-------------------------------------------------------------------------
-------
[user@server dir]$ psql mydb
Welcome to POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of PSTGRESQL
[PostgreSQL 6.5.3 on i686-pc-linux-gnu, compiled by gcc pgcc-2.91.66]
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: mydb
mydb=> CREATE TABLE connection (
connection_id INT4 primary key,
connection_owner INT4, -- Foreign Key for users table
connection_start TIMESTAMP,
connection_end RELTIME
);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index
'connection_pkey' for table 'connection'
CREATE
mydb=> CREATE VIEW connection_last AS
SELECT * FROM connection as con_out
WHERE connection_start IN ( SELECT max(connection_start) FROM
connection as con_in
WHERE con_in.connection_owner =
con_out.connection_owner
GROUP BY connection_owner);
CREATE
mydb=> SELECT * FROM connection_last;
connection_id|connection_owner|connection_start|connection_end
-------------+----------------+----------------+--------------
(0 rows)
mydb=> INSERT INTO connection VALUES (3,'2','22-01-01','122');
INSERT 172197 1
mydb=> select * from connection;
connection_id|connection_owner|connection_start |connection_end
-------------+----------------+----------------------+---------------
3| 2|2001-01-22 00:00:00-02|@ 2 mins 2 secs
(1 row)
mydb=> SELECT * FROM connection as con_out
WHERE connection_start IN ( SELECT max(connection_start) FROM
connection as con_in
WHERE con_in.connection_owner =
con_out.connection_owner
GROUP BY connection_owner);
connection_id|connection_owner|connection_start |connection_end
-------------+----------------+----------------------+---------------
3| 2|2001-01-22 00:00:00-02|@ 2 mins 2 secs
(1 row)
mydb=> select * from connection_last;
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
We have lost the connection to the backend, so further processing is
impossible.
Terminating.
[user@server dir]$
-------------------------------------------------------------------------
-----------
_____________________________________________________________
GUNS N' ROSES.
Eles est���o de volta no novo CD Live Era 87-93. Fundamental para entender
a hist���ria do rock dos anos 90. Fundamental comprar logo. S��� R$ 20,90 no Submarino.
PROMO������O MOUSE VERMELHO
http://www.submarino.com.br/default.asp?franq=100037
_____________________________________________________________
From bouncefilter Fri Feb 18 18:32:22 2000
Received: from hu.tm.ee (ppp908.tele2.ee [212.107.37.208])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA43906
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 18:31:49 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 221603BE9; Sat, 19 Feb 2000 01:36:39 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38ADD786.97A98EF4@tm.ee>
Date: Sat, 19 Feb 2000 01:36:38 +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: Thomas Lockhart <lockhart@alumni.caltech.edu>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: SQL compliance - why -- comments only at psql level ?
References: <85256887.006F108A.00@mailer.zd.com>
<38AB9610.C863108C@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas Lockhart wrote:
I've since seen the article in the latest issue of PCWeek. The article
was not at all clear on the *specific* features which would disqualify
Postgres from having SQL92 entry level compliance (for most commercial
RDBMSes this is the only level they attain), and I was amused to note
that although InterBase was lauded for SQL92 compliance, the author
did encourage them to consider supporting the SQL92 comment delimiter
("--") in their next release :))
Why does PostgreSQL _not_ support the -- comment delimiter ?
Is there something complicated to supporting it in parser ?
IMNSHO it would require only a few lines in gram.y
Does supporting user-defined operators interfere ?
I assume we could comfortably disallow -- as a possible operator (one
can't input it from interactive psql anyway)
--------------
Hannu
From bouncefilter Fri Feb 18 19:02: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 TAA50985
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 19:01: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 TAA04523;
Fri, 18 Feb 2000 19:00:18 -0500 (EST)
To: Marc Tardif <admin@wtbwts.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] queries on 2+ indices
In-reply-to: <Pine.BSF.4.10.10002181124360.17592-100000@server.b0x.com>
References: <Pine.BSF.4.10.10002181124360.17592-100000@server.b0x.com>
Comments: In-reply-to Marc Tardif <admin@wtbwts.com>
message dated "Fri, 18 Feb 2000 11:40:40 +0000"
Date: Fri, 18 Feb 2000 19:00:18 -0500
Message-ID: <4520.950918418@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Marc Tardif <admin@wtbwts.com> writes:
I'm not sure I understand what is "qpqual" in your explanation. Once the
first indexscan is performed, is a temporary table created (in-file or
in-memory) containing the relevant tuples?
No, it's all done on-the-fly as each tuple is scanned.
is the remaining part of the WHERE
clause re-evaluated again and again for each of the found tuples in the
first indexscan?
That's what I said.
regards, tom lane
From bouncefilter Fri Feb 18 19:16: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 TAA53245
for <pgsql-hackers@postgresql.org>;
Fri, 18 Feb 2000 19:15:21 -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 TAA04563;
Fri, 18 Feb 2000 19:14:52 -0500 (EST)
To: typedeath@zipmail.com.br
cc: pgsql-hackers@postgresql.org
Subject: Re: Is it a bug?
In-reply-to: <20000218163323.346CF7222@zipmx11.zipmail.com.br>
References: <20000218163323.346CF7222@zipmx11.zipmail.com.br>
Comments: In-reply-to "Mauricio da Silva Barrios" <typedeath@zipmail.com.br>
message dated "Fri, 18 Feb 2000 13:33:23 -0300"
Date: Fri, 18 Feb 2000 19:14:51 -0500
Message-ID: <4560.950919291@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Mauricio da Silva Barrios" <typedeath@zipmail.com.br> writes:
mydb=> CREATE VIEW connection_last AS
SELECT * FROM connection as con_out
WHERE connection_start IN ( SELECT max(connection_start) FROM
connection as con_in
WHERE con_in.connection_owner =
con_out.connection_owner
GROUP BY connection_owner);
mydb=> select * from connection_last;
pqReadData() -- backend closed the channel unexpectedly.
Hmm. Seems to work fine in current sources:
regression=# select * from connection_last;
connection_id | connection_owner | connection_start | connection_end
---------------+------------------+------------------------+----------------
3 | 2 | 2001-01-22 00:00:00-05 | 00:02:02
(1 row)
I seem to recall that the rule rewriter had some problems dealing with
aggregate functions inside sub-selects in 6.5.*, and that's probably
what's causing your problem.
7.0 is scheduled to go beta next week, so I'd suggest picking up
a beta copy ...
regards, tom lane
From bouncefilter Fri Feb 18 19:23: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 TAA54660
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 19:22:33 -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 TAA04618;
Fri, 18 Feb 2000 19:21:50 -0500 (EST)
To: Hannu Krosing <hannu@tm.ee>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: SQL compliance - why -- comments only at psql level
?
In-reply-to: <38ADD786.97A98EF4@tm.ee>
References: <85256887.006F108A.00@mailer.zd.com>
<38AB9610.C863108C@alumni.caltech.edu> <38ADD786.97A98EF4@tm.ee>
Comments: In-reply-to Hannu Krosing <hannu@tm.ee>
message dated "Sat, 19 Feb 2000 01:36:38 +0200"
Date: Fri, 18 Feb 2000 19:21:50 -0500
Message-ID: <4615.950919710@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Hannu Krosing <hannu@tm.ee> writes:
Thomas Lockhart wrote:
... although InterBase was lauded for SQL92 compliance, the author
did encourage them to consider supporting the SQL92 comment delimiter
("--") in their next release :))
Why does PostgreSQL _not_ support the -- comment delimiter ?
Better read it again, Hannu ... wasn't us that was being spoken of ...
regards, tom lane
From bouncefilter Fri Feb 18 19:45:08 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 TAA60684
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 19:44:43 -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
TAA20900;
Fri, 18 Feb 2000 19:38:35 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002190038.TAA20900@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: SQL compliance - why -- comments only at psql level
?
In-Reply-To: <38ADD786.97A98EF4@tm.ee> from Hannu Krosing at "Feb 19,
2000 01:36:38 am"
To: Hannu Krosing <hannu@tm.ee>
Date: Fri, 18 Feb 2000 19:38:35 -0500 (EST)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I believe it is Interbase that does not support the -- comment.
Thomas Lockhart wrote:
I've since seen the article in the latest issue of PCWeek. The article
was not at all clear on the *specific* features which would disqualify
Postgres from having SQL92 entry level compliance (for most commercial
RDBMSes this is the only level they attain), and I was amused to note
that although InterBase was lauded for SQL92 compliance, the author
did encourage them to consider supporting the SQL92 comment delimiter
("--") in their next release :))Why does PostgreSQL _not_ support the -- comment delimiter ?
Is there something complicated to supporting it in parser ?
IMNSHO it would require only a few lines in gram.y
Does supporting user-defined operators interfere ?
I assume we could comfortably disallow -- as a possible operator (one
can't input it from interactive psql anyway)--------------
Hannu************
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 18 20:25:11 2000
Received: from CS.UniBO.IT (leporello.cs.unibo.it [130.136.1.110])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA67247
for <pgsql-hackers@postgresql.org>;
Fri, 18 Feb 2000 20:24:22 -0500 (EST)
(envelope-from cornacch@CS.UniBO.IT)
Received: from adina.cs.unibo.it (cornacch@adina.cs.unibo.it [130.136.1.160])
by CS.UniBO.IT (8.9.3/8.9.3/Debian 8.9.3-6) with SMTP id CAA04502;
Sat, 19 Feb 2000 02:23:47 +0100
Date: Sat, 19 Feb 2000 02:23:38 +0100 (MET)
From: Roberto Cornacchia <cornacch@CS.UniBO.IT>
To: pgsql-hackers@postgresql.org
cc: Paolo Ciaccia <ciaccia@CS.UniBO.IT>, Andrea Ghidini <ghidini@CS.UniBO.IT>
Subject: Generalized Top Queries on PostgreSQL
Message-ID: <Pine.GSO.3.96.1000219022048.17025B-100000@adina.cs.unibo.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hello everyone,
Dr. P. Ciaccia, A. Ghidini and I (R. Cornacchia), have recently
developed, and implemented on PostgreSQL, a class of TOP Queries.
Here I would like to briefly present our main results.
The proposed sintax is the following:
SELECT
FROM
WHERE
STOP AFTER <N>
FOR EACH <stop-grouping attribute list>
RANK BY <ranking specification>
ORDER BY
where both FOR EACH and RANK BY (and STOP AFTER clause as a whole) are
optional.
Here is an example:
----
"Retrieve the 10 highest paid employees for each department.
Order the results first on department name and then on employee name"
SELECT Dept.name, Emp.name, Emp.salary
FROM Emp, Dept
WHERE Emp.dno = Dept.dno
STOP AFTER 10
FOR EACH Dept.dno
RANK BY Emp.salary DESC
ORDER BY Dept.name, Emp.name
----
We called such a query "Generalized Top Query".
The semantics introduced by the example is derived from the one
proposed by Carey and Kossmann ("On Saying 'Enougth Already' in
SQL", 1997). The main points of our extension are:
1) You can obtain the <N> Top rows as dictated by the RANK BY
specification and then produce the results according to the
ORDER BY specification. This means much more flexibility.
2) You can obtain the Top N rows for each of the "groups" which are
individuated by the FOR EACH specification
(from here "Generalized" top query).
Please consider that our semantics completely includes the current
LIMIT clause capabilities, offering at the same time some additional
ones.
For what concerns PostgreSQL, one of our first issues were to keep
basically unchanged
the current framework.
Here is a brief list of major changes we operated:
- We provided 2 new physical operators:
ScanStop: stops the stream to <N> rows
SortStop: performs an ad-hoc sort on the stream,
retaining only the <N> top rows.
- The optimizer can operate a push-down in the path-tree of
those two operators. It means we reduce the
stream cardinality as soon as possible, leading to a great
improvement on the performances of the subsequent operators.
- A larger number of optimizable operators force the optimizer to
generate more plans to handle,
so we extended the operators properties and the pruning rules.
- We extended the cost model as well, introducing estimates for the
cost of producing the FIRST N tuples.
- The rules involved in the Stop operators placement are mainly
based upon referential integrity constraints. In this way we
provided a *temporary* solution to this Postgres lack, storing
the informations on constraints in two new system catalogs.
- The FOR EACH generalization leads to natural generalization
of all the above concepts.
- The evaluation of GROUP BY clause can be performed before and after
the STOP AFTER, and both makes sense. In order to optimize the Stop
After operator, we choose to evaluate it before the group by
(and the order by).
* Let us summarize the current state of our work. *
- Our extension is highly optimized and can lead to performance
improvements of several orders of magnitude in comparison with the
current "LIMIT approach"
- It has a low impact on the original PostgreSQL code
- It does not affect the usual processing of classical queries
- It is soon expected to work with views.
- It works with subqueries
- It works with cursors
- It efficently makes use of indices
- It is updated to a 6.6 snapshot of November 1999 (we are waiting
for a more stable release)
--------------------------------------------------------------------
More details on this subject are going to be presented in a
forthcoming paper, available if interested.
We would be glad to receive your comments on this work.
Best regards,
R. Cornacchia (cornacch@cs.unibo.it) Computer Science, University of
Bologna
A. Ghidini (ghidini@cs.unibo.it) Computer Science, University of Bologna
Dr. Paolo Ciaccia (ciaccia@cs.unibo.it) DEIS CSITE-CNR, University of
Bologna
From bouncefilter Sat Feb 19 01:27:12 2000
Received: from Hydro.CAM.ORG (Hydro.CAM.ORG [198.168.100.7])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA27012
for <pgsql-hackers@postgresql.org>;
Sat, 19 Feb 2000 01:26:19 -0500 (EST)
(envelope-from admin@wtbwts.com)
Received: from www.pcr.ca (www.pcr.ca [207.139.158.13] (may be forged))
by Hydro.CAM.ORG (8.8.8/8.8.4) with ESMTP
id BAA01249 for <pgsql-hackers@postgresql.org>;
Sat, 19 Feb 2000 01:25:48 -0500 (EST)
Date: Sat, 19 Feb 2000 01:26:11 +0000 (GMT)
From: Marc Tardif <admin@wtbwts.com>
X-Sender: admin@server.b0x.com
To: pgsql-hackers@postgresql.org
Subject: handling multiple file descriptors
Message-ID: <Pine.BSF.4.10.10002190119010.18788-100000@server.b0x.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I've been trying to figure out how postgresql handles multiple open file
descriptors. First, I have managed to find out postgresql keeps a pool of
available descriptors for general processing tasks like sorting for
example. Second, I have tried to find what kind of data structure was used
for open descriptors to tables and indices, but couldn't find where. Could
someone please let me know what kind of data structure(s) is/are used for
open file descriptors and where this is located in the code?
The reason I'm so curious about such a specific part of the code is that
this problem has often occured in my own source code. In the past, I have
used a linked list and contemplated using a hash table to manage multiple
open file descriptors. I'm therefore interested to find out what real
production systems use for this kind of problem.
Regards,
Marc Tardif
From bouncefilter Fri Feb 18 20:29:13 2000
Received: from hu.tm.ee (ppp908.tele2.ee [212.107.37.208])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA68028
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 20:28:21 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id E290C3BE9; Sat, 19 Feb 2000 03:36:41 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38ADF3A9.B0F30A78@tm.ee>
Date: Sat, 19 Feb 2000 03:36:41 +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>,
pgsql-hackers@postgreSQL.org, Bruce Momjian <pgman@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: SQL compliance - why -- comments only at psql level
?
References: <85256887.006F108A.00@mailer.zd.com>
<38AB9610.C863108C@alumni.caltech.edu>
<38ADD786.97A98EF4@tm.ee> <4615.950919710@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Hannu Krosing <hannu@tm.ee> writes:
Thomas Lockhart wrote:
... although InterBase was lauded for SQL92 compliance, the author
did encourage them to consider supporting the SQL92 comment delimiter
("--") in their next release :))Why does PostgreSQL _not_ support the -- comment delimiter ?
Better read it again, Hannu ... wasn't us that was being spoken of ...
I got the impression from the paragraph that followed that we don't
and the first query I tried bounced from commandline
[hannu@hu hannu]$ psql -c "select count(*) from t1 -- what"
ERROR: parser: parse error at or near "-"
but worked interactively:
[hannu@hu TeleHansaPlus]$ psql
Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL
[PostgreSQL 6.5.2 on i586-pc-linux-gnu, compiled by gcc egcs-2.91.66]
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: hannu
hannu=> select count(*) from t1 -- what
hannu-> ;
count
-----
3
(1 row)
and failed also when used from python
[hannu@hu TeleHansaPlus]$ python
Python 1.5.2 (#1, Apr 18 1999, 16:03:16) [GCC pgcc-2.91.60 19981201
(egcs-1.1.1 on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
import pg
con=pg.connect('hannu')
con.query("select count(*) from t1 -- what")
Traceback (innermost last):
File "<stdin>", line 1, in ?
pg.error: ERROR: parser: parse error at or near "-"
So assumed it was handled in psql when in interactive mode.
------------
Hannu
From bouncefilter Fri Feb 18 20:40:09 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 UAA70676
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 20:39: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
UAA23190;
Fri, 18 Feb 2000 20:38:06 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002190138.UAA23190@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: SQL compliance - why -- comments only at psql level
?
In-Reply-To: <38ADF3A9.B0F30A78@tm.ee> from Hannu Krosing at "Feb 19,
2000 03:36:41 am"
To: Hannu Krosing <hannu@tm.ee>
Date: Fri, 18 Feb 2000 20:38:06 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>,
Thomas Lockhart <lockhart@alumni.caltech.edu>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Hannu Krosing <hannu@tm.ee> writes:
Thomas Lockhart wrote:
... although InterBase was lauded for SQL92 compliance, the author
did encourage them to consider supporting the SQL92 comment delimiter
("--") in their next release :))Why does PostgreSQL _not_ support the -- comment delimiter ?
Better read it again, Hannu ... wasn't us that was being spoken of ...
I got the impression from the paragraph that followed that we don't
and the first query I tried bounced from commandline
[hannu@hu hannu]$ psql -c "select count(*) from t1 -- what"
ERROR: parser: parse error at or near "-"
Worked here:
$ sql -c "select count(*) from t1 -- what" test
ERROR: Relation 't1' does not exist
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 18 21:07:15 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 VAA75971
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 21:06: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
VAA24822;
Fri, 18 Feb 2000 21:05:56 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002190205.VAA24822@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: SQL compliance - why -- comments only at psql level
?
In-Reply-To: <38ADFB2A.84FF7EA9@alumni.caltech.edu> from Thomas Lockhart at
"Feb 19, 2000 02:08:42 am"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Fri, 18 Feb 2000 21:05:56 -0500 (EST)
CC: Hannu Krosing <hannu@tm.ee>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I got the impression from the paragraph that followed that we don't
and the first query I tried bounced from commandline
So assumed it was handled in psql when in interactive mode.Yuck. They *were* talking about InterBase, but you're right!
Didn't realize that scan.l had lost (or never did have) the right
stuff. Will be fixed before we're out of beta...
Can you give me a failure condition for the TODO list? I can't see the
bug here.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 18 20:59:09 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 UAA74494
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 20:58:34 -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 CAA08657;
Sat, 19 Feb 2000 02:08:42 GMT
Sender: lockhart@hub.org
Message-ID: <38ADFB2A.84FF7EA9@alumni.caltech.edu>
Date: Sat, 19 Feb 2000 02:08:42 +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: Hannu Krosing <hannu@tm.ee>
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org,
Bruce Momjian <pgman@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: SQL compliance - why -- comments only at psql level
?
References: <85256887.006F108A.00@mailer.zd.com>
<38AB9610.C863108C@alumni.caltech.edu>
<38ADD786.97A98EF4@tm.ee> <4615.950919710@sss.pgh.pa.us>
<38ADF3A9.B0F30A78@tm.ee>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I got the impression from the paragraph that followed that we don't
and the first query I tried bounced from commandline
So assumed it was handled in psql when in interactive mode.
Yuck. They *were* talking about InterBase, but you're right!
Didn't realize that scan.l had lost (or never did have) the right
stuff. Will be fixed before we're out of beta...
- Tom
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Feb 18 21:18:13 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 VAA78103
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 21:17:28 -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 CAA08717;
Sat, 19 Feb 2000 02:24:38 GMT
Sender: lockhart@hub.org
Message-ID: <38ADFEE6.F7B96B0A@alumni.caltech.edu>
Date: Sat, 19 Feb 2000 02:24:38 +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>, Hannu Krosing <hannu@tm.ee>
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: SQL compliance - why -- comments only at psql
level?
References: <200002190205.VAA24822@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Can you give me a failure condition for the TODO list? I can't see the
bug here.
Well, now that I got off my duff and tried your little test with my
current sources, I get your result. Hannu??
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Feb 18 21:38:09 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 VAA81663
for <pgsql-hackers@postgreSQL.org>;
Fri, 18 Feb 2000 21:38: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 VAA11001;
Fri, 18 Feb 2000 21:37:40 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Hannu Krosing <hannu@tm.ee>, pgsql-hackers@postgreSQL.org,
Bruce Momjian <pgman@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: SQL compliance - why -- comments only at psql level
?
In-reply-to: <38ADFB2A.84FF7EA9@alumni.caltech.edu>
References: <85256887.006F108A.00@mailer.zd.com>
<38AB9610.C863108C@alumni.caltech.edu>
<38ADD786.97A98EF4@tm.ee> <4615.950919710@sss.pgh.pa.us>
<38ADF3A9.B0F30A78@tm.ee> <38ADFB2A.84FF7EA9@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Sat, 19 Feb 2000 02:08:42 +0000"
Date: Fri, 18 Feb 2000 21:37:40 -0500
Message-ID: <10998.950927860@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
Yuck. They *were* talking about InterBase, but you're right!
Didn't realize that scan.l had lost (or never did have) the right
stuff. Will be fixed before we're out of beta...
I've griped about these boundary conditions before, actually ---
although scan.l does the right thing most of the time with comments,
it has problems if a -- comment is terminated with \r instead of \n
(hence gripes from Windows users), and it also has problems if a --
comment is not terminated with \n before the end of the buffer.
There are some other cases where \r is not taken as equivalent
to \n, also.
Am testing a fix now.
regards, tom lane
From bouncefilter Sat Feb 19 00:09:11 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA13391
for <pgsql-hackers@postgresql.org>;
Sat, 19 Feb 2000 00:08:40 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id OAA15616
for <pgsql-hackers@postgresql.org>;
Sat, 19 Feb 2000 14:08:39 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-13 [133.137.84.13])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id OAA01543
for <pgsql-hackers@postgresql.org>; Sat, 19 Feb 2000 14:08:37 +0900
To: pgsql-hackers@postgresql.org
Subject: new backslah command of psql
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000219141402U.t-ishii@sra.co.jp>
Date: Sat, 19 Feb 2000 14:14:02 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 18
I have added new backslash command \eset and \eshow to psql.
(only enabled if --enable-multibyte specified)
Modified files are help.c and command.c.
-------------------------------------------------------------------
o \eset <encoding>
change the client encoding to <encoding>. This is actually
PQsetClientEncoding + pset.encoding (psql internal data) change. Now
user can change the client side encoding on the fly, that is not
possible before 7.0.
o \eshow
show the client encoding.
-------------------------------------------------------------------
--
Tatsuo Ishii
From bouncefilter Sat Feb 19 02:30:13 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 CAA37391
for <pgsql-hackers@postgreSQL.org>;
Sat, 19 Feb 2000 02:29:21 -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 CAA11899;
Sat, 19 Feb 2000 02:29:08 -0500 (EST)
To: Marc Tardif <admin@wtbwts.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] handling multiple file descriptors
In-reply-to: <Pine.BSF.4.10.10002190119010.18788-100000@server.b0x.com>
References: <Pine.BSF.4.10.10002190119010.18788-100000@server.b0x.com>
Comments: In-reply-to Marc Tardif <admin@wtbwts.com>
message dated "Sat, 19 Feb 2000 01:26:11 +0000"
Date: Sat, 19 Feb 2000 02:29:07 -0500
Message-ID: <11896.950945347@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Marc Tardif <admin@wtbwts.com> writes:
I've been trying to figure out how postgresql handles multiple open file
descriptors. First, I have managed to find out postgresql keeps a pool of
available descriptors for general processing tasks like sorting for
example. Second, I have tried to find what kind of data structure was used
for open descriptors to tables and indices, but couldn't find where. Could
someone please let me know what kind of data structure(s) is/are used for
open file descriptors and where this is located in the code?
See src/backend/storage/file/fd.c. You might also find buffile.c,
in the same directory, of interest.
These modules are not simply concerned with managing kernel FDs, but
also with releasing resources during transaction abort. Postgres'
model of error recovery is that elog(ERROR) longjmps back to the main
server loop, so routines that were aborted out of don't get to close
files, free memory, or otherwise release resources. fd.c is responsible
for cleaning up open FDs and temporary files after that happens.
regards, tom lane
From bouncefilter Sat Feb 19 03:24:13 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 DAA48927
for <hackers@postgresql.org>; Sat, 19 Feb 2000 03:23: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 IAA13809;
Sat, 19 Feb 2000 08:34:13 GMT
Sender: lockhart@hub.org
Message-ID: <38AE5583.37C39D3C@alumni.caltech.edu>
Date: Sat, 19 Feb 2000 08:34:11 +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>,
Jan Wieck <jwieck@debis.com>
Subject: gram.y foreign keys
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
OK, I've put in fixes to get Jan up and running on column foreign
keys. The current fix forces NOT NULL arguments to be near the
beginning of a column constraint list, and enforces the SQL92
requirement that the DEFAULT clause occur nearly first in a column
constraint.
As Jan probably already knows, the shift/reduce conflicts all happened
as a result of NOT NULL and NOT DEFERRABLE clauses; removing either
eliminated the conflicts.
I poked at it for *hours*, and have not yet stumbled on the correct
layout to give full flexibility while allowing the new constraint
attributes. Jan was thinking that he needed some token lookahead to do
this, but I'll be suprised if that is required to solve this for the
SQL92 case: it would be the first and only instance of syntax which
can not be solved by our yacc parser and istm that the spec would try
to stay away from that. The successful technique for fixing this will
likely involve unrolling more clauses to allow yacc to juggle more
clauses simultaneously before forcing a shift/reduce operation.
I'm leaving town through next weekend (back the 28th) and can pick
this up for more work then.
btw, regression tests pass except for the rules test with known
formatting differences.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Sat Feb 19 04:08:14 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 EAA57777
for <hackers@postgreSQL.org>; Sat, 19 Feb 2000 04:07:40 -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
EAA03479;
Sat, 19 Feb 2000 04:07:29 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002190907.EAA03479@candle.pha.pa.us>
Subject: Re: [HACKERS] gram.y foreign keys
In-Reply-To: <38AE5583.37C39D3C@alumni.caltech.edu> from Thomas Lockhart at
"Feb 19, 2000 08:34:11 am"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Sat, 19 Feb 2000 04:07:28 -0500 (EST)
CC: Postgres Hackers List <hackers@postgreSQL.org>,
Jan Wieck <jwieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Let me know if you want to discussed this over the phone for ideas.
OK, I've put in fixes to get Jan up and running on column foreign
keys. The current fix forces NOT NULL arguments to be near the
beginning of a column constraint list, and enforces the SQL92
requirement that the DEFAULT clause occur nearly first in a column
constraint.As Jan probably already knows, the shift/reduce conflicts all happened
as a result of NOT NULL and NOT DEFERRABLE clauses; removing either
eliminated the conflicts.I poked at it for *hours*, and have not yet stumbled on the correct
layout to give full flexibility while allowing the new constraint
attributes. Jan was thinking that he needed some token lookahead to do
this, but I'll be suprised if that is required to solve this for the
SQL92 case: it would be the first and only instance of syntax which
can not be solved by our yacc parser and istm that the spec would try
to stay away from that. The successful technique for fixing this will
likely involve unrolling more clauses to allow yacc to juggle more
clauses simultaneously before forcing a shift/reduce operation.I'm leaving town through next weekend (back the 28th) and can pick
this up for more work then.btw, regression tests pass except for the rules test with known
formatting differences.- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California************
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Sat Feb 19 07:02:19 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 HAA85023
for <pgsql-hackers@postgreSQL.org>;
Sat, 19 Feb 2000 07:02: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
HAA14966;
Sat, 19 Feb 2000 07:01:55 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002191201.HAA14966@candle.pha.pa.us>
Subject: Re: UESQLC
In-Reply-To: <00021912251300.00851@mastermind.home.ma.es> from Rafael Jesus
Alcantara Perez at "Feb 19, 2000 12:17:16 pm"
To: Rafael Jesus Alcantara Perez <rafa@dedalo-ing.com>
Date: Sat, 19 Feb 2000 07:01:55 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Looks nice. Should we put your code in contrib/ or put the URL on our
web site?
-----BEGIN PGP SIGNED MESSAGE-----
Hello Bruce:
I'm the main author of UESQLC, an embedded SQL compiler that, (now) can generate
code for ODBC, Oracle OCI and PostgreSQL LIBPQ interfaces. It parses SQL92, and
generates the code for the target selected (one of the three main targets
supported) using a SGML based target code description. I have attached an
example of C++ with embedded SQL (UESQL). It is under the GPL and this is the
URL:I hope that this program could help you.
Greets.
Rafa.
- --
+----------
| Rafael Jesus Alcantara Perez. P.O. Box 1199, 29080 Malaga, SPAIN.
| Email: mailto:rafa@dedalo-ing.com
| PGP public key: http://www.dedalo-ing.com/~rafa/public-key.asc
+---------------------
"For every complex problem there is a solution that is concise, clear, simple, and wrong."
(H. L. Mencken)-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconviQEVAwUBOK59o9qA/MQ7nrK9AQFlAAf8D1KP0xUOWV5uOOG671QBhJsyimO+mevC
Dw1m/7+EgfOnlgYtIKtB/AQIy1vayVFASnP9fD/udKTXYWWYXFaEGUScHwJpJZj0
2TgAZdhjGwaUPnjpizQM6By8bs0bI7s0ZgL8SQw38k0YOZPC+4xCg7UvQsDieR+5
5lDZgbgF4Mdls79R6bSBUHZp0lLZkdvsL5V8OsstFY4CI+BXyo1C1RtYpipN7w+N
dlLCblw7rGz6ohS7BtUU8GkJzGrznDaHz9dmm/7IVRwa8ovUnBVxlRlZCKY5SnGJ
6N7xj9HT1QiNsNqpzE8KZFDrUsI290K4Gc55GKhGg8VCes1Z+FIjBg==
=rDh5
-----END PGP SIGNATURE-----
Content-Description: UESQL in C++
[Attachment, skipping...]
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Sat Feb 19 09:11:32 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA02958
for <pgsql-hackers@postgresql.org>;
Sat, 19 Feb 2000 09:10:38 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61292 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S163842AbQBSOJq>;
Sat, 19 Feb 2000 15:09:46 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12MAcS-0000BM-00; Sat, 19 Feb 2000 15:12:24 +0100
Date: Sat, 19 Feb 2000 15:12:24 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: SQL compliance
In-Reply-To: <38AB9610.C863108C@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.21.0002191350430.474-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-02-17, Thomas Lockhart mentioned:
I've since seen the article in the latest issue of PCWeek. The article
was not at all clear on the *specific* features which would disqualify
Postgres from having SQL92 entry level compliance
I dug through the standard to come up with a list. I probably missed some
things, but they would be more of a lexical nature. I think I covered all
language constructs (which is what people look at anyway). Some of these
things I never used, so I merely tested them by looking at the current
documentation and/or entering a simple example query. Also, this list
doesn't care whether an implemented feature contains bugs that would
actually disqualify it from complete compliance.
* TIME and TIMESTAMP WITH TIMEZONE missing [6.1]
* Things such as SELECT MAX(ALL x) FROM y; don't work. [6.5]
{This seems to be an easy grammar fix.}
* LIKE with ESCAPE clause missing [8.5]
{Is on TODO.}
* SOME / ANY doesn't seem to exist [8.7]
* Grant privileges have several deficiencies [10.3, 11.36]
* Schemas [11.1, 11.2]
* CREATE VIEW name (x, y, z) doesn't work [11.19]
* There's a WITH CHECK OPTION clause for CREATE VIEW [11.19]
* no OPEN statement [13.2]
* FETCH syntax has a few issues [13.3]
* SELECT x INTO a, b, c table [13.5]
* DELETE WHERE CURRENT OF [13.6]
* INSERT INTO table DEFAULT VALUES [13.8]
{Looks like a grammar fix as well.}
* UPDATE WHERE CURRENT OF [13.9]
* no SQLSTATE, SQLCODE [22.1, 22.2]
{Not sure about that one, since the sections don't contain leveling
information.}
* default transaction isolation level is SERIALIZABLE
{Why isn't ours?}
* no autocommit in SQL
* modules? [12]
* Some type conversion problems. For example a DECIMAL field should not
dump out as NUMERIC, and a FLOAT(x) field should be stored as such.
[* Haven't looked at Embedded SQL.]
That's it. :)
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sat Feb 19 09:11:28 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA03002
for <pgsql-hackers@postgresql.org>;
Sat, 19 Feb 2000 09:10:54 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62024 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S165889AbQBSOKH>;
Sat, 19 Feb 2000 15:10:07 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12MAcf-0000C4-00; Sat, 19 Feb 2000 15:12:37 +0100
Date: Sat, 19 Feb 2000 15:12:36 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: chris@bitmead.com, PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] psql and Control-C
In-Reply-To: <287.950887429@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0002191424230.474-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-02-18, Tom Lane mentioned:
Readline has an official way to preempt is, namely setting rl_done to
non-zero. I can take a look how it copes with a longjmp from a signal
handler, but I wouldn't set my hopes too high.Oh? Maybe we don't *need* a longjmp: maybe the signal handler just
needs to do either send-a-cancel or set-rl_done depending on the
current state of a flag that's set by the main line code.
I tried that but it doesn't work. On further thought I believe that the
purpose of rl_done is for readline extensions, so that, for example, a
semicolon handler can scan the current line and then immediately return as
if you had pressed enter. When idle, readline hangs on read(), so setting
some variable isn't going to interrupt that.
The longjmp seems to work but I need to test it more. I'm concerned how it
will work across platforms, esp. Windows (being a POSIX thing). Should
there be a configure test or can I assume it on every non-WIN32 system?
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sat Feb 19 09:11:21 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA03003
for <hackers@postgresql.org>; Sat, 19 Feb 2000 09:10:55 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62040 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S161797AbQBSOKH>;
Sat, 19 Feb 2000 15:10:07 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12MAcm-0000CY-00; Sat, 19 Feb 2000 15:12:44 +0100
Date: Sat, 19 Feb 2000 15:12:44 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] Date/time types: big changeu
In-Reply-To: <403.950888101@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0002191440030.474-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-02-18, Tom Lane mentioned:
Or were you talking about a server-side env variable? That could work
I guess, but I thought you were intent on eliminating env-var
dependencies in initdb and postmaster startup ... for good reasons ...
Yes, as you noticed.
I don't mind postmaster startup environment variables that much. The ones
for initdb were much more evil. This really seems to be an item for the
Grand Unified Configuration File, but until that happens it's easier to
have a dozen of orthogonal environment variables than having to reorganize
this whole thing later on.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sat Feb 19 09:11:39 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA03013;
Sat, 19 Feb 2000 09:11:05 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62440 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S167941AbQBSOKV>;
Sat, 19 Feb 2000 15:10:21 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12MAcw-0000Ch-00; Sat, 19 Feb 2000 15:12:54 +0100
Date: Sat, 19 Feb 2000 15:12:54 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Jan Wieck <wieck@debis.com>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>, Tom Lane <tgl@sss.pgh.pa.us>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
Michael Meskes <meskes@postgresql.org>,
PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] ERROR: Unable to identify an operator '=' for types
'numeric' and 'float8'
In-Reply-To: <m12LHCo-0003kgC@orion.SAPserv.Hamburg.dsh.de>
Message-ID: <Pine.LNX.4.21.0002191455270.474-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-02-17, Jan Wieck mentioned:
IMHO a value floating around should be kept NUMERIC or in
it's string representation until it's finally clear where it
is dropped (int2/4/8, float4/8, numeric or return to client).
Actually, the hierarchy float8, float4, numeric, int8, int4, int2 might
just be right. The standard specifies that float<x> + numeric = float<y>
(where perhaps x == y, not sure). On the other hand, it is also quite
clear that a constant of the form 123.45 is a numeric literal.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sat Feb 19 11:53:19 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 LAA34062
for <hackers@postgreSQL.org>; Sat, 19 Feb 2000 11:53:03 -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 LAA12581;
Sat, 19 Feb 2000 11:52:48 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] gram.y foreign keys
In-reply-to: <38AE5583.37C39D3C@alumni.caltech.edu>
References: <38AE5583.37C39D3C@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Sat, 19 Feb 2000 08:34:11 +0000"
Date: Sat, 19 Feb 2000 11:52:48 -0500
Message-ID: <12578.950979168@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
I poked at it for *hours*, and have not yet stumbled on the correct
layout to give full flexibility while allowing the new constraint
attributes. Jan was thinking that he needed some token lookahead to do
this, but I'll be suprised if that is required to solve this for the
SQL92 case: it would be the first and only instance of syntax which
can not be solved by our yacc parser and istm that the spec would try
to stay away from that. The successful technique for fixing this will
likely involve unrolling more clauses to allow yacc to juggle more
clauses simultaneously before forcing a shift/reduce operation.
The argument for adding a token lookahead wasn't that it is impossible
to do it at the grammar level; it was that it looked a lot simpler,
more understandable, and more robust/maintainable to do it as a token
filter than by grammar-unrolling.
If you've spent hours on it and can't find any better solution than
restricting the order of column constraint clauses, I'd say that kind
of proves the point, no?
The other way we had discussed of attacking it was to postpone some
processing to analyze.c (see thread around 10-Dec).
Anyway, IMNSHO we can't release with an artificial restriction on
column constraint clause order; it's way too likely to break existing
code, even if it is within the letter of the SQL spec. This'll do for
beta testing but we need something better before 7.0 release.
regards, tom lane
From bouncefilter Sat Feb 19 11:56:19 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 LAA34453
for <pgsql-hackers@postgreSQL.org>;
Sat, 19 Feb 2000 11:55: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 LAA12608;
Sat, 19 Feb 2000 11:55:22 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Rafael Jesus Alcantara Perez <rafa@dedalo-ing.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: UESQLC
In-reply-to: <200002191201.HAA14966@candle.pha.pa.us>
References: <200002191201.HAA14966@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Sat, 19 Feb 2000 07:01:55 -0500"
Date: Sat, 19 Feb 2000 11:55:22 -0500
Message-ID: <12605.950979322@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Looks nice. Should we put your code in contrib/ or put the URL on our
web site?
The GPL license would pose a problem for including it in our
distribution, I think (GPL vs BSD and all that) --- but no reason
not to link to it from our web pages...
regards, tom lane
From bouncefilter Sat Feb 19 12:02:19 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 MAA35886
for <pgsql-hackers@postgreSQL.org>;
Sat, 19 Feb 2000 12:01:31 -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 MAA12655;
Sat, 19 Feb 2000 12:01:27 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and Control-C
In-reply-to: <Pine.LNX.4.21.0002191424230.474-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0002191424230.474-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Sat, 19 Feb 2000 15:12:36 +0100"
Date: Sat, 19 Feb 2000 12:01:27 -0500
Message-ID: <12652.950979687@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
The longjmp seems to work but I need to test it more. I'm concerned how it
will work across platforms, esp. Windows (being a POSIX thing). Should
there be a configure test or can I assume it on every non-WIN32 system?
longjmp predates POSIX by an eon or two. I doubt you need to worry about
it on Unix platforms. (Since we utterly rely on it in the backend,
Postgres wouldn't ever work on a platform without it anyway.)
Less sure about the situation on Windows or Mac, but configure isn't
going to help for those anyway.
regards, tom lane
From bouncefilter Sat Feb 19 12:16:25 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 MAA38760
for <pgsql-hackers@postgreSQL.org>;
Sat, 19 Feb 2000 12:16: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 MAA12735;
Sat, 19 Feb 2000 12:16:10 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: SQL compliance
In-reply-to: <Pine.LNX.4.21.0002191350430.474-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0002191350430.474-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Sat, 19 Feb 2000 15:12:24 +0100"
Date: Sat, 19 Feb 2000 12:16:10 -0500
Message-ID: <12732.950980570@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
* Things such as SELECT MAX(ALL x) FROM y; don't work. [6.5]
{This seems to be an easy grammar fix.}
Yes, and since ALL is already a reserved word, it wouldn't break
anything to accept it. I'll try to take care of that today.
None of the other stuff is quite as easy to fix :-(
* INSERT INTO table DEFAULT VALUES [13.8]
{Looks like a grammar fix as well.}
Huh? We do have DEFAULT VALUES --- what is wrong exactly?
What we don't seem to have is full <table value constructor> per 7.2;
we only allow VALUES ... in INSERT, whereas SQL allows it in other
constructs where a sub-SELECT would be legal, and we don't accept
multiple rows in VALUES. For example, you should be able to write
INSERT INTO t VALUES (1,2,3), (4,5,6), (7,8,9), ...
but we don't accept that now. The spec also shows several examples like
CONSTRAINT DOMAIN_CONSTRAINTS_CHECK_DEFERRABLE
CHECK ( ( IS_DEFERRABLE, INITIALLY_DEFERRED ) IN
( VALUES ( 'NO', 'NO' ),
( 'YES', 'NO' ),
( 'YES', 'YES' ) ) )
Thanks for digging through the spec ... I bet that was tedious ...
regards, tom lane
From bouncefilter Sat Feb 19 14:22:21 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 OAA59887
for <pgsql-hackers@postgreSQL.org>;
Sat, 19 Feb 2000 14:21: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 OAA17954;
Sat, 19 Feb 2000 14:21:18 -0500 (EST)
To: Mark Hollomon <mhh@mindspring.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Nasty portability glitch in plperl
Date: Sat, 19 Feb 2000 14:21:18 -0500
Message-ID: <17951.950988078@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
I tried today for the first time to compile plperl, and didn't have
much success. After fixing a couple of simple problems, I was left
with
cc -c -D_HPUX_SOURCE -Aa -I/usr/local/include -I/opt/perl5/lib/5.00503/PA-RISC2.0/CORE +z -I../../../src/interfaces/libpq -I../../../src/include -I../../../src/backend plperl.c
cpp: "perl.h", line 136: warning 2001: Redefinition of macro VOIDUSED.
cpp: "perl.h", line 1474: warning 2001: Redefinition of macro DEBUG.
cc: "../../../src/include/utils/int8.h", line 34: error 1681: Must use +e or -Ae for long long in ANSI mode.
make: *** [plperl.o] Error 1
This is with a plain-vanilla installation of perl 5.005_03 on HPUX 10.20.
Perl's configure script chooses HP's cc in strict-ANSI (-Aa) mode,
and I let it have its head on the issue. I could work around it by
reinstalling Perl using gcc and/or forcing -Ae (not-so-strict ANSI mode)
in Perl's installation CFLAGS, but if I'm running into this problem with
the standard setup then so will a lot of other people on HPUX. I don't
think we can say "you have to have a nonstandard Perl installation to
use this".
But short of that I don't see a clean answer. We select -Ae in the
hpux_cc template, but I usually don't use the hpux_cc template ---
I prefer hpux_gcc for development. (In fact, the first problem I had to
fix was that plperl's makefile tried to use CFLAGS taken from postgres's
configuration with CC taken from perl's. HP's cc does not like gcc-
specific compiler switches, nor vice versa.) So there's noplace for
plperl to cleanly pull -Ae from.
The only thing I can think of at the moment is to do something like
if (platform-is-HPUX-and-CC-is-cc)
CFLAGS+= -Ae
endif
in plperl's Makefile.PL, but that sure strikes me as awfully ugly.
Anyone have a better answer?
regards, tom lane
From bouncefilter Sat Feb 19 17:26:24 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 RAA95437
for <hackers@postgreSQL.org>; Sat, 19 Feb 2000 17:25: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 RAA26177;
Sat, 19 Feb 2000 17:25:36 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Date/time types: big change
In-reply-to: <38AD7335.9D4C663F@alumni.caltech.edu>
References: <Pine.GSO.4.02A.10002181524230.4777-100000@Krokodil.DoCS.UU.SE>
<403.950888101@sss.pgh.pa.us>
<38AD69CD.E4511B4F@alumni.caltech.edu>
<552.950889168@sss.pgh.pa.us>
<38AD7335.9D4C663F@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Fri, 18 Feb 2000 16:28:37 +0000"
Date: Sat, 19 Feb 2000 17:25:35 -0500
Message-ID: <26174.950999135@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
One might also ask why its set of
allowed values is inconsistent with the SET command's (probably
postgres.c ought to just call a routine in variable.c, rather than
having its own parsing code)?
I'm vaguely recalling that there was a "chicken and egg" problem with
the backend firing up... Ah, in fact I think (still from my sometimes
faulty memory) that it had to do with whether the Postgres memory
management stuff (palloc et al) was available at the time postgres.c
needed to make the call.
Yup, your memory is still working...
Feel free to review it though and make sweeping or small changes.
OK, I tweaked the code in variable.c to not depend on palloc(), and
made the change. In the course of doing so, I noticed what I assume
is a bug: RESET DateStyle and SET DateStyle = 'DEFAULT' were still
setting to Postgres style. Presumably they should reset to ISO style
in the brave new world, no?
What I actually did was to make them reset to whatever the backend's
startup setting is. Thus, if a postmaster PGDATESTYLE environment
variable exists, it will determine the result of RESET DateStyle as
well as the state of a new backend. (A client-side PGDATESTYLE setting
cannot affect RESET, of course, since it just causes a SET command to
be issued.) I think this is appropriate behavior, but it might be open
to debate.
BTW, here is an interesting corner case for you: what happens when
the postmaster is started with PGDATESTYLE="DEFAULT"? You get ISO
now, but I almost committed code that would have gone into infinite
recursion...
regards, tom lane
From bouncefilter Sat Feb 19 21:33:26 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA42804
for <pgsql-hackers@postgresql.org>;
Sat, 19 Feb 2000 21:32:51 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62522 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S202757AbQBTCb7>;
Sun, 20 Feb 2000 03:31:59 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12MMCl-0001uX-00; Sun, 20 Feb 2000 03:34:39 +0100
Date: Sun, 20 Feb 2000 03:34:38 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] new backslah command of psql
In-Reply-To: <20000219141402U.t-ishii@sra.co.jp>
Message-ID: <Pine.LNX.4.21.0002191617440.474-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-02-19, Tatsuo Ishii mentioned:
I have added new backslash command \eset and \eshow to psql.
(only enabled if --enable-multibyte specified)
Modified files are help.c and command.c.
Next time, make sure to update the documentation as well.
o \eset <encoding>
change the client encoding to <encoding>.
o \eshow
show the client encoding.
I took the liberty to change that to \encoding <x> sets the encoding and
\encoding without arguments shows it. Also you can do \echo :ENCODING.
That fits in better with the rest.
I have a question for you, though. Right now, when I have a non-multibyte
backend and a multibyte psql I get this when I start up psql:
psql: ERROR: MultiByte support must be enabled to use this function
That means I can't use psql on non-multibyte servers in that case.
(Probably true for other libpq applications, too.) I don't think that's
acceptable. Is there anything you can do there, such as the backend
ignoring whatever function is being called?
I believe you are going a little too far with ifdef'ing out MULTIBYTE. For
instance, it should be perfectly fine to call pg_char_to_encoding, even if
there's no possibility of using the encoding. Even when I don't configure
for multibyte support I should be able to use all (or at least most) of
the functions and get SQL_ASCII or 0 or some such back.
I will be interested to work with you and Thomas (and who knows else) on
the national character and related issues for the next release. Some of
this stuff needs a serious look.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sat Feb 19 21:36:26 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA43407
for <pgsql-hackers@postgresql.org>;
Sat, 19 Feb 2000 21:35:43 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63288 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S202758AbQBTCew>;
Sun, 20 Feb 2000 03:34:52 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12MMFZ-0001xz-00; Sun, 20 Feb 2000 03:37:33 +0100
Date: Sun, 20 Feb 2000 03:37:33 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: SQL compliance
In-Reply-To: <12732.950980570@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0002200336560.474-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-02-19, Tom Lane mentioned:
* INSERT INTO table DEFAULT VALUES [13.8]
{Looks like a grammar fix as well.}Huh? We do have DEFAULT VALUES --- what is wrong exactly?
Not documented. ;)
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sat Feb 19 23:11:28 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA59609
for <pgsql-hackers@postgreSQL.org>;
Sat, 19 Feb 2000 23:10:33 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id NAA14996;
Sun, 20 Feb 2000 13:10:30 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-12 [133.137.84.12])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id NAA07056;
Sun, 20 Feb 2000 13:10:27 +0900
To: peter_e@gmx.net
Cc: t-ishii@sra.co.jp, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] new backslah command of psql
In-Reply-To: <Pine.LNX.4.21.0002191617440.474-100000@localhost.localdomain>
References: <20000219141402U.t-ishii@sra.co.jp>
<Pine.LNX.4.21.0002191617440.474-100000@localhost.localdomain>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000220131554B.t-ishii@sra.co.jp>
Date: Sun, 20 Feb 2000 13:15:54 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 67
On 2000-02-19, Tatsuo Ishii mentioned:
I have added new backslash command \eset and \eshow to psql.
(only enabled if --enable-multibyte specified)
Modified files are help.c and command.c.Next time, make sure to update the documentation as well.
Ok.
o \eset <encoding>
change the client encoding to <encoding>.
o \eshow
show the client encoding.
I took the liberty to change that to \encoding <x> sets the encoding and
\encoding without arguments shows it.
Ok.
Also you can do \echo :ENCODING.
That fits in better with the rest.
Oh, I didn't know that.
I have a question for you, though. Right now, when I have a non-multibyte
backend and a multibyte psql I get this when I start up psql:psql: ERROR: MultiByte support must be enabled to use this function
That means I can't use psql on non-multibyte servers in that case.
(Probably true for other libpq applications, too.) I don't think that's
acceptable. Is there anything you can do there, such as the backend
ignoring whatever function is being called?I believe you are going a little too far with ifdef'ing out MULTIBYTE. For
instance, it should be perfectly fine to call pg_char_to_encoding, even if
there's no possibility of using the encoding. Even when I don't configure
for multibyte support I should be able to use all (or at least most) of
the functions and get SQL_ASCII or 0 or some such back.
I can hardly imagine the case where multibyte-enabled/non-multibyte
installations are mixed together. Anyway, we could enable part of
multibyte functions even if it not configured. But is it worth to do
that?
I personally think that MULTIBYTE should always be enabled since it is
"upper compatible" to non-MB installations and no significant
performance penalty is observed (I am not sure about what other core
developers are thinking, though).
Moreover, we are going to implement the national character etc. in the
near future and the current multibyte implementations will be
deprecated soon.
I will be interested to work with you and Thomas (and who knows else) on
the national character and related issues for the next release. Some of
this stuff needs a serious look.
Yes, especially to introduce CREATE CHARACTER SET, current MB stuffs
must be completely rewritten.
--
Tatsuo Ishii
From bouncefilter Sun Feb 20 00:01: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 AAA70329
for <pgsql-hackers@postgreSQL.org>;
Sun, 20 Feb 2000 00:01: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
XAA01125;
Sat, 19 Feb 2000 23:58:36 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002200458.XAA01125@candle.pha.pa.us>
Subject: Re: [HACKERS] new backslah command of psql
In-Reply-To: <Pine.LNX.4.21.0002191617440.474-100000@localhost.localdomain>
from Peter Eisentraut at "Feb 20, 2000 03:34:38 am"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Sat, 19 Feb 2000 23:58:36 -0500 (EST)
CC: Tatsuo Ishii <t-ishii@sra.co.jp>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
On 2000-02-19, Tatsuo Ishii mentioned:
I have added new backslash command \eset and \eshow to psql.
(only enabled if --enable-multibyte specified)
Modified files are help.c and command.c.
Do we have to have a \eset command? Can't we just use \set that we
already have?
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Sun Feb 20 03:25:30 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA06466
for <pgsql-hackers@postgreSQL.org>;
Sun, 20 Feb 2000 03:25:13 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id RAA19840;
Sun, 20 Feb 2000 17:25:11 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id RAA07988;
Sun, 20 Feb 2000 17:25:11 +0900
To: pgman@candle.pha.pa.us
Cc: peter_e@gmx.net, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] new backslash command of psql
In-Reply-To: Your message of "Sat, 19 Feb 2000 23:58:36 -0500 (EST)"
<200002200458.XAA01125@candle.pha.pa.us>
References: <200002200458.XAA01125@candle.pha.pa.us>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000220172510B.t-ishii@sra.co.jp>
Date: Sun, 20 Feb 2000 17:25:10 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 9
[spelling mistake in Subject corrected]
Do we have to have a \eset command? Can't we just use \set that we
already have?
Not sure. Seems \set is for just setting a variable. To change the
client encoding, we need to do more.
--
Tatsuo Ishii
From bouncefilter Sun Feb 20 05:03:31 2000
Received: from feivel.fam-meskes.de (h-62.96.159.43.host.de.colt.net
[62.96.159.43]) by hub.org (8.9.3/8.9.3) with ESMTP id FAA20272
for <pgsql-hackers@postgresql.org>;
Sun, 20 Feb 2000 05:02:57 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 87DEF2BD57; Sun, 20 Feb 2000 11:03:53 +0100 (CET)
Date: Sun, 20 Feb 2000 11:03:52 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: UESQLC
Message-ID: <20000220110352.A1170@fam-meskes.de>
Mail-Followup-To: PostgreSQL-development <pgsql-hackers@postgresql.org>
References: <200002191201.HAA14966@candle.pha.pa.us>
<12605.950979322@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <12605.950979322@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Sat, Feb 19, 2000 at 11:55:22AM -0500
Sender: michael@fam-meskes.de
On Sat, Feb 19, 2000 at 11:55:22AM -0500, Tom Lane wrote:
The GPL license would pose a problem for including it in our
distribution, I think (GPL vs BSD and all that) --- but no reason
not to link to it from our web pages...
I accidently deleted the original mail before reading it. Could someone
please give me the link. What exactly is UESQLC?
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 Sun Feb 20 09:20:36 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA51887
for <pgsql-hackers@postgresql.org>;
Sun, 20 Feb 2000 09:20:32 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62988 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S5768AbQBTOTm>;
Sun, 20 Feb 2000 15:19:42 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12MXFW-0004V1-00; Sun, 20 Feb 2000 15:22:14 +0100
Date: Sun, 20 Feb 2000 15:22:14 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: SQL compliance
In-Reply-To: <12732.950980570@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0002201439580.3142-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-02-19, Tom Lane mentioned:
What we don't seem to have is full <table value constructor> per 7.2;
we only allow VALUES ... in INSERT, whereas SQL allows it in other
constructs where a sub-SELECT would be legal,
Not required by Intermediate Level.
and we don't accept
multiple rows in VALUES. For example, you should be able to writeINSERT INTO t VALUES (1,2,3), (4,5,6), (7,8,9), ...
but we don't accept that now.
Not required either.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sun Feb 20 10:42:35 2000
Received: from hu.tm.ee (ppp766.tele2.ee [212.107.37.66])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA63402
for <pgsql-hackers@postgreSQL.org>;
Sun, 20 Feb 2000 10:41:47 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 14CFF3BE5; Sun, 20 Feb 2000 17:49:57 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38B00D24.AB13D9A9@tm.ee>
Date: Sun, 20 Feb 2000 17:49:56 +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: Thomas Lockhart <lockhart@alumni.caltech.edu>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: SQL compliance - why -- comments only at psql
level?
References: <200002190205.VAA24822@candle.pha.pa.us>
<38ADFEE6.F7B96B0A@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas Lockhart wrote:
Can you give me a failure condition for the TODO list? I can't see the
bug here.Well, now that I got off my duff and tried your little test with my
current sources, I get your result. Hannu??
My tests were with 6.5.3 which has even more yuckies in it :
[hannu@hu hannu]$ psql -c "select -- what ?
count(*) from t1;"
ERROR: attribute 'what' not found
[hannu@hu hannu]$ psql -c "select -- what
count(*) from t1;"
ERROR: parser: parse error at or near "count"
[hannu@hu hannu]$ psql -c "select count(*) -- what
from t1;"
count
-----
3
(1 row)
But they all work from psql
hannu=> select -- what ?
hannu-> count(*) from t1;
count
-----
3
(1 row)
hannu=> select count(*) -- what ?
hannu-> from t1;
count
-----
3
(1 row)
Could you try them on current.
-------------
Hannu
From bouncefilter Sun Feb 20 10:44:36 2000
Received: from hu.tm.ee (ppp766.tele2.ee [212.107.37.66])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA63770
for <pgsql-hackers@postgreSQL.org>;
Sun, 20 Feb 2000 10:44:14 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 7DF563BEF; Sun, 20 Feb 2000 17:52:43 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38B00DCB.2F2B15AC@tm.ee>
Date: Sun, 20 Feb 2000 17:52:43 +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: Thomas Lockhart <lockhart@alumni.caltech.edu>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: SQL compliance - why -- comments only at psql
level?
References: <200002190205.VAA24822@candle.pha.pa.us>
<38ADFEE6.F7B96B0A@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas Lockhart wrote:
Can you give me a failure condition for the TODO list? I can't see the
bug here.Well, now that I got off my duff and tried your little test with my
current sources, I get your result. Hannu??
Btw, how did you try them ?
Could it be that psql is now stripping comments even in non-interactive
mode (when using -c or redirected stdin)?
Could you test with some other frontend (python, perl, tcl, C) ?
------------
Hannu
From bouncefilter Sun Feb 20 11:35: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 LAA71351
for <pgsql-hackers@postgreSQL.org>;
Sun, 20 Feb 2000 11:34: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 LAA04654;
Sun, 20 Feb 2000 11:34:38 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: SQL compliance
In-reply-to: <Pine.LNX.4.21.0002201439580.3142-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0002201439580.3142-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Sun, 20 Feb 2000 15:22:14 +0100"
Date: Sun, 20 Feb 2000 11:34:38 -0500
Message-ID: <4651.951064478@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
On 2000-02-19, Tom Lane mentioned:
What we don't seem to have is full <table value constructor> per 7.2;
we only allow VALUES ... in INSERT, whereas SQL allows it in other
constructs where a sub-SELECT would be legal,
Not required by Intermediate Level.
No, but it's useful enough that we should have it...
regards, tom lane
From bouncefilter Sun Feb 20 12:42:39 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 MAA81105
for <pgsql-hackers@postgreSQL.org>;
Sun, 20 Feb 2000 12:42:25 -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 MAA05351;
Sun, 20 Feb 2000 12:41:44 -0500 (EST)
To: Hannu Krosing <hannu@tm.ee>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: SQL compliance - why -- comments only at psql
level?
In-reply-to: <38B00DCB.2F2B15AC@tm.ee>
References: <200002190205.VAA24822@candle.pha.pa.us>
<38ADFEE6.F7B96B0A@alumni.caltech.edu> <38B00DCB.2F2B15AC@tm.ee>
Comments: In-reply-to Hannu Krosing <hannu@tm.ee>
message dated "Sun, 20 Feb 2000 17:52:43 +0200"
Date: Sun, 20 Feb 2000 12:41:44 -0500
Message-ID: <5348.951068504@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Hannu Krosing <hannu@tm.ee> writes:
Could you test with some other frontend (python, perl, tcl, C) ?
Yup, psql is untrustworthy as a means of testing the backend's comment
handling ;-).
I committed lexer changes on Friday evening that I believe fix all of
the backend's problems with \r versus \n. The issue with unterminated
-- comments, which was Hannu's original complaint, was fixed awhile ago;
but we still had problems with comments terminated with \r instead of
\n, as well as some non-SQL-compliant behavior for -- comments between
the segments of a multiline literal, etc etc.
While fixing this I realized that there are some fundamental
discrepancies between the way the backend recognizes comments and the
way that psql does. These arise from the fact that the comment
introducer sequences /* and -- are also legal as parts of operator
names, and since the backend is based on lex which uses greedy longest-
available-match rules, you get things like this:
select *-- 123
ERROR: Can't find left op '*--' for type 23
(Parsing '*--' as an operator name wins over parsing just '*' as an
operator name, so that '--' would be recognized on the next call.)
More subtly,
select /**/- 22
ERROR: parser: parse error at or near ""
which is the backend's rather lame excuse for an "unterminated comment"
error. What happens here is that the sequence /**/- is bit off as a
single lexer token, then tested in this order to see if it is
(a) a complete "/* ... */" comment (nope),
(b) the start of a comment, "/* anything" (yup), or
(c) an operator (which would succeed if it got the chance).
There does not seem to be any way to persuade lex to stop at the "*/"
if it has a chance to recognize a longer token by applying the operator
rule.
Both of these problems are easily avoided by inserting some whitespace,
but I wonder whether we ought to try to fix them for real. One way
that this could be done would be to alter the lexer rules so that
operators are lexed a single character at a time, which'd eliminate
lex's tendency to recognize a long operator name in place of a comment.
Then we'd need a post-pass to recombine adjacent operator characters into
a single token. (This would forever prevent anyone from using operator
names that include '--' or '/*', but I'm not sure that's a bad thing.)
The post-pass would also be a mighty convenient place to fix the NOT NULL
problem that's giving us trouble in another thread: the post-pass would
need one-token lookahead anyway, so it could very easily convert NOT
followed by NULL into a single special token.
Meanwhile, psql is using some ad-hoc code to recognize comments,
rather than a lexer, and it thinks both of these sequences are indeed
comments. I also find that it strips out the -- flavor of comment,
but sends the /* */ flavor on through, which is just plain inconsistent.
I suggest we change psql to not strip -- comments either. The only
reason for psql to be in the comment-recognition business at all is
so that it can determine whether a semicolon is end-of-query or just
a character in a comment.
Another thing I'd like to fix here is to get the backend to produce
a more useful error message than 'parse error at or near ""' when it's
presented with an unterminated comment or unterminated literal.
The flex manual recommends coding like
<quote><<EOF>> {
error( "unterminated quote" );
yyterminate();
}
but <<EOF>> is a flex-ism not supported by regular lex. We already
tell people they have to use flex (though I'm not sure that's *really*
necessary at present); do we want to set that requirement in stone?
Or does anyone know another way to get this effect?
regards, tom lane
From bouncefilter Mon Feb 21 11:22:56 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 LAA09753
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 11:21:58 -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 LAA08868
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 11:21:38 -0500 (EST)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
QAA19651;
Sun, 20 Feb 2000 16:50:51 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002202150.QAA19651@candle.pha.pa.us>
Subject: Re: [HACKERS] new backslash command of psql
In-Reply-To: <20000220172510B.t-ishii@sra.co.jp> from Tatsuo Ishii at "Feb 20,
2000 05:25:10 pm"
To: Tatsuo Ishii <t-ishii@sra.co.jp>
Date: Sun, 20 Feb 2000 16:50:51 -0500 (EST)
CC: peter_e@gmx.net, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[spelling mistake in Subject corrected]
Do we have to have a \eset command? Can't we just use \set that we
already have?Not sure. Seems \set is for just setting a variable. To change the
client encoding, we need to do more.
We already have some special variable meanings like \set PROMPT1 which
controls the psql prompt. Seems an encoding variable can be made too.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Sun Feb 20 18:14:48 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA40099
for <pgsql-hackers@postgreSQL.org>;
Sun, 20 Feb 2000 18:14:14 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA09119 for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 10:13:30 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdbZ7CQ_;
Mon Feb 21 10:12:58 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA15751 for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 10:12:57 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0eskds; Mon Feb 21 10:11:52 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA07129
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 10:11:51 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
KAA09185 for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 10:11:08 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38B07450.2B25309D@nimrod.itg.telecom.com.au>
Date: Mon, 21 Feb 2000 10:10:08 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] psql and Control-C
References: <Pine.GSO.4.02A.10002181522060.4777-100000@Krokodil.DoCS.UU.SE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Peter Eisentraut wrote:
On Fri, 18 Feb 2000, Chris Bitmead wrote:
I mean escape from a half-typed in query, not escape from psql
altogether.If you don't read the documentation before running a program, I can't help
you. Also, the welcome message points out both \? and \q.
I think it takes quite a while to realise that you can intersperse a
backslash command anywhere. like..
select * from
\q
which is a bit different to shell where
while :
exit
will not have the desired effect.
From bouncefilter Sun Feb 20 20:04:44 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 UAA75829;
Sun, 20 Feb 2000 20:03:45 -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 UAA16592;
Sun, 20 Feb 2000 20:03:40 -0500 (EST)
To: Jeroen van Vianen <jeroen@design.nl>
cc: pgsql-patches@postgreSQL.org, pgsql-hackers@postgreSQL.org
Subject: Re: [PATCHES] Patch for more readable parse error messages
In-reply-to: <4.2.0.58.20000220193250.00969f00@mail.design.nl>
References: <4.2.0.58.20000220151757.00956ba0@mail.design.nl>
<4.2.0.58.20000220151757.00956ba0@mail.design.nl>
<4.2.0.58.20000220193250.00969f00@mail.design.nl>
Comments: In-reply-to Jeroen van Vianen <jeroen@design.nl>
message dated "Sun, 20 Feb 2000 19:43:06 +0100"
Date: Sun, 20 Feb 2000 20:03:40 -0500
Message-ID: <16589.951095020@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Jeroen van Vianen <jeroen@design.nl> writes:
Does this work with a non-bison parser? It looks mighty
bison-dependent to me...
I'm not sure, but it probably is flex dependent (but Postgres always needed
flex anyway). I'm not aware of any yacc / byacc / bison dependencies. Don't
know if anybody has been successful building Postgres with another parser
generator.
Um, you're right of course --- those are lexer not parser datastructures
you're poking into. Sorry for my confusion.
We do in fact work with non-bison parser generators, or did last time
I tried it (around 6.5 release). I would not like us to stop working
with non-bison yaccs, since bison's output depends on alloca() which
is not available everywhere.
I'm not sure about the situation with lexers. We have been saying for
a long time that flex was required, but since we got rid of the
scanner's use of trailing context ('/' rules) I think there is a better
chance that it would work with vanilla lex. Anyone want to try that
with current sources?
BTW, as we ship flex's output lex.yy.c (as scan.c) and bison's output
(gram.c) in the distribution, any user would be able to compile the
sources, but if they want to start hacking the .l or .y files, they'll
need appropriate tools.
Right. I am not aware of any portability problems with flex's output
as there are with bison's, so it may be that the concern is moot.
We may just be able to say "use the prebuilt scan.c or get flex; we
don't care about supporting vendor lexes anymore".
I do see a potential problem with this patch that's not related to
portability questions; it is that you're assuming that the lexer's
furthest penetration into the source text is a good place to point
at for parser errors. That may not be true always. In particular,
I've been advocating solving some other problems by inserting a
one-token lookahead buffer between the parser and the lexer. If that
happens then you'd be off by (at least) one token in some cases.
I think the way that this sort of thing is customarily handled in
"real" compilers is that each token carries along an indication of
just where it was found in the source, and then error messages can
finger the right place without making assumptions about synchronization
between different phases of the scanning/parsing process. That might
be more work than we can justify for SQL queries; not sure.
BTW, I think that the immediate problem of generating a good error
message for unterminated comments and literals could be solved in other
ways. This patch or something like it might be cool anyway, but you
should bear in mind that printing out a query and then a marker that's
supposed to line up with something in the query doesn't always work
all that well. Consider a query that's several dozen lines long,
such as a large table definition. If we had more control over the
user interface and could highlight the offending token directly,
I'd be more excited about doing something like this. (Actually, you
could partially address that problem by only printing one line's worth
of query text leading up to the error marker point. It would still be
tricky to get it right in the presence of newlines, tabs, etc.)
regards, tom lane
From bouncefilter Sun Feb 20 22:44:45 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id WAA25018;
Sun, 20 Feb 2000 22:44:34 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
OAA13961; Mon, 21 Feb 2000 14:43:54 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0QfaTn;
Mon Feb 21 14:43:39 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
OAA27096; Mon, 21 Feb 2000 14:43:38 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0VJgSV; Mon Feb 21 14:42:42 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA26965;
Mon, 21 Feb 2000 14:42:36 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
OAA15616; Mon, 21 Feb 2000 14:41:54 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38B0B3C6.BC4EE7C5@nimrod.itg.telecom.com.au>
Date: Mon, 21 Feb 2000 14:40:54 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-patches@postgreSQL.org, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error
messages
References: <4.2.0.58.20000220151757.00956ba0@mail.design.nl>
<4.2.0.58.20000220151757.00956ba0@mail.design.nl>
<4.2.0.58.20000220193250.00969f00@mail.design.nl>
<16589.951095020@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
We do in fact work with non-bison parser generators, or did last time
I tried it (around 6.5 release). I would not like us to stop working
with non-bison yaccs, since bison's output depends on alloca() which
is not available everywhere.
I think GNU alloca should work on any platform because it's written in a
portable way.
From bouncefilter Mon Feb 21 02:00:48 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 CAA94341
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 02:00:16 -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 PAA04345 for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 15:59:55 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: Numeric with '-'
Date: Mon, 21 Feb 2000 16:06:07 +0900
Message-ID: <000401bf7c3a$1fec7200$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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Hi,
The following phenomenon was reported to pgsql-jp(ML in Japan).
rest=# select -1234567890.1234567;
ERROR: Unable to convert left operator '-' from type 'unknown'
-1234567890.1234567 is treated as - '1234567890.1234567'
as the following comment in scan.l says.
/* we no longer allow unary minus in numbers.
* instead we pass it separately to parser. there it gets
* coerced via doNegate() -- Leon aug 20 1999
*/
However doNegate() does nothing for SCONST('1234567890.1234567').
I don't understand where or how to combine '-' and numeric SCONST.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Mon Feb 21 02:55:48 2000
Received: from loopy.berkhirt.com (loopy.berkhirt.com [209.220.85.54])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA04001
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 02:55:15 -0500 (EST)
(envelope-from bhirt@loopy.berkhirt.com)
Received: (from bhirt@localhost)
by loopy.berkhirt.com (8.9.3/8.9.3) id BAA27982;
Mon, 21 Feb 2000 01:54:37 -0600
Date: Mon, 21 Feb 2000 01:54:37 -0600
From: Brian Hirt <bhirt@mobygames.com>
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Numeric with '-'
Message-ID: <20000221015437.A356@loopy.berkhirt.com>
Reply-To: bhirt@mobygames.com
References: <000401bf7c3a$1fec7200$2801007e@tpf.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1us
In-Reply-To: <000401bf7c3a$1fec7200$2801007e@tpf.co.jp>;
from Inoue@tpf.co.jp on Mon, Feb 21, 2000 at 04:06:07PM +0900
X-PC-Gaming: http://www.mobygames.com/
A strange thing I noticed with this is that
"select -234567890.1234567;" works and
"select -1234567890.123456;" also works while
"select -1234567890.1234567;" does not. That
extra character just seems to push things over
the edge.
It almost seems like there is some sort of length
restriction somewhere in the parser.
On Mon, Feb 21, 2000 at 04:06:07PM +0900, Hiroshi Inoue wrote:
Hi,
The following phenomenon was reported to pgsql-jp(ML in Japan).
rest=# select -1234567890.1234567;
ERROR: Unable to convert left operator '-' from type 'unknown'-1234567890.1234567 is treated as - '1234567890.1234567'
as the following comment in scan.l says./* we no longer allow unary minus in numbers.
* instead we pass it separately to parser. there it gets
* coerced via doNegate() -- Leon aug 20 1999
*/However doNegate() does nothing for SCONST('1234567890.1234567').
I don't understand where or how to combine '-' and numeric SCONST.Regards.
Hiroshi Inoue
Inoue@tpf.co.jp************
--
The world's most ambitious and comprehensive PC game database project.
From bouncefilter Mon Feb 21 03:47:49 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 DAA17332
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 03:47:14 -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 RAA04409; Mon, 21 Feb 2000 17:47:07 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: <bhirt@mobygames.com>
Cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Numeric with '-'
Date: Mon, 21 Feb 2000 17:53:20 +0900
Message-ID: <000601bf7c49$1a6bea40$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: <20000221015437.A356@loopy.berkhirt.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
-----Original Message-----
From: Brian Hirt [mailto:bhirt@mobygames.com]A strange thing I noticed with this is that
"select -234567890.1234567;" works and
"select -1234567890.123456;" also works while
"select -1234567890.1234567;" does not. That
extra character just seems to push things over
the edge.It almost seems like there is some sort of length
restriction somewhere in the parser.
Currently numeric constants are FLOAT8 constants if the
the precision <= 17 otherwise string constants.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Mon Feb 21 04:01:49 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 EAA20230
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 04:01:28 -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 EAA02019;
Mon, 21 Feb 2000 04:00:52 -0500 (EST)
To: bhirt@mobygames.com
cc: Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Numeric with '-'
In-reply-to: <20000221015437.A356@loopy.berkhirt.com>
References: <000401bf7c3a$1fec7200$2801007e@tpf.co.jp>
<20000221015437.A356@loopy.berkhirt.com>
Comments: In-reply-to Brian Hirt <bhirt@mobygames.com>
message dated "Mon, 21 Feb 2000 01:54:37 -0600"
Date: Mon, 21 Feb 2000 04:00:51 -0500
Message-ID: <2016.951123651@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Brian Hirt <bhirt@mobygames.com> writes:
"select -1234567890.123456;" also works while
"select -1234567890.1234567;" does not. That
extra character just seems to push things over
the edge.
It almost seems like there is some sort of length
restriction somewhere in the parser.
Indeed there is, and you'll find it at src/backend/parser/scan.l
line 355 (in current sources). The lexer backs off from "float
constant" to "unspecified string constant" in order to avoid losing
precision from conversion to float. Which is fine, except that
without any cue that the constant is numeric, the parser is unable
to figure out what to do with the '-' operator.
I've been ranting about this in a recent pghackers thread ;-).
The lexer shouldn't have to commit to a conversion to float8
in order to report that a token looks like a numeric literal.
The resulting error message
ERROR: Unable to convert left operator '-' from type 'unknown'
isn't exactly up to a high standard of clarity either; what it
really means is "unable to choose a unique left operator '-'
for type 'unknown'", and it ought to suggest adding an explicit
cast. I'll see what I can do about that. But the right way to
fix the fundamental problem is still under debate.
In the meantime you can provide the parser a clue with an
explicit cast:
play=> select -1234567890.1234567::numeric;
?column?
-----------------
-1234567890.12346
(1 row)
This still seems a little broken though, since it looks like the
constant's precision is getting truncated to 15 digits; presumably
there's a coercion to float happening in there somewhere, but I
don't understand where at the moment...
A few minutes later: yes I do: there's no unary minus operator
defined for type numeric, so the parser does the best it can
by applying float8um instead. Jan?
regards, tom lane
From bouncefilter Mon Feb 21 04:09:50 2000
Received: from design.nl (lexington.design.nl [193.78.77.101])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA21701;
Mon, 21 Feb 2000 04:09:11 -0500 (EST)
(envelope-from jeroen@design.nl)
Received: from benny (ranger.design.nl [212.206.76.159])
by design.nl (General Design 1.1) with ESMTP
id KAA01076; Mon, 21 Feb 2000 10:06:04 +0100 (NLD)
Message-Id: <4.2.2.20000221100225.00ab24b0@mail.design.nl>
X-Sender: jeroenv@mail.design.nl
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Date: Mon, 21 Feb 2000 10:07:11 +0100
To: Tom Lane <tgl@sss.pgh.pa.us>
From: Jeroen van Vianen <jeroen@design.nl>
Subject: Re: [PATCHES] Patch for more readable parse error messages
Cc: pgsql-patches@postgreSQL.org, pgsql-hackers@postgreSQL.org
In-Reply-To: <16589.951095020@sss.pgh.pa.us>
References: <4.2.0.58.20000220193250.00969f00@mail.design.nl>
<4.2.0.58.20000220151757.00956ba0@mail.design.nl>
<4.2.0.58.20000220151757.00956ba0@mail.design.nl>
<4.2.0.58.20000220193250.00969f00@mail.design.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 20:03 20-02-00 -0500, Tom Lane wrote:
I do see a potential problem with this patch that's not related to
portability questions; it is that you're assuming that the lexer's
furthest penetration into the source text is a good place to point
at for parser errors. That may not be true always. In particular,
I've been advocating solving some other problems by inserting a
one-token lookahead buffer between the parser and the lexer. If that
happens then you'd be off by (at least) one token in some cases.
That's true, but the '*' indicator might at least indicate the approximate
location of the error. I'm not aware of many (programming) languages that
are able to indicate the error at the correct location all the time, anyway.
I think the way that this sort of thing is customarily handled in
"real" compilers is that each token carries along an indication of
just where it was found in the source, and then error messages can
finger the right place without making assumptions about synchronization
between different phases of the scanning/parsing process. That might
be more work than we can justify for SQL queries; not sure.
True, but requires a lot more work.
BTW, I think that the immediate problem of generating a good error
message for unterminated comments and literals could be solved in other
ways. This patch or something like it might be cool anyway, but you
should bear in mind that printing out a query and then a marker that's
supposed to line up with something in the query doesn't always work
all that well. Consider a query that's several dozen lines long,
such as a large table definition. If we had more control over the
user interface and could highlight the offending token directly,
I'd be more excited about doing something like this. (Actually, you
could partially address that problem by only printing one line's worth
of query text leading up to the error marker point. It would still be
tricky to get it right in the presence of newlines, tabs, etc.)
I try to make a good guess at where the location of the error is, but am
hesitant to only print a few tokens near the error locations, as you won't
be able to know where the error was found in complex queries or table
definitions. Please try with more complex queries and tell me what you think.
Jeroen
From bouncefilter Mon Feb 21 04:56:49 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 EAA30077
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 04:56: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 KAA00330;
Mon, 21 Feb 2000 10:54:31 +0100
Date: Mon, 21 Feb 2000 10:54:31 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
Rafael Jesus Alcantara Perez <rafa@dedalo-ing.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: UESQLC
In-Reply-To: <12605.950979322@sss.pgh.pa.us>
Message-ID: <Pine.LNX.3.96.1000221105103.31581B-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 19 Feb 2000, Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Looks nice. Should we put your code in contrib/ or put the URL on our
web site?The GPL license would pose a problem for including it in our
distribution, I think (GPL vs BSD and all that) --- but no reason
not to link to it from our web pages...
In the current contrib are any matters with GPL
(from Massimo Dal Zotto).
Karel
From bouncefilter Mon Feb 21 08:45:53 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA77566
for <pgsql-hackers@postgresql.org>;
Mon, 21 Feb 2000 08:45: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 JAA63481
for <pgsql-hackers@postgresql.org>;
Mon, 21 Feb 2000 09:45:35 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 21 Feb 2000 09:45:35 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: Beta for 4:30AST ... ?
Message-ID: <Pine.BSF.4.21.0002210944490.86931-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Not having heard anything otherwise, assume we can go Beta today, as
planned?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Feb 21 10:42:55 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 KAA99683
for <pgsql-hackers@postgresql.org>;
Mon, 21 Feb 2000 10:42:01 -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 KAA05902;
Mon, 21 Feb 2000 10:41:53 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-reply-to: <Pine.BSF.4.21.0002210944490.86931-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0002210944490.86931-100000@thelab.hub.org>
Comments: In-reply-to The Hermit Hacker <scrappy@hub.org>
message dated "Mon, 21 Feb 2000 09:45:35 -0400"
Date: Mon, 21 Feb 2000 10:41:53 -0500
Message-ID: <5899.951147713@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
Not having heard anything otherwise, assume we can go Beta today, as
planned?
Might as well --- we have open issues, but there'll always be open
issues. I don't think anyone is still hoping to shoehorn new features
into 7.0, just bug fixes. (Wait, does a unary-minus operator for
numeric count as a new feature ;-) ?)
I do suggest that we had better commit the current state of the rules
regress test output as the expected output, so that we don't have a
lot of confused beta-testers. An actual fix will have to wait for
Thomas to return, but I don't think we want to put off going to beta
just because he's on vacation.
regards, tom lane
From bouncefilter Mon Feb 21 10:44:57 2000
Received: from www.geocrawler.com (sourceforge.net [198.186.203.33])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA00314
for <pgsql-hackers@hub.org>; Mon, 21 Feb 2000 10:44:36 -0500 (EST)
(envelope-from nobody@www.geocrawler.com)
Received: (from nobody@localhost)
by www.geocrawler.com (8.9.3/8.9.3) id HAA24867;
Mon, 21 Feb 2000 07:44:33 -0800
Date: Mon, 21 Feb 2000 07:44:33 -0800
Message-Id: <200002211544.HAA24867@www.geocrawler.com>
To: pgsql-hackers@hub.org
Subject: ShmemCreate: cannot create reg
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.
Hello!
I've tried to compile PostgreSQL v.6.5.2. for SCO
OpenServer 5.0.5.
I used directly instructions from documentation.
Compilation ended with
'All of PostgreSQL is successfully made.
Ready to install.'
But when I tried to start PostgreSQL server I've
got
a message :
'IpcMemoryCreate: shmget failed
(Invalid argument) key=5432001, size=1063936,
permission=600
FATAL 1:
ShmemCreate: cannot create region
'
In compilation log I saw pattern:
'c++ -I../../backend -I../../include -
I../../interfaces/libpq -I../../include -
I../../backend -dy -c pgconnection.cc -o
pgconnection.o
Starting parse
Entering state 0
Reading a token: Next token is 332
(EXTERN_LANG_STRING)
Reducing via rule 3 (line 314), -> @1
state stack now 0
Entering state 2
Reducing via rule 12 (line 340), -> @2
state stack now 0 2
Entering state 4
Next token is 332 (EXTERN_LANG_STRING)
Shifting token 332 (EXTERN_LANG_STRING), Entering
state 34
Reducing via rule 36 (line 400),
EXTERN_LANG_STRING -> extern_lang_string
state stack now 0 2 4
Entering state 38..."
and so on.
(...)
Entering state 1
Reading a token: Now at end of input.
Reducing via rule 2 (line 300), extdefs ->
program
state stack now 0
Entering state 1397
Now at end of input.
Shifting token 0 ($), Entering state 1398
Now at end of input.
All of PostgreSQL is successfully made. Ready to
install.'
Thanks for any help
Regards, Adam Walczykiewicz
(adam.walczykiewicz@multiuser.com.pl)
Geocrawler.com - The Knowledge Archive
From bouncefilter Mon Feb 21 11:15:56 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 LAA08161
for <pgsql-hackers@hub.org>; Mon, 21 Feb 2000 11:15: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 LAA06094;
Mon, 21 Feb 2000 11:15:40 -0500 (EST)
To: "Adam Walczykiewicz" <adam.walczykiewicz@multiuser.com.pl>
cc: pgsql-hackers@hub.org
Subject: Re: [HACKERS] ShmemCreate: cannot create reg
In-reply-to: <200002211544.HAA24867@www.geocrawler.com>
References: <200002211544.HAA24867@www.geocrawler.com>
Comments: In-reply-to "Adam Walczykiewicz" <archiver@db.geocrawler.com>
message dated "Mon, 21 Feb 2000 07:44:33 -0800"
Date: Mon, 21 Feb 2000 11:15:40 -0500
Message-ID: <6091.951149740@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Adam Walczykiewicz" <archiver@db.geocrawler.com> writes:
'IpcMemoryCreate: shmget failed
(Invalid argument) key=5432001, size=1063936,
permission=600
FATAL 1:
ShmemCreate: cannot create region
You're probably running into the kernel limit on the maximum size
of a shared memory region. To get started, try giving -N and -B
switches smaller than the default values (-N 8 -B 32 should work
unless your kernel SHMEMMAX setting is real small).
In the long run you'll probably want to increase your SHMEMMAX
setting so that you can run with more buffers, but I don't know
where to set that on SCO.
regards, tom lane
From bouncefilter Mon Feb 21 12:35:57 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA28287
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 12:35:40 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id JAA15150;
Mon, 21 Feb 2000 09:34:18 -0800 (PST)
Message-Id: <3.0.1.32.20000221092823.010a4ac0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 21 Feb 2000 09:28:23 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, The Hermit Hacker <scrappy@hub.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <5899.951147713@sss.pgh.pa.us>
References: <Pine.BSF.4.21.0002210944490.86931-100000@thelab.hub.org>
<Pine.BSF.4.21.0002210944490.86931-100000@thelab.hub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 10:41 AM 2/21/00 -0500, Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
Not having heard anything otherwise, assume we can go Beta today, as
planned?Might as well --- we have open issues, but there'll always be open
issues. I don't think anyone is still hoping to shoehorn new features
into 7.0, just bug fixes. (Wait, does a unary-minus operator for
numeric count as a new feature ;-) ?)
I've been using a snapshot taken a couple of days ago, which includes
the new datetime stuff and outer join syntax stuff. I've loaded
several thousand lines of data model which has been ported from Oracle
into it, and have been testing our port of the Ars Digita web toolkit
extensively on it. This consists of literally thousands of queries
against the aforementioned data model, which includes nearly 500 foreign
keys including some "on delete/update cascade" and "set null" clauses.
It is all working GREAT. Better than 6.5 (in which case the referential
actions have to be removed anyway, of course), in fact. I've had no
problems with the new datetime stuff, which was of particular concern
to me because the toolkit is full of queries to grab information from
the last week, since your last visit to the website, to update robot
detection tables, to send e-mail alerts to folks who request them daily
or weekly (similar to majordomo digests), to update the database's view
of the site's static content, to build reports on usage of the site,
etc etc. Certain bug fixes really make the port work cleaner, the
"group by" fix (to return no rows if no groups exist) in particular.
Even pg_dump works, though I had to modify a couple of views in order
to get them reload correctly. If I sound like I was a bit nervous of
pg_dump it has to do with those nearly 500 foreign keys I mentioned.
Anyway, from my POV it sure feels like it should be a very solid beta.
I've not run across anything causing me to want to switch back to 6.5.
- 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 Feb 21 12:58:59 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 MAA33044
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 12:58: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
MAA07106;
Mon, 21 Feb 2000 12:57:44 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002211757.MAA07106@candle.pha.pa.us>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <3.0.1.32.20000221092823.010a4ac0@mail.pacifier.com> from Don
Baccus at "Feb 21, 2000 09:28:23 am"
To: Don Baccus <dhogaza@pacifier.com>
Date: Mon, 21 Feb 2000 12:57:44 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, The Hermit Hacker <scrappy@hub.org>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
It is all working GREAT. Better than 6.5 (in which case the referential
actions have to be removed anyway, of course), in fact. I've had no
problems with the new datetime stuff, which was of particular concern
to me because the toolkit is full of queries to grab information from
the last week, since your last visit to the website, to update robot
detection tables, to send e-mail alerts to folks who request them daily
or weekly (similar to majordomo digests), to update the database's view
of the site's static content, to build reports on usage of the site,
etc etc. Certain bug fixes really make the port work cleaner, the
"group by" fix (to return no rows if no groups exist) in particular.Even pg_dump works, though I had to modify a couple of views in order
to get them reload correctly. If I sound like I was a bit nervous of
pg_dump it has to do with those nearly 500 foreign keys I mentioned.Anyway, from my POV it sure feels like it should be a very solid beta.
I've not run across anything causing me to want to switch back to 6.5.
You can thank our may testers, and Tom Lane, who is fixing things like
crazy. Tom has fixed more PostgreSQL bugs than anyone else in the
history of our development.
Though bug fixing is not a glorious job, without reliability, we are
useless.
Thanks, Tom.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 21 13:20:59 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA38473
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 13:20:24 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id KAA01236;
Mon, 21 Feb 2000 10:19:25 -0800 (PST)
Message-Id: <3.0.1.32.20000221100856.010a12c0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 21 Feb 2000 10:08:56 -0800
To: Bruce Momjian <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
Cc: Tom Lane <tgl@sss.pgh.pa.us>, The Hermit Hacker <scrappy@hub.org>,
pgsql-hackers@postgreSQL.org
In-Reply-To: <200002211757.MAA07106@candle.pha.pa.us>
References: <3.0.1.32.20000221092823.010a4ac0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 12:57 PM 2/21/00 -0500, Bruce Momjian wrote:
You can thank our may testers, and Tom Lane, who is fixing things like
crazy. Tom has fixed more PostgreSQL bugs than anyone else in the
history of our development.Though bug fixing is not a glorious job, without reliability, we are
useless.Thanks, Tom.
Yes, I've noticed that Tom takes on bugs like a pitbull takes on
mail carriers, and I do appreciate it.
I'm not allergic to fixing bugs, and as I learn more about PG
hope to dig into doing so with gusto.
- 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 Feb 21 13:09:57 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 NAA35914
for <pgsql-hackers@postgresql.org>;
Mon, 21 Feb 2000 13:09:22 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.34.146]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Mon, 21 Feb 2000 11:58:57 -0600
Sender: ed
Message-ID: <38B17FC4.DA85890B@austin.rr.com>
Date: Mon, 21 Feb 2000 12:11:16 -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: Don Baccus <dhogaza@pacifier.com>
CC: Tom Lane <tgl@sss.pgh.pa.us>, The Hermit Hacker <scrappy@hub.org>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
References: <Pine.BSF.4.21.0002210944490.86931-100000@thelab.hub.org>
<Pine.BSF.4.21.0002210944490.86931-100000@thelab.hub.org>
<3.0.1.32.20000221092823.010a4ac0@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Don Baccus wrote:
Even pg_dump works, though I had to modify a couple of views in order
to get them reload correctly.
Don, could you elaborate on what you had to do to make your views
reload correctly?
Cheers,
Ed Loehr
From bouncefilter Mon Feb 21 13:19:11 2000
Received: from mailgw1.prontomail.com (mailgw1.prontomail.com
[209.185.149.197]) by hub.org (8.9.3/8.9.3) with ESMTP id NAA38061
for <pgsql-hackers@postgresql.org>;
Mon, 21 Feb 2000 13:18:33 -0500 (EST)
(envelope-from rob.c@virgilio.it)
From: rob.c@virgilio.it
Received: from web36 (209.185.149.236) by mailgw1.prontomail.com (NPlex
2.0.123) for pgsql-hackers@postgresql.org;
Mon, 21 Feb 2000 10:17:45 -0800
Message-Id: <09C70821E48E3D1178B200807CFD4B52@rob.c.virgilio.it>
Date: Mon, 21 Feb 2000 13:17:46 -0500
X-Priority: Normal
Content-Type: text/plain; charset=iso-8859-1
To: pgsql-hackers@postgresql.org
Subject: subscribe
X-Mailer: Web Based Pronto
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
subscribe
===========================================================
VIRGILIO MAIL - Il tuo indirizzo E-mail gratis e per sempre
http://mail.virgilio.it/
VIRGILIO - La guida italiana a Internet
http://www.virgilio.it/
From bouncefilter Mon Feb 21 13:31:04 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA40551
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 13:30:37 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id KAA04874;
Mon, 21 Feb 2000 10:29:31 -0800 (PST)
Message-Id: <3.0.1.32.20000221102715.010ada40@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 21 Feb 2000 10:27:15 -0800
To: Ed Loehr <eloehr@austin.rr.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
Cc: Tom Lane <tgl@sss.pgh.pa.us>, The Hermit Hacker <scrappy@hub.org>,
pgsql-hackers@postgresql.org
In-Reply-To: <38B17FC4.DA85890B@austin.rr.com>
References: <Pine.BSF.4.21.0002210944490.86931-100000@thelab.hub.org>
<Pine.BSF.4.21.0002210944490.86931-100000@thelab.hub.org>
<3.0.1.32.20000221092823.010a4ac0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 12:11 PM 2/21/00 -0600, Ed Loehr wrote:
Don Baccus wrote:
Even pg_dump works, though I had to modify a couple of views in order
to get them reload correctly.Don, could you elaborate on what you had to do to make your views
reload correctly?
Good timing - I was about to post on this subject anyway.
I was able to fix my views by changing:
create view foo as select * from bar;
to:
...select * from bar bar;
In other words, an explicit declaration of the range table name (is
that the right term?P my mind's numb from porting queries all weekend)
leads to a rule that will reload.
I figured this out because there are some fairly complex views in
this datamodel, which use explicit names to avoid ambiguous column
references.
The standard actually says that a from clause like "from bar"
implicitly declares "bar" for you, i.e. is exactly equivalent
to "from bar bar". If Postgres name scoping - which I know is
not standard-compliant in the JOIN syntax case - is close enough
so that a transformation of "from bar" to "from bar bar" could
be done in the parser without breaking existing code, then a
lot more views could be successfully be dumped and reloaded.
Would all views dump/reload, or are there other problems I don't know
about? I'm not in a position to judge, I've been too deeply embedded
in getting this toolkit ready for release (our first will be Wednesday)
to worry about the general case. However, I do know that doing the
transformation by hand in the datamodel source has fixed the problem
for me.
Does anyone know if there are other problems?
Even if there are, a simple transformation such as I describe would
help - IF it didn't break existing code. If it would break existing
code, then it is due to non-compliance with the standard so perhaps
wouldn't be such a terrible thing, either. I'm not really in a
position to judge.
What do folks think?
- 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 Feb 21 13:59:59 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 NAA47638
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 13:59: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
NAA09910;
Mon, 21 Feb 2000 13:59:07 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002211859.NAA09910@candle.pha.pa.us>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <3.0.1.32.20000221100856.010a12c0@mail.pacifier.com> from Don
Baccus at "Feb 21, 2000 10:08:56 am"
To: Don Baccus <dhogaza@pacifier.com>
Date: Mon, 21 Feb 2000 13:59:07 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, The Hermit Hacker <scrappy@hub.org>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
At 12:57 PM 2/21/00 -0500, Bruce Momjian wrote:
You can thank our may testers, and Tom Lane, who is fixing things like
crazy. Tom has fixed more PostgreSQL bugs than anyone else in the
history of our development.Though bug fixing is not a glorious job, without reliability, we are
useless.Thanks, Tom.
Yes, I've noticed that Tom takes on bugs like a pitbull takes on
mail carriers, and I do appreciate it.
Yes, and we badly needed someone like that before Tom came along. I
used to do it, but in a very pitiful way. Mostly I just added them to
the TODO list.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 21 14:06:58 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 OAA49622
for <pgsql-hackers@postgresql.org>;
Mon, 21 Feb 2000 14:06:21 -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 OAA16721;
Mon, 21 Feb 2000 14:06:13 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-reply-to: <5899.951147713@sss.pgh.pa.us>
References: <Pine.BSF.4.21.0002210944490.86931-100000@thelab.hub.org>
<5899.951147713@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
message dated "Mon, 21 Feb 2000 10:41:53 -0500"
Date: Mon, 21 Feb 2000 14:06:13 -0500
Message-ID: <16718.951159973@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Tom Lane <tgl@sss.pgh.pa.us> writes:
The Hermit Hacker <scrappy@hub.org> writes:
Not having heard anything otherwise, assume we can go Beta today, as
planned?
Might as well --- we have open issues, but there'll always be open
issues. I don't think anyone is still hoping to shoehorn new features
into 7.0, just bug fixes.
OK, I'm done shoehorning in last-minute bug fixes, too. You may fire
when ready, as far as I'm concerned.
I did commit current rules output per my previous note. Regression
tests pass 100% clean on my primary box; haven't tried other systems
yet.
regards, tom lane
From bouncefilter Mon Feb 21 14:08:59 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 OAA50018
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 14:08: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
OAA10055;
Mon, 21 Feb 2000 14:07:26 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002211907.OAA10055@candle.pha.pa.us>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <3.0.1.32.20000221102715.010ada40@mail.pacifier.com> from Don
Baccus at "Feb 21, 2000 10:27:15 am"
To: Don Baccus <dhogaza@pacifier.com>
Date: Mon, 21 Feb 2000 14:07:26 -0500 (EST)
CC: Ed Loehr <eloehr@austin.rr.com>, Tom Lane <tgl@sss.pgh.pa.us>,
The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
At 12:11 PM 2/21/00 -0600, Ed Loehr wrote:
Don Baccus wrote:
Even pg_dump works, though I had to modify a couple of views in order
to get them reload correctly.Don, could you elaborate on what you had to do to make your views
reload correctly?Good timing - I was about to post on this subject anyway.
I was able to fix my views by changing:
create view foo as select * from bar;
to:
...select * from bar bar;
In other words, an explicit declaration of the range table name (is
Yes, right name.
I am totally confused why "from bar bar" is different from "bar".
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 21 14:20:59 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 OAA52829
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 14:20:02 -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
OAA12426;
Mon, 21 Feb 2000 14:19:37 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002211919.OAA12426@candle.pha.pa.us>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <16718.951159973@sss.pgh.pa.us> from Tom Lane at "Feb 21,
2000 02:06:13 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 21 Feb 2000 14:19:37 -0500 (EST)
CC: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Tom Lane <tgl@sss.pgh.pa.us> writes:
The Hermit Hacker <scrappy@hub.org> writes:
Not having heard anything otherwise, assume we can go Beta today, as
planned?Might as well --- we have open issues, but there'll always be open
issues. I don't think anyone is still hoping to shoehorn new features
into 7.0, just bug fixes.OK, I'm done shoehorning in last-minute bug fixes, too. You may fire
when ready, as far as I'm concerned.
Last call for partially implemented changes that you want to get in
before feature freeze... :-)
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 21 14:28:03 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 OAA54672
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 14:27:18 -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 OAA23465;
Mon, 21 Feb 2000 14:27:09 -0500 (EST)
To: Don Baccus <dhogaza@pacifier.com>
cc: Ed Loehr <eloehr@austin.rr.com>, The Hermit Hacker <scrappy@hub.org>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-reply-to: <3.0.1.32.20000221102715.010ada40@mail.pacifier.com>
References: <Pine.BSF.4.21.0002210944490.86931-100000@thelab.hub.org>
<Pine.BSF.4.21.0002210944490.86931-100000@thelab.hub.org>
<3.0.1.32.20000221092823.010a4ac0@mail.pacifier.com>
<3.0.1.32.20000221102715.010ada40@mail.pacifier.com>
Comments: In-reply-to Don Baccus <dhogaza@pacifier.com>
message dated "Mon, 21 Feb 2000 10:27:15 -0800"
Date: Mon, 21 Feb 2000 14:27:08 -0500
Message-ID: <23462.951161228@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Don Baccus <dhogaza@pacifier.com> writes:
I was able to fix my views by changing:
create view foo as select * from bar;
to:
...select * from bar bar;
Hmm, I think I see it.
create view foo as select * from int8_tbl;
$ pg_dump -t foo regression
\connect - postgres
CREATE TABLE "foo" (
"q1" int8,
"q2" int8
);
CREATE RULE "_RETfoo" AS ON SELECT TO foo DO INSTEAD SELECT int8_tbl.q1,
int8_tbl.q2 FROM int8_tbl (q1, q2);
IIRC, Thomas explained that the ANSI syntax says you *must* supply a
table alias if you are going to supply any column aliases in FROM.
The regurgitated rule violates that.
I guess this is another manifestation of the issue about the system
shoving in column "aliases" that the user never typed. pg_dump is
probably repeating what the backend told it. Think we'll have to
leave it unfixed till Thomas gets back.
It's also a reminder that the regress tests don't exercise pg_dump :-(
regards, tom lane
From bouncefilter Mon Feb 21 14:38:58 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA56932
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 14:35:16 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id LAA01011;
Mon, 21 Feb 2000 11:33:30 -0800 (PST)
Message-Id: <3.0.1.32.20000221112804.010ad930@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 21 Feb 2000 11:28:04 -0800
To: Bruce Momjian <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
Cc: Ed Loehr <eloehr@austin.rr.com>, Tom Lane <tgl@sss.pgh.pa.us>,
The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
In-Reply-To: <200002211907.OAA10055@candle.pha.pa.us>
References: <3.0.1.32.20000221102715.010ada40@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 02:07 PM 2/21/00 -0500, Bruce Momjian wrote:
I am totally confused why "from bar bar" is different from "bar".
In the rule created for the view, the from clause gets generated
like this:
"from foo (list of columns), ..."
or - if an explicit range table name is given
"from foo foo (list of columns), ..."
The parser doesn't like the first form, is googoo-eyed over
the second and takes it without error. I'm too busy to look at Date
or the SQL standard at the moment, but the list of columns is a non-standard
PG-ism anyway, isn't it? Something lingering from pre-SQL days?
Is the list of columns even needed? Is this some inheritance-related
thing?
As I mentioned in my earlier note, I was too swamped by my porting
effort to dig into this at all, and between work, the web toolkit,
and work on http://birdnotes.net won't have time to explore this
in the next couple of weeks. I did take enough time to see that
the rule is built on the parse tree for the underlying select which
is why the hack of adding the range table name explicitly while
parsing if it's not mentioned came to mind.
- 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 Feb 21 14:42:00 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA58677
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 14:41:26 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id LAA03821;
Mon, 21 Feb 2000 11:40:42 -0800 (PST)
Message-Id: <3.0.1.32.20000221113824.010b0d80@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 21 Feb 2000 11:38:24 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
Cc: Ed Loehr <eloehr@austin.rr.com>, The Hermit Hacker <scrappy@hub.org>,
pgsql-hackers@postgreSQL.org
In-Reply-To: <23462.951161228@sss.pgh.pa.us>
References: <3.0.1.32.20000221102715.010ada40@mail.pacifier.com>
<Pine.BSF.4.21.0002210944490.86931-100000@thelab.hub.org>
<Pine.BSF.4.21.0002210944490.86931-100000@thelab.hub.org>
<3.0.1.32.20000221092823.010a4ac0@mail.pacifier.com>
<3.0.1.32.20000221102715.010ada40@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 02:27 PM 2/21/00 -0500, Tom Lane wrote:
Don Baccus <dhogaza@pacifier.com> writes:
IIRC, Thomas explained that the ANSI syntax says you *must* supply a
table alias if you are going to supply any column aliases in FROM.
The regurgitated rule violates that.
Ahhh...column aliases...these ARE standard SQL, then! I'll be...
I need to spend a couple of days studying Date thorougly someday, rather
than just cherry-picking when specific questions come to mind.
I guess this is another manifestation of the issue about the system
shoving in column "aliases" that the user never typed.
Yes.
pg_dump is probably repeating what the backend told it.
My fifteen minute sprint through the code led me to believe this
is true.
Think we'll have to
leave it unfixed till Thomas gets back.
That would be plenty of time to get it in for the real 7.0 release.
If indeed PG would survive the insertion of the table name as a
table alias when none is given - the standard semantics, in other
words - it would be very simple to do. I'm just a little queasy
about possible side-effects.
It's also a reminder that the regress tests don't exercise pg_dump :-(
Ohhh...that's not good.
- 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 Feb 21 14:41:58 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 OAA58671
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 14:41:24 -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
OAA13237;
Mon, 21 Feb 2000 14:39:08 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002211939.OAA13237@candle.pha.pa.us>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <3.0.1.32.20000221112804.010ad930@mail.pacifier.com> from Don
Baccus at "Feb 21, 2000 11:28:04 am"
To: Don Baccus <dhogaza@pacifier.com>
Date: Mon, 21 Feb 2000 14:39:08 -0500 (EST)
CC: Ed Loehr <eloehr@austin.rr.com>, Tom Lane <tgl@sss.pgh.pa.us>,
The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
At 02:07 PM 2/21/00 -0500, Bruce Momjian wrote:
I am totally confused why "from bar bar" is different from "bar".
In the rule created for the view, the from clause gets generated
like this:"from foo (list of columns), ..."
or - if an explicit range table name is given
"from foo foo (list of columns), ..."
Got it:
test=> select * from pg_class pg_class (relname);
Wow, that is some strange syntax, and I didn't know we even allowed
that.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 21 14:46:58 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA60105
for <pgsql-hackers@postgresql.org>;
Mon, 21 Feb 2000 14:46:23 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63416 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S233480AbQBUTp0>;
Mon, 21 Feb 2000 20:45:26 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12MyoT-0001dT-00; Mon, 21 Feb 2000 20:48:09 +0100
Date: Mon, 21 Feb 2000 20:48:08 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] new backslash command of psql
In-Reply-To: <200002202150.QAA19651@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.21.0002212046290.349-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-02-20, Bruce Momjian mentioned:
We already have some special variable meanings like \set PROMPT1 which
controls the psql prompt. Seems an encoding variable can be made too.
Setting the encoding actually has to *do* something though. The prompt
will just be stored and read out next time it's needed. I guess one could
include hooks into the set variable command, but I figured multibyte as we
know it is going away soon anyway ...
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Mon Feb 21 09:50:58 2000
Received: from sibcol.irk.ru (sibcol.irk.ru [195.206.40.122])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA91707
for <pgsql-hackers@postgresql.org>;
Mon, 21 Feb 2000 09:50:38 -0500 (EST)
(envelope-from geel@sibcol.irk.ru)
Received: from geel (50-11.ppp.dsi.ru [195.206.50.11])
by sibcol.irk.ru (8.9.3/8.8.7) with SMTP id WAA02278
for <pgsql-hackers@postgresql.org>;
Mon, 21 Feb 2000 22:50:28 +0800 (IRKT)
(envelope-from geel@sibcol.irk.ru)
Message-ID: <001201bf7ca4$f88e0140$0100a8c0@geel.bigbang>
From: "j.j.geel" <geel@sibcol.irk.ru>
To: <pgsql-hackers@postgresql.org>
Subject:
Date: Mon, 21 Feb 2000 22:50:55 +0300
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_000F_01BF7CBE.1C6254E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
This is a multi-part message in MIME format.
------=_NextPart_000_000F_01BF7CBE.1C6254E0
Content-Type: text/plain;
charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
subscribe
------=_NextPart_000_000F_01BF7CBE.1C6254E0
Content-Type: text/html;
charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Dkoi8-r http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#d8d0c8>
<DIV><FONT color=3D#000000 face=3D"Arial Cyr"=20
size=3D2>subscribe</FONT></DIV></BODY></HTML>
------=_NextPart_000_000F_01BF7CBE.1C6254E0--
From bouncefilter Mon Feb 21 14:52:58 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 OAA61734
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 14:52:27 -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 OAA27931;
Mon, 21 Feb 2000 14:52:02 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Numeric with '-'
In-reply-to: <000401bf7c3a$1fec7200$2801007e@tpf.co.jp>
References: <000401bf7c3a$1fec7200$2801007e@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Mon, 21 Feb 2000 16:06:07 +0900"
Date: Mon, 21 Feb 2000 14:52:02 -0500
Message-ID: <27928.951162722@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
The following phenomenon was reported to pgsql-jp(ML in Japan).
rest=# select -1234567890.1234567;
ERROR: Unable to convert left operator '-' from type 'unknown'
I've committed fixes that make the parser treat numeric literals
the same no matter how many digits they have. With current sources,
regression=# select -1234567890.1234567;
?column?
-------------------
-1234567890.12346
(1 row)
which is probably still not what you want, because the default
type for a non-integer literal is float8 in the absence of any
context to clue the system otherwise, so you lose precision.
You can do
regression=# select -1234567890.12345678900::numeric;
?column?
-------------------------
-1234567890.12345678900
(1 row)
but in reality that's only working because of the way that doNegate
works on literals; since there is no unary minus operator for NUMERIC,
a minus on a non-constant value is going to be coerced to float8:
regression=# select -val from num_data;
?column?
------------------
0
0
34338492.215397
-4.31
-7799461.4119
-16397.038491
-93901.57763026
83028485
-74881
24926804.0450474
(10 rows)
whereas this works right:
regression=# select 0-val from num_data;
?column?
---------------------
0.0000000000
0.0000000000
34338492.2153970470
-4.3100000000
-7799461.4119000000
-16397.0384910000
-93901.5776302600
83028485.0000000000
-74881.0000000000
24926804.0450474200
(10 rows)
Somebody ought to write a NUMERIC unary minus...
regards, tom lane
From bouncefilter Mon Feb 21 15:25:59 2000
Received: from bohr.webline.dk (root@65.ppp3-1.image.dk [212.54.75.65])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA69605
for <pgsql-hackers@postgresql.org>;
Mon, 21 Feb 2000 15:25:55 -0500 (EST) (envelope-from kar@webline.dk)
Received: from bering (kar@bering.webline.dk [192.168.1.10])
by bohr.webline.dk (8.9.3/8.8.8) with SMTP id VAA06776
for <pgsql-hackers@postgresql.org>; Mon, 21 Feb 2000 21:19:40 +0100
From: Kaare Rasmussen <kar@webline.dk>
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
Date: Mon, 21 Feb 2000 20:58:44 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <200002211757.MAA07106@candle.pha.pa.us>
In-Reply-To: <200002211757.MAA07106@candle.pha.pa.us>
MIME-Version: 1.0
Message-Id: <00022121005503.00287@bering>
Content-Transfer-Encoding: 8bit
You can thank our may testers, and Tom Lane, who is fixing things like
crazy. Tom has fixed more PostgreSQL bugs than anyone else in the
history of our development.
It's very impressive. I've noticed many times that someone mentions a bug, and
sometimes hours later Tom has cornered the problem. Maybe one or two questions
about how to go about it, and then the hole is plugged.
From bouncefilter Mon Feb 21 15:01: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 PAA64270
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 15:00:59 -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
OAA13815;
Mon, 21 Feb 2000 14:58:59 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002211958.OAA13815@candle.pha.pa.us>
Subject: Re: [HACKERS] new backslash command of psql
In-Reply-To: <Pine.LNX.4.21.0002212046290.349-100000@localhost.localdomain>
from Peter Eisentraut at "Feb 21, 2000 08:48:08 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Mon, 21 Feb 2000 14:58:59 -0500 (EST)
CC: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
On 2000-02-20, Bruce Momjian mentioned:
We already have some special variable meanings like \set PROMPT1 which
controls the psql prompt. Seems an encoding variable can be made too.Setting the encoding actually has to *do* something though. The prompt
will just be stored and read out next time it's needed. I guess one could
include hooks into the set variable command, but I figured multibyte as we
know it is going away soon anyway ...
Oh, I though it didn't need hooks. Never mind.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 21 15:26:02 2000
Received: from bohr.webline.dk (root@65.ppp3-1.image.dk [212.54.75.65])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA69600
for <pgsql-hackers@postgresql.org>;
Mon, 21 Feb 2000 15:25:48 -0500 (EST) (envelope-from kar@webline.dk)
Received: from bering (kar@bering.webline.dk [192.168.1.10])
by bohr.webline.dk (8.9.3/8.8.8) with SMTP id VAA06782
for <pgsql-hackers@postgresql.org>; Mon, 21 Feb 2000 21:19:56 +0100
From: Kaare Rasmussen <kar@webline.dk>
To: pgsql-hackers@postgresql.org
Subject: TODO list / why 7.0 ?
Date: Mon, 21 Feb 2000 21:01:26 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <200002211757.MAA07106@candle.pha.pa.us>
<00022121005503.00287@bering>
In-Reply-To: <00022121005503.00287@bering>
MIME-Version: 1.0
Message-Id: <00022121082604.00287@bering>
Content-Transfer-Encoding: 8bit
Having been away for some time I'm very anxious to see that there's a 7.0
release coming very soon. I extracted the TODO list from the CVS (latest update
February 9). The only really really big issue as I see it is referential
integrity. This is big, I admit but why going to 7.0 for this? Or is it because
it's long overdue (MSVC and stuff)?
There are other things that must have taken a lot of work, only it's not
mainstream the same way referential integrity is (PL/Perl and more). I had
hoped to find outer joins, but look forward to the next release if it will be
there.
Maybe I missed something in the TODO list or in the fixed list, but I couldn't
find VIEWs with UNIONs, which I understand would be solved by a rewrite of the
rules system.
From bouncefilter Mon Feb 21 15:27:59 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 PAA69995
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 15:27:23 -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 PAA29007;
Mon, 21 Feb 2000 15:27:12 -0500 (EST)
To: Don Baccus <dhogaza@pacifier.com>
cc: Ed Loehr <eloehr@austin.rr.com>, The Hermit Hacker <scrappy@hub.org>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-reply-to: <3.0.1.32.20000221113824.010b0d80@mail.pacifier.com>
References: <3.0.1.32.20000221102715.010ada40@mail.pacifier.com>
<Pine.BSF.4.21.0002210944490.86931-100000@thelab.hub.org>
<Pine.BSF.4.21.0002210944490.86931-100000@thelab.hub.org>
<3.0.1.32.20000221092823.010a4ac0@mail.pacifier.com>
<3.0.1.32.20000221102715.010ada40@mail.pacifier.com>
<3.0.1.32.20000221113824.010b0d80@mail.pacifier.com>
Comments: In-reply-to Don Baccus <dhogaza@pacifier.com>
message dated "Mon, 21 Feb 2000 11:38:24 -0800"
Date: Mon, 21 Feb 2000 15:27:12 -0500
Message-ID: <29004.951164832@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Don Baccus <dhogaza@pacifier.com> writes:
Think we'll have to
leave it unfixed till Thomas gets back.
That would be plenty of time to get it in for the real 7.0 release.
I don't like shipping betas with broken pg_dump; that makes life
unreasonably difficult for beta testers, if we have to force another
initdb before release. So I put in a quick hack solution: don't print
the column alias list at all unless there is a table alias. This makes
the rule's FROM clause conform to ANSI syntax. If you actually did
write
create view foo as SELECT alias FROM table table (alias);
then it will dump as
create view foo as SELECT table.realcolname AS alias FROM table;
but there's no harm done. Better solution needed but I'll let Thomas
provide it.
And now, it's 4:30 PM AST and we are outta here ... right Marc?
regards, tom lane
From bouncefilter Mon Feb 21 15:31:59 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA71177
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 15:31:28 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id MAA20650;
Mon, 21 Feb 2000 12:30:41 -0800 (PST)
Message-Id: <3.0.1.32.20000221122828.010b4250@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 21 Feb 2000 12:28:28 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
Cc: Ed Loehr <eloehr@austin.rr.com>, The Hermit Hacker <scrappy@hub.org>,
pgsql-hackers@postgreSQL.org
In-Reply-To: <29004.951164832@sss.pgh.pa.us>
References: <3.0.1.32.20000221113824.010b0d80@mail.pacifier.com>
<3.0.1.32.20000221102715.010ada40@mail.pacifier.com>
<Pine.BSF.4.21.0002210944490.86931-100000@thelab.hub.org>
<Pine.BSF.4.21.0002210944490.86931-100000@thelab.hub.org>
<3.0.1.32.20000221092823.010a4ac0@mail.pacifier.com>
<3.0.1.32.20000221102715.010ada40@mail.pacifier.com>
<3.0.1.32.20000221113824.010b0d80@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 03:27 PM 2/21/00 -0500, Tom Lane wrote:
I don't like shipping betas with broken pg_dump; that makes life
unreasonably difficult for beta testers, if we have to force another
initdb before release. So I put in a quick hack solution: don't print
the column alias list at all unless there is a table alias. This makes
the rule's FROM clause conform to ANSI syntax. If you actually did
write
create view foo as SELECT alias FROM table table (alias);
then it will dump as
create view foo as SELECT table.realcolname AS alias FROM table;
but there's no harm done. Better solution needed but I'll let Thomas
provide it.
EXCELLENT!
- 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 Feb 21 15:41:59 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA73525
for <pgsql-hackers@postgresql.org>;
Mon, 21 Feb 2000 15:41: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 QAA67671;
Mon, 21 Feb 2000 16:40:59 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 21 Feb 2000 16:40:59 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Kaare Rasmussen <kar@webline.dk>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] TODO list / why 7.0 ?
In-Reply-To: <00022121082604.00287@bering>
Message-ID: <Pine.BSF.4.21.0002211640510.86931-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Long Overdue ;)
On Mon, 21 Feb 2000, Kaare Rasmussen wrote:
Having been away for some time I'm very anxious to see that there's a 7.0
release coming very soon. I extracted the TODO list from the CVS (latest update
February 9). The only really really big issue as I see it is referential
integrity. This is big, I admit but why going to 7.0 for this? Or is it because
it's long overdue (MSVC and stuff)?There are other things that must have taken a lot of work, only it's not
mainstream the same way referential integrity is (PL/Perl and more). I had
hoped to find outer joins, but look forward to the next release if it will be
there.Maybe I missed something in the TODO list or in the fixed list, but I couldn't
find VIEWs with UNIONs, which I understand would be solved by a rewrite of the
rules system.************
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Feb 21 17:22: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 RAA96458
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 17:21:24 -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 RAA29563;
Mon, 21 Feb 2000 17:21:15 -0500 (EST)
To: Kaare Rasmussen <kar@webline.dk>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO list / why 7.0 ?
In-reply-to: <00022121082604.00287@bering>
References: <200002211757.MAA07106@candle.pha.pa.us>
<00022121005503.00287@bering> <00022121082604.00287@bering>
Comments: In-reply-to Kaare Rasmussen <kar@webline.dk>
message dated "Mon, 21 Feb 2000 21:01:26 +0100"
Date: Mon, 21 Feb 2000 17:21:15 -0500
Message-ID: <29560.951171675@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Kaare Rasmussen <kar@webline.dk> writes:
This is big, I admit but why going to 7.0 for this? Or is it because
it's long overdue (MSVC and stuff)?
A number of people thought 6.5 should have been called 7.0 because of
MVCC. A number of other people thought that this release should be 6.6,
and the next one (which should have outer joins and much better VIEWs
thanks to a redesigned querytree representation) should be 7.0.
I think it's kind of a compromise ;-).
OTOH, if you look less at bullet points on a feature list and more at
reliability and quality of implementation, there's plenty of material
to argue that this indeed deserves to be 7.0. I think we have made
a quantum jump in our ability to understand and improve the Berkeley
code over the past year --- at least I have, maybe I shouldn't speak
for the other developers. There have been some pretty significant
improvements under-the-hood, and I think those are going to translate
directly into a more reliable system.
regards, tom lane
From bouncefilter Mon Feb 21 18:56:07 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA21586
for <pgsql-hackers@postgresql.org>;
Mon, 21 Feb 2000 18:55:34 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62150 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S243726AbQBUXyb>;
Tue, 22 Feb 2000 00:54:31 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12N2hU-00026v-00; Tue, 22 Feb 2000 00:57:12 +0100
Date: Tue, 22 Feb 2000 00:57:12 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Hannu Krosing <hannu@tm.ee>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: SQL compliance - why -- comments only at psql
level?
In-Reply-To: <5348.951068504@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0002220002360.349-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-02-20, Tom Lane mentioned:
select *-- 123
ERROR: Can't find left op '*--' for type 23
select /**/- 22
ERROR: parser: parse error at or near ""
I believe that these things (certainly the first one) could be fixed by
making the {operator} rule in scan.l rescanning yytext for "--" or "/*"
(using string functions) and if found putting part of the token back in
the input stream using yyless().
Meanwhile, psql is using some ad-hoc code to recognize comments,
rather than a lexer, and it thinks both of these sequences are indeed
comments.
Incidentally, it's right. ;)
I suggest we change psql to not strip -- comments either.
That sounds reasonable, although we had a painful discussion about this
last fall, I recall, that ended with me leaving it like that. If someone
wants to bother, be my guest. One of these days, psql should get a lexer
to fix some other parsing problems as well.
but <<EOF>> is a flex-ism not supported by regular lex.
Exclusive start conditions are not supported by regular lex either. We
lose. Sometimes I think we're actually doing people a favour by requiring
flex, because then they don't have to deal with incarnations like Sun's.
If you want to catch unbalanced quotes at the end of input, I could
imagine that some grand unified evilness via yywrap setting some global
flag or two might get the job done.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Mon Feb 21 18:56:02 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA21587
for <pgsql-hackers@postgresql.org>;
Mon, 21 Feb 2000 18:55:37 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62211 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S126985AbQBUXyg>;
Tue, 22 Feb 2000 00:54:36 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12N2hf-00027P-00; Tue, 22 Feb 2000 00:57:23 +0100
Date: Tue, 22 Feb 2000 00:57:23 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error
messages
In-Reply-To: <16589.951095020@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0002220023260.349-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-02-20, Tom Lane mentioned:
I would not like us to stop working
with non-bison yaccs, since bison's output depends on alloca() which
is not available everywhere.
Couldn't alloca(x) be defined to palloc(x) where missing? The performance
will be worse, but it ought to work.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Mon Feb 21 18:56:05 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA21589
for <pgsql-hackers@postgresql.org>;
Mon, 21 Feb 2000 18:55:41 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62478 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S247808AbQBUXyz>;
Tue, 22 Feb 2000 00:54:55 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12N2hq-00027m-00; Tue, 22 Feb 2000 00:57:34 +0100
Date: Tue, 22 Feb 2000 00:57:34 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: bhirt@mobygames.com, Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Numeric with '-'
In-Reply-To: <2016.951123651@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0002220031170.349-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-02-21, Tom Lane mentioned:
I've been ranting about this in a recent pghackers thread ;-).
The lexer shouldn't have to commit to a conversion to float8
in order to report that a token looks like a numeric literal.
Has the ranting resulted in any idea yet? ISTM that keeping a non-integer
number as a string all the way to the executor shouldn't hurt too much.
After all, according to SQL 123.45 *is* a NUMERIC literal! By making it a
float we're making our users liable to breaking all kinds of fiscal
regulations in some places. (Ask Jan.)
The resulting error message
ERROR: Unable to convert left operator '-' from type 'unknown'
isn't exactly up to a high standard of clarity either;
Speaking of 'unknown', this is my favourite brain-damaged query of all
times:
peter=> select 'a' like 'a';
ERROR: Unable to identify an operator '~~' for types 'unknown' and 'unknown'
You will have to retype this query using an explicit cast
Is there a good reason that a character literal is unknown? I'm sure the
reasons lie somewhere in the extensible type system, but if I wanted it to
be something else explicitly then I would have written DATE 'yesterday'.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Mon Feb 21 18:59:02 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA22151;
Mon, 21 Feb 2000 18:58: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 TAA69179;
Mon, 21 Feb 2000 19:57:56 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 21 Feb 2000 19:57:56 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: webmaster@postgreSQL.org, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <29004.951164832@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0002211952550.86931-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Working on the Release Announcement now ... Bruce, how accurate is the
current TODO list? If I go through it looking for all items marked as
'-', I come up with the following list. Is it missing anything? I know
not *everything* has to be listed, so I'm more afraid of listing something
that shouldn't then not listing enough ...
The beta1.tar.gz snapshot has been created ... I'll put out an
announcement later tonight once I've heard back on this list, which also
gives some of the mirror sites a chance to sync up, and Vince a chance to
update the web site...
=============================================
RELIABILITY
RESOURCES
* -Disallow inherited columns with the same name as new columns
* -Elog() does not free all its memory
* -spinlock stuck problem when elog(FATAL) and elog(ERROR) inside bufmgr
* -Recover or force failure when disk space is exhausted(Hiroshi)
PARSER
* -INSERT INTO ... SELECT with AS columns matching result columns problem
* -Select a[1] FROM test fails, it needs test.a[1](Tom)
* -Array index references without table name cause problems [array](Tom)
* -INSERT ... SELECT ... GROUP BY groups by target columns not source
columns(Tom)
* -CREATE TABLE test (a char(5) DEFAULT text '', b int4) fails on
INSERT(Tom)
* -UNION with LIMIT fails
* -CREATE TABLE x AS SELECT 1 UNION SELECT 2 fails
* -CREATE TABLE test(col char(2) DEFAULT user) fails in length
restriction
* -mismatched types in CREATE TABLE ... DEFAULT causes problems [default]
* -SELECT ... UNION ... ORDER BY fails when sort expr not in result list,
ORDER BY is applied only to the first SELECT
* -select * from pg_class where oid in (0,-1)
* -prevent primary key that exceeds max index columns [primary]
* -SELECT COUNT('asdf') FROM pg_class WHERE oid=12 crashes
* -require SELECT DISTINCT target list to have all ORDER BY columns
* -When using aggregates + GROUP BY, no rows in should yield no rows
out(Tom)
* -Allow HAVING to use comparisons that have no aggregates(Tom)
* -Allow COUNT(DISTINCT col))(TOm)
VIEWS
* -Views with spaces in view name fail when referenced
MISC
* -User who can create databases can modify pg_database table(Peter E)
* -Fix btree to give a useful elog when key > 1/2 (page - overhead)(Tom)
* -pg_dump should preserve primary key information
* -database names with spaces fail
* -insert of 0.0 into DECIMAL(4,4) field fails(Tom)
* -* Interlock to prevent DROP DATABASE on a database with running
backendsInterlock to prevent DROP DATABASE on a database with running
backends
ENHANCEMENTS
URGENT
* -Add referential integrity(Jan)[primary]
* -Eliminate limits on query length
* -Fix memory leak for aggregates(Tom)
ADMIN
* -Better interface for adding to pg_group(Peter E)
* -Generate postmaster pid file and remove flock/fcntl lock
code[flock](Tatsuo)
TYPES
* -Add BIT, BIT VARYING
* -Allow pg_descriptions when creating tables
* -Allow pg_descriptions when creating types, columns, and functions
* -Allow LOCALE to use indexes in regular expression searches(Tom)
* -Allow array on int8[](Thomas)
* -Add index on NUMERIC/DECIMAL type(Jan)
* -Make Absolutetime/Relativetime int4 because time_t can be int8 on some
ports
* -Make type equivalency apply to aggregates
INDEXES
* -Permissions on indexes, prevent them(Peter E)
* -Allow indexing of LIKE with localle character sets
* -Allow indexing of more than eight columns
COMMANDS
* -Add ALTER TABLE DROP/ALTER COLUMN feature(Peter E)
* -Move LIKE index optimization handling to the optimizer(Tom)
CLIENTS
* -Allow flag to control COPY input/output of NULLs
* -Allow psql \copy to allow delimiters
* -Add a function to return the last inserted oid, for use in psql
scripts (Peter E)
* -Allow psql to print nulls as distinct from "" [null]
MISC
* -Certain indexes will not shrink, i.e. oid indexes with many
inserts(Vadim)
* -Allow WHERE restriction on ctid(Hiroshi)
* -Allow PQrequestCancel() to terminate when in waiting-for-lock state
* -Allow subqueries in target list(Tom)
* -Document/trigger/rule so changes to pgshadow recreate pgpwd
[pg_shadow]
* -Overhaul mdmgr/smgr to fix double unlinking and double opens, cleanup
* -Add PL/Perl(Mark Hollomon)
* -Add option for postgres user have a password by default(Peter E)
PERFORMANCE
FSYNC
* -Prevent fsync in SELECT-only queries(Vadim)
INDEXES
* -Convert function(constant) into a constant for index use(Bernard
Frankpitt)
* -Make index creation use psort code, because it is now faster(Tom)
* -Allow creation of sort temp tables > 1 Gig
* -Create more system table indexes for faster cache lookups
* -fix indexscan() so it does leak memory by not requiring caller to
free(Tom)
* -Improve btbinsrch() to handle equal keys better, remove
btfirsteq()(Tom)
* -Allow optimizer to prefer plans that match ORDER BY(Tom)
CACHE
* -elog() flushes cache, try invalidating just entries from current xact,
perhaps using invalidation cache
MISC
* -Fix memory exhaustion when using many OR's [cnfify](Tom)
* -Process const = const parts of OR clause in separate pass(Bernard
Frankpitt)
* -fix memory leak in cache code when non-existant table is referenced In
WHERE tab1.x=3 AND tab1.x=tab2.y, add tab2.y=3
* -pass atttypmod through parser in more cases [atttypmod]
* -remove duplicate type in/out functions for disk and net
SOURCE CODE
* -Add needed includes and removed unneeded include files(Bruce)
* -Make configure --enable-debug add -g on compile line
* -Pre-generate lex and yacc output so not required for install
==================================================
On Mon, 21 Feb 2000, Tom Lane wrote:
Don Baccus <dhogaza@pacifier.com> writes:
Think we'll have to
leave it unfixed till Thomas gets back.That would be plenty of time to get it in for the real 7.0 release.
I don't like shipping betas with broken pg_dump; that makes life
unreasonably difficult for beta testers, if we have to force another
initdb before release. So I put in a quick hack solution: don't print
the column alias list at all unless there is a table alias. This makes
the rule's FROM clause conform to ANSI syntax. If you actually did
write
create view foo as SELECT alias FROM table table (alias);
then it will dump as
create view foo as SELECT table.realcolname AS alias FROM table;
but there's no harm done. Better solution needed but I'll let Thomas
provide it.And now, it's 4:30 PM AST and we are outta here ... right Marc?
regards, tom lane
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Feb 21 19:39:02 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA36215
for <pgsql-hackers@postgresql.org>;
Mon, 21 Feb 2000 19:38:31 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id QAA18145;
Mon, 21 Feb 2000 16:37:09 -0800 (PST)
Message-Id: <3.0.1.32.20000221162853.01091a70@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 21 Feb 2000 16:28:53 -0800
To: Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Numeric with '-'
Cc: bhirt@mobygames.com, Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgresql.org>
In-Reply-To: <Pine.LNX.4.21.0002220031170.349-100000@localhost.localdoma
in>
References: <2016.951123651@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 12:57 AM 2/22/00 +0100, Peter Eisentraut wrote:
Has the ranting resulted in any idea yet? ISTM that keeping a non-integer
number as a string all the way to the executor shouldn't hurt too much.
After all, according to SQL 123.45 *is* a NUMERIC literal! By making it a
float we're making our users liable to breaking all kinds of fiscal
regulations in some places. (Ask Jan.)
Certainly there was a time in the past, at least, where cross-compilers
frequently did something along these lines, if they were designed
to support a variety of target architectures. Not so common now in the
compiler world since typically host and target both support IEEE
standard floating point operations, but 'twas so back in the days before
the standard existed and before hardware implementations proliferated.
It wouldn't impact the performance of query parsing and analysis noticably.
You have to take care when (for instance) folding operations on
constants - I suspect that somewhere in the 50K lines of the SQL92
draft or the 83K lines of the SQL3 draft precise rules for such
things are laid down. Though probably in an incomprehensible fashion!
Speaking of 'unknown', this is my favourite brain-damaged query of all
times:peter=> select 'a' like 'a';
ERROR: Unable to identify an operator '~~' for types 'unknown' and 'unknown'
You will have to retype this query using an explicit cast
That *is* very cool! :) Postgres is an amazing beast at times!
- 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 Feb 21 19:39:03 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA36132;
Mon, 21 Feb 2000 19:38:21 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id QAA18200;
Mon, 21 Feb 2000 16:37:17 -0800 (PST)
Message-Id: <3.0.1.32.20000221163448.010940d0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 21 Feb 2000 16:34:48 -0800
To: The Hermit Hacker <scrappy@hub.org>, Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
Cc: webmaster@postgresql.org, pgsql-hackers@postgresql.org
In-Reply-To: <Pine.BSF.4.21.0002211952550.86931-100000@thelab.hub.org>
References: <29004.951164832@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 07:57 PM 2/21/00 -0400, The Hermit Hacker wrote:
* -Add referential integrity(Jan)[primary]
This is only PARTIALLY complete:
MATCH FULL and MATCH <unspecified> foreign keys and their related
referential actions are complete. MATCH PARTIAL isn't in - I'll be
doing that for 7.1.
It doesn't check that the columns referenced in a foreign key
form a primary key or are contrained by UNIQUE in the referenced
table. This will be checked in 7.1, not sure who will do it (who
ever gets to it first, probably).
Those are the two major user-visible loose ends with this feature.
- 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 Feb 21 19:56: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 TAA43490;
Mon, 21 Feb 2000 19:55: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
TAA19367;
Mon, 21 Feb 2000 19:53:39 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002220053.TAA19367@candle.pha.pa.us>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <Pine.BSF.4.21.0002211952550.86931-100000@thelab.hub.org> from
The
Hermit Hacker at "Feb 21, 2000 07:57:56 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Mon, 21 Feb 2000 19:53:39 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, webmaster@postgreSQL.org,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Should be accurate. I usually make a release list after the feature
freeze/beta starts.
Working on the Release Announcement now ... Bruce, how accurate is the
current TODO list? If I go through it looking for all items marked as
'-', I come up with the following list. Is it missing anything? I know
not *everything* has to be listed, so I'm more afraid of listing something
that shouldn't then not listing enough ...The beta1.tar.gz snapshot has been created ... I'll put out an
announcement later tonight once I've heard back on this list, which also
gives some of the mirror sites a chance to sync up, and Vince a chance to
update the web site...=============================================
RELIABILITYRESOURCES
* -Disallow inherited columns with the same name as new columns
* -Elog() does not free all its memory
* -spinlock stuck problem when elog(FATAL) and elog(ERROR) inside bufmgr
* -Recover or force failure when disk space is exhausted(Hiroshi)PARSER
* -INSERT INTO ... SELECT with AS columns matching result columns problem
* -Select a[1] FROM test fails, it needs test.a[1](Tom)
* -Array index references without table name cause problems [array](Tom)
* -INSERT ... SELECT ... GROUP BY groups by target columns not source
columns(Tom)
* -CREATE TABLE test (a char(5) DEFAULT text '', b int4) fails on
INSERT(Tom)
* -UNION with LIMIT fails
* -CREATE TABLE x AS SELECT 1 UNION SELECT 2 fails
* -CREATE TABLE test(col char(2) DEFAULT user) fails in length
restriction
* -mismatched types in CREATE TABLE ... DEFAULT causes problems [default]
* -SELECT ... UNION ... ORDER BY fails when sort expr not in result list,
ORDER BY is applied only to the first SELECT
* -select * from pg_class where oid in (0,-1)
* -prevent primary key that exceeds max index columns [primary]
* -SELECT COUNT('asdf') FROM pg_class WHERE oid=12 crashes
* -require SELECT DISTINCT target list to have all ORDER BY columns
* -When using aggregates + GROUP BY, no rows in should yield no rows
out(Tom)
* -Allow HAVING to use comparisons that have no aggregates(Tom)
* -Allow COUNT(DISTINCT col))(TOm)VIEWS
* -Views with spaces in view name fail when referenced
MISC
* -User who can create databases can modify pg_database table(Peter E)
* -Fix btree to give a useful elog when key > 1/2 (page - overhead)(Tom)
* -pg_dump should preserve primary key information
* -database names with spaces fail
* -insert of 0.0 into DECIMAL(4,4) field fails(Tom)
* -* Interlock to prevent DROP DATABASE on a database with running
backendsInterlock to prevent DROP DATABASE on a database with running
backendsENHANCEMENTS
URGENT
* -Add referential integrity(Jan)[primary]
* -Eliminate limits on query length
* -Fix memory leak for aggregates(Tom)ADMIN
* -Better interface for adding to pg_group(Peter E)
* -Generate postmaster pid file and remove flock/fcntl lock
code[flock](Tatsuo)TYPES
* -Add BIT, BIT VARYING
* -Allow pg_descriptions when creating tables
* -Allow pg_descriptions when creating types, columns, and functions
* -Allow LOCALE to use indexes in regular expression searches(Tom)
* -Allow array on int8[](Thomas)
* -Add index on NUMERIC/DECIMAL type(Jan)
* -Make Absolutetime/Relativetime int4 because time_t can be int8 on some
ports
* -Make type equivalency apply to aggregatesINDEXES
* -Permissions on indexes, prevent them(Peter E)
* -Allow indexing of LIKE with localle character sets
* -Allow indexing of more than eight columnsCOMMANDS
* -Add ALTER TABLE DROP/ALTER COLUMN feature(Peter E)
* -Move LIKE index optimization handling to the optimizer(Tom)CLIENTS
* -Allow flag to control COPY input/output of NULLs
* -Allow psql \copy to allow delimiters
* -Add a function to return the last inserted oid, for use in psql
scripts (Peter E)
* -Allow psql to print nulls as distinct from "" [null]MISC
* -Certain indexes will not shrink, i.e. oid indexes with many
inserts(Vadim)
* -Allow WHERE restriction on ctid(Hiroshi)
* -Allow PQrequestCancel() to terminate when in waiting-for-lock state
* -Allow subqueries in target list(Tom)
* -Document/trigger/rule so changes to pgshadow recreate pgpwd
[pg_shadow]
* -Overhaul mdmgr/smgr to fix double unlinking and double opens, cleanup
* -Add PL/Perl(Mark Hollomon)
* -Add option for postgres user have a password by default(Peter E)PERFORMANCE
FSYNC
* -Prevent fsync in SELECT-only queries(Vadim)
INDEXES
* -Convert function(constant) into a constant for index use(Bernard
Frankpitt)
* -Make index creation use psort code, because it is now faster(Tom)
* -Allow creation of sort temp tables > 1 Gig
* -Create more system table indexes for faster cache lookups
* -fix indexscan() so it does leak memory by not requiring caller to
free(Tom)
* -Improve btbinsrch() to handle equal keys better, remove
btfirsteq()(Tom)
* -Allow optimizer to prefer plans that match ORDER BY(Tom)CACHE
* -elog() flushes cache, try invalidating just entries from current xact,
perhaps using invalidation cacheMISC
* -Fix memory exhaustion when using many OR's [cnfify](Tom)
* -Process const = const parts of OR clause in separate pass(Bernard
Frankpitt)
* -fix memory leak in cache code when non-existant table is referenced In
WHERE tab1.x=3 AND tab1.x=tab2.y, add tab2.y=3
* -pass atttypmod through parser in more cases [atttypmod]
* -remove duplicate type in/out functions for disk and netSOURCE CODE
* -Add needed includes and removed unneeded include files(Bruce)
* -Make configure --enable-debug add -g on compile line
* -Pre-generate lex and yacc output so not required for install==================================================
On Mon, 21 Feb 2000, Tom Lane wrote:Don Baccus <dhogaza@pacifier.com> writes:
Think we'll have to
leave it unfixed till Thomas gets back.That would be plenty of time to get it in for the real 7.0 release.
I don't like shipping betas with broken pg_dump; that makes life
unreasonably difficult for beta testers, if we have to force another
initdb before release. So I put in a quick hack solution: don't print
the column alias list at all unless there is a table alias. This makes
the rule's FROM clause conform to ANSI syntax. If you actually did
write
create view foo as SELECT alias FROM table table (alias);
then it will dump as
create view foo as SELECT table.realcolname AS alias FROM table;
but there's no harm done. Better solution needed but I'll let Thomas
provide it.And now, it's 4:30 PM AST and we are outta here ... right Marc?
regards, tom lane
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org************
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 21 20:00: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 TAA44205;
Mon, 21 Feb 2000 19:59:36 -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
TAA19649;
Mon, 21 Feb 2000 19:57:36 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002220057.TAA19649@candle.pha.pa.us>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <3.0.1.32.20000221163448.010940d0@mail.pacifier.com> from Don
Baccus at "Feb 21, 2000 04:34:48 pm"
To: Don Baccus <dhogaza@pacifier.com>
Date: Mon, 21 Feb 2000 19:57:36 -0500 (EST)
CC: The Hermit Hacker <scrappy@hub.org>, Tom Lane <tgl@sss.pgh.pa.us>,
webmaster@postgreSQL.org, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
At 07:57 PM 2/21/00 -0400, The Hermit Hacker wrote:
* -Add referential integrity(Jan)[primary]
This is only PARTIALLY complete:
MATCH FULL and MATCH <unspecified> foreign keys and their related
referential actions are complete. MATCH PARTIAL isn't in - I'll be
doing that for 7.1.
Added to TODO.
It doesn't check that the columns referenced in a foreign key
form a primary key or are contrained by UNIQUE in the referenced
table. This will be checked in 7.1, not sure who will do it (who
ever gets to it first, probably).
Added.
* Foreign key does not check that columns referenced form a primary key
or constrained by UNIQUE
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 21 20:09:02 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 UAA46333
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 20:08:31 -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 KAA00048; Tue, 22 Feb 2000 10:07:44 +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] Numeric with '-'
Date: Tue, 22 Feb 2000 10:13:57 +0900
Message-ID: <000001bf7cd2$17e01100$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: <27928.951162722@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
The following phenomenon was reported to pgsql-jp(ML in Japan).
rest=# select -1234567890.1234567;
ERROR: Unable to convert left operator '-' from type 'unknown'I've committed fixes that make the parser treat numeric literals
the same no matter how many digits they have. With current sources,regression=# select -1234567890.1234567;
?column?
-------------------
-1234567890.12346
(1 row)which is probably still not what you want,
Hmm,this may be worse than before.
INSERT/UPDATE statements would lose precision without
telling any error/warnings.
because the default
type for a non-integer literal is float8 in the absence of any
context to clue the system otherwise, so you lose precision.
You can do
Shouldn't decimal constants be distinguished from real constants ?
For example, decimal --> NCONST -> T_Numreic Value ->
Const node of type NUMERICOID ....
Comments ?
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Mon Feb 21 20:43:03 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA53723
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 20:42:19 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id KAA11066;
Tue, 22 Feb 2000 10:42:11 +0900 (JST)
Received: from localhost (IDENT:t-ishii@srapc968-yotsuya [133.137.36.133])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id KAA02816;
Tue, 22 Feb 2000 10:42:11 +0900
To: lockhart@alumni.caltech.edu
Cc: t-ishii@sra.co.jp, peter_e@gmx.net, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_ctl man page
In-Reply-To: <389FBBFA.F57E3FCF@alumni.caltech.edu>
References: <Pine.LNX.4.21.0002072051550.6572-100000@localhost.localdomain>
<20000208105126W.t-ishii@sra.co.jp>
<389FBBFA.F57E3FCF@alumni.caltech.edu>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Message-Id: <20000222104757U.t-ishii@sra.co.jp>
Date: Tue, 22 Feb 2000 10:47:57 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 138
Beta testing is about to start, but I have not heard from Vadim what
he thinks about "smart" etc yet. Time is up... So I decided to keep
the options of pg_ctl as it is for coming 7.0.
P.S. I have reverted back "-smart" to "-m smart" as Peter and Thomas
suggested. If I have spare time, I would add "---" style options as
well. My first priority is fixing bugs and writing documentaions about
the multibyte support...
--
Tatsuo Ishii
-------------------------------------------------------------------
NAME
pg_ctl - starts/stops/restarts postmaster
SYNOPSIS
pg_ctl [-w][-D database_dir][-p path_to_postmaster][-o "postmaster_opts"] start
pg_ctl [-w][-D database_dir][-m [s[mart]|f[ast]|i[mmediate]]] stop
pg_ctl [-w][-D database_dir][-m [s[mart]|f[ast]|i[mmediate]][-o "postmaster_opts"] restart
pg_ctl [-D database_dir] status
DESCRIPTION
pg_ctl is a utility for starting, stopping or restarting postmaster.
Starting postmaster
To start postmaster:
pg_ctl start
If -w is supplied, pg_ctl waits for the database server comes up, by
watching for creation of the pid file (PGDATA/postmaster.pid), for up
to 60 seconds.
Parameters to invoke postmaster are taken from following sources:
Path to postmaster: found in the command search path
Database directory: PGDATA environment variable
Other parameters: PGDATA/postmaster.opts.default
postmaster.opts.default contains parameters for postmaster. With a
default installation, the "-S" option is enabled. So "pg_ctl start"
implies:
postmaster -S
Note that postmaster.opts.default is installed by initdb from
lib/postmaster.opts.default.sample under the PostgreSQL installation
directory (lib/postmaster.opts.default.sample is copied from
src/bin/pg_ctl/postmaster.opts.default.sample while installing
PostgreSQL).
To override default parameters you can use -D, -p and -o options.
-D database_dir
specifies the database directory
-p path_to_postmaster
specifies the path to postmaster
-o "postmaster_opts"
specifies any parameters for postmaster
Examples:
# blocks until postmaster comes up
pg_ctl -w start
# specifies postmaster path
pg_ctl -p /usr/local/pgsq/bin/postmaster start
# uses port 5433 and disables fsync
pg_ctl -o "-o -F -p 5433" start
Stopping postmaster
pg_ctl stop
stops postmaster.
There are several options for the stopping mode.
-w
waits for postmaster to shut down
-m [s[mart]|f[ast]|i[mmediate]]
specifies the shutdown mode. smart mode waits for all
the clients to logout. This is the default.
fast mode sends SIGTERM to the backends, that means
active transactions get rolled back. immediate mode sends SIGUSR1
to the backends and lets them abort. In this case, database recovery
will be neccessary on the next startup.
Restarting postmaster
This is almost equivalent to stopping postmaster then starting it
again except that the parameters for postmaster used before stopping
it would be used too. This is done by saving them in
PGDATA/postmaster.opts file. -w, -D, -m, -fast, -immediate and -o
can also be used in the restarting mode and they have same meanings as
described above.
Examples:
# restarts postmaster in the simplest form
pg_ctl restart
# restarts postmaster, waiting for it to shut down and to come up
pg_ctl -w restart
# uses port 5433 and disables fsync next time
pg_ctl -o "-o -F -p 5433" restart
Getting status from postmaster
To get status information from postmaster:
pg_ctl status
Following is sample outputs from pg_ctl.
pg_ctl: postmaster is running (pid: 13718)
options are:
/usr/local/src/pgsql/current/bin/postmaster
-p 5433
-D /usr/local/src/pgsql/current/data
-B 64
-b /usr/local/src/pgsql/current/bin/postgres
-N 32
-o '-F'
************
************
From bouncefilter Mon Feb 21 22:36: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 WAA78624
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 22:35:06 -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 WAA21720;
Mon, 21 Feb 2000 22:34:56 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Numeric with '-'
In-reply-to: <000001bf7cd2$17e01100$2801007e@tpf.co.jp>
References: <000001bf7cd2$17e01100$2801007e@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Tue, 22 Feb 2000 10:13:57 +0900"
Date: Mon, 21 Feb 2000 22:34:56 -0500
Message-ID: <21717.951190496@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
Hmm,this may be worse than before.
INSERT/UPDATE statements would lose precision without
telling any error/warnings.
They didn't give any such warning before, either. I doubt I've
made anything worse.
Shouldn't decimal constants be distinguished from real constants ?
Why? I don't see any particularly good reason for distinguishing
1234567890.1234567890 from 1.2345678901234567890e9. (numeric_in
does accept both these days, BTW.)
regards, tom lane
From bouncefilter Mon Feb 21 22:57: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 WAA82348
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 22:56:42 -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 WAA22064;
Mon, 21 Feb 2000 22:56:34 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error
messages
In-reply-to: <Pine.LNX.4.21.0002220023260.349-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0002220023260.349-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Tue, 22 Feb 2000 00:57:23 +0100"
Date: Mon, 21 Feb 2000 22:56:34 -0500
Message-ID: <22061.951191794@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
On 2000-02-20, Tom Lane mentioned:
I would not like us to stop working
with non-bison yaccs, since bison's output depends on alloca() which
is not available everywhere.
Couldn't alloca(x) be defined to palloc(x) where missing?
Probably, but I wasn't looking for a workaround; that was just one
quick illustration of a reason not to want to use bison (one that's
bitten me personally, so I knew it offhand). We should try not to
become dependent on bison when there are near-equivalent tools, just
on general principles of maintaining portability. For an analogy,
I believe most of the developers use gcc, but it would be a real bad
idea for us to abandon support for other compilers.
For the same sort of reasons I'd prefer that our scanner worked
with vanilla lex, not just flex. I'm not sure how far away we are
from that; it may be an unrealistic goal. But if it is within reach
then we shouldn't give it up lightly.
regards, tom lane
From bouncefilter Mon Feb 21 22:52:04 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 WAA81472
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 22:51:31 -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 MAA00118; Tue, 22 Feb 2000 12:51:26 +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] Numeric with '-'
Date: Tue, 22 Feb 2000 12:57:41 +0900
Message-ID: <000301bf7ce8$f77bb600$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: <21717.951190496@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
Hmm,this may be worse than before.
INSERT/UPDATE statements would lose precision without
telling any error/warnings.They didn't give any such warning before, either. I doubt I've
made anything worse.
Before your change
INSERT into t (numdata) values (-1234567890.1234567);
caused an error
ERROR: Unable to convert left operator '-' from type 'unknown'.
but currently inserts a constant -1234567890.12346.
and
INSERT into t (numdata) values (1234567890.1234567);
inserted a numeric constant 1234567890.1234567 precisely
but currently inserts a constant 1234567890.12346.
Shouldn't decimal constants be distinguished from real constants ?
Why? I don't see any particularly good reason for distinguishing
1234567890.1234567890 from 1.2345678901234567890e9. (numeric_in
does accept both these days, BTW.)
According to a book about SQL92 which I have,SQL92 seems to
recommend it.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Mon Feb 21 23:06: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 XAA84985
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 23:05:58 -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 XAA22125;
Mon, 21 Feb 2000 23:05:49 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: bhirt@mobygames.com, Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Numeric with '-'
In-reply-to: <Pine.LNX.4.21.0002220031170.349-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0002220031170.349-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Tue, 22 Feb 2000 00:57:34 +0100"
Date: Mon, 21 Feb 2000 23:05:49 -0500
Message-ID: <22122.951192349@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
On 2000-02-21, Tom Lane mentioned:
I've been ranting about this in a recent pghackers thread ;-).
The lexer shouldn't have to commit to a conversion to float8
in order to report that a token looks like a numeric literal.
Has the ranting resulted in any idea yet? ISTM that keeping a non-integer
number as a string all the way to the executor shouldn't hurt too much.
Well, actually it's sufficient to keep it as a string until the type
analyzer has figured out what data type it's supposed to be; then you
can feed it to that type's typinput conversion routine. After that
it's not the parser's problem anymore ;-).
I committed changes to do exactly that this morning. Thomas had been
saying that integer literals should be kept as strings too, but I don't
believe that and didn't do it.
peter=> select 'a' like 'a';
ERROR: Unable to identify an operator '~~' for types 'unknown' and 'unknown'
You will have to retype this query using an explicit cast
Is there a good reason that a character literal is unknown? I'm sure the
reasons lie somewhere in the extensible type system, but if I wanted it to
be something else explicitly then I would have written DATE 'yesterday'.
Remember that constants of random types like "line segment" have to
start out as character literals (unless you want to try to pass them
through the lexer and parser undamaged without quotes). So untyped
character literal has to be a pretty generic thing. It might be a good
idea for the type analyzer to try again with the assumption that the
literal is supposed to be type text, if it fails to find an
interpretation without that assumption --- but I think this is a
ticklish change that could have unwanted consequences. It'd need
some close examination.
regards, tom lane
From bouncefilter Mon Feb 21 23:33:05 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 XAA90682
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 23:32: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
XAA23843;
Mon, 21 Feb 2000 23:08:26 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002220408.XAA23843@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error
messages
In-Reply-To: <22061.951191794@sss.pgh.pa.us> from Tom Lane at "Feb 21,
2000 10:56:34 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 21 Feb 2000 23:08:26 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Peter Eisentraut <peter_e@gmx.net> writes:
On 2000-02-20, Tom Lane mentioned:
I would not like us to stop working
with non-bison yaccs, since bison's output depends on alloca() which
is not available everywhere.Couldn't alloca(x) be defined to palloc(x) where missing?
Probably, but I wasn't looking for a workaround; that was just one
quick illustration of a reason not to want to use bison (one that's
bitten me personally, so I knew it offhand). We should try not to
become dependent on bison when there are near-equivalent tools, just
on general principles of maintaining portability. For an analogy,
I believe most of the developers use gcc, but it would be a real bad
idea for us to abandon support for other compilers.
But I don't see non-bison solutions for finding the location of errors.
Is it possible? Could we enable the feature just for bison?
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 21 23:20:05 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 XAA88181
for <pgsql-hackers@postgresql.org>;
Mon, 21 Feb 2000 23:19:44 -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 XAA22191;
Mon, 21 Feb 2000 23:19:29 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: Hannu Krosing <hannu@tm.ee>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: SQL compliance - why -- comments only at psql
level?
In-reply-to: <Pine.LNX.4.21.0002220002360.349-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0002220002360.349-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Tue, 22 Feb 2000 00:57:12 +0100"
Date: Mon, 21 Feb 2000 23:19:28 -0500
Message-ID: <22188.951193168@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
On 2000-02-20, Tom Lane mentioned:
select *-- 123
ERROR: Can't find left op '*--' for type 23
I believe that these things (certainly the first one) could be fixed by
making the {operator} rule in scan.l rescanning yytext for "--" or "/*"
(using string functions) and if found putting part of the token back in
the input stream using yyless().
I think you are right, that would work. Is yyless flex-specific or a
generic lex feature?
The intermediate-lookahead-buffer solution might still be better, if it
lets us solve more problems than just this one. I'm inclined to not
do anything until Thomas decides what he wants to do about the NOT NULL
business.
but <<EOF>> is a flex-ism not supported by regular lex.
Exclusive start conditions are not supported by regular lex either.
Oooh, somehow I managed to completely miss that statement in the flex
manual, but you are right. Hmm. I think that shoots a gaping hole in
my desire to have scan.l work with plain lex. Offhand I don't see a
good way to avoid using exclusive start conditions for multi-section
literals.
If you want to catch unbalanced quotes at the end of input, I could
imagine that some grand unified evilness via yywrap setting some global
flag or two might get the job done.
Right at the moment I'm thinking we might as well use <<EOF>>, which
is after all the recommended way of doing it.
regards, tom lane
From bouncefilter Mon Feb 21 23:46:05 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA93522;
Mon, 21 Feb 2000 23:45:50 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id NAA23733;
Tue, 22 Feb 2000 13:45:40 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id NAA06241;
Tue, 22 Feb 2000 13:45:39 +0900
To: dhogaza@pacifier.com
Cc: scrappy@hub.org, tgl@sss.pgh.pa.us, webmaster@postgreSQL.org,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: Your message of "Mon, 21 Feb 2000 16:34:48 -0800"
<3.0.1.32.20000221163448.010940d0@mail.pacifier.com>
References: <3.0.1.32.20000221163448.010940d0@mail.pacifier.com>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000222134539N.t-ishii@sra.co.jp>
Date: Tue, 22 Feb 2000 13:45:39 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 25
At 07:57 PM 2/21/00 -0400, The Hermit Hacker wrote:
* -Add referential integrity(Jan)[primary]
This is only PARTIALLY complete:
MATCH FULL and MATCH <unspecified> foreign keys and their related
referential actions are complete. MATCH PARTIAL isn't in - I'll be
doing that for 7.1.It doesn't check that the columns referenced in a foreign key
form a primary key or are contrained by UNIQUE in the referenced
table. This will be checked in 7.1, not sure who will do it (who
ever gets to it first, probably).Those are the two major user-visible loose ends with this feature.
What about ALTER TABLE table DROP CONSTRAINT? I see this:
alter table t1 drop constraint t1_fk cascade;
ERROR: ALTER TABLE / DROP CONSTRAINT is not implemented
Note that we seem to have ALTER TABLE table ADD CONSTRAINT, though.
--
Tatsuo Ishii
From bouncefilter Mon Feb 21 23:54:05 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 XAA95561
for <pgsql-hackers@postgreSQL.org>;
Mon, 21 Feb 2000 23:53:14 -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 XAA22278;
Mon, 21 Feb 2000 23:53:09 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Numeric with '-'
In-reply-to: <000301bf7ce8$f77bb600$2801007e@tpf.co.jp>
References: <000301bf7ce8$f77bb600$2801007e@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Tue, 22 Feb 2000 12:57:41 +0900"
Date: Mon, 21 Feb 2000 23:53:09 -0500
Message-ID: <22275.951195189@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
They didn't give any such warning before, either. I doubt I've
made anything worse.
Before your change
INSERT into t (numdata) values (-1234567890.1234567);
caused an error
ERROR: Unable to convert left operator '-' from type 'unknown'.
but currently inserts a constant -1234567890.12346.
Yipes, you are right. I think that that sort of construct should
result in the value not getting converted at all until the parser
knows that it must be converted to the destination column's type.
Let me see if I can find out what's going wrong. If this doesn't
seem to be fixable, I may have to back off the patch...
regards, tom lane
From bouncefilter Tue Feb 22 00:26:06 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA03481
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 00:25:21 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id VAA01450;
Mon, 21 Feb 2000 21:24:44 -0800 (PST)
Message-Id: <3.0.1.32.20000221210551.0108e130@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 21 Feb 2000 21:05:51 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: [PATCHES] Patch for more readable parse
error messages
Cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <22061.951191794@sss.pgh.pa.us>
References: <Pine.LNX.4.21.0002220023260.349-100000@localhost.localdomain>
<Pine.LNX.4.21.0002220023260.349-100000@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 10:56 PM 2/21/00 -0500, Tom Lane wrote:
Probably, but I wasn't looking for a workaround; that was just one
quick illustration of a reason not to want to use bison (one that's
bitten me personally, so I knew it offhand). We should try not to
become dependent on bison when there are near-equivalent tools, just
on general principles of maintaining portability. For an analogy,
I believe most of the developers use gcc, but it would be a real bad
idea for us to abandon support for other compilers.For the same sort of reasons I'd prefer that our scanner worked
with vanilla lex, not just flex. I'm not sure how far away we are
from that; it may be an unrealistic goal. But if it is within reach
then we shouldn't give it up lightly.
I agree entirely with the above. The more portable the tool, the larger
the potential user base. Unless the goal is to bundle-up Postgres with
a pre-defined set of software, i.e. GNU in this case (despite the fact
that I don't see Postgres on their site as part of their list of open-source
software, and I think I looked twice), go for the cover-the-earth approach.
SQL syntax isn't particularly difficult. On the other hand, I realize there's
a legacy to support. Still, making portions of the product dependent on one
tool or another is an issue that merits close scrutiny. Shouldn't be done
except under compelling reasons.
I mean, presuming a reasonably modern C, C tools, and large-scale
operating-system environment makes sense (no reason to run native on a palm
pilot,
at this point). But unecessary dependence on particular tools when not
necessary doesn't make much sense.
Just IMO, 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 Tue Feb 22 00:11:12 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 AAA00427;
Tue, 22 Feb 2000 00:10: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
AAA27880;
Tue, 22 Feb 2000 00:09:11 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002220509.AAA27880@candle.pha.pa.us>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <20000222134539N.t-ishii@sra.co.jp> from Tatsuo Ishii at "Feb 22,
2000 01:45:39 pm"
To: Tatsuo Ishii <t-ishii@sra.co.jp>
Date: Tue, 22 Feb 2000 00:09:11 -0500 (EST)
CC: dhogaza@pacifier.com, scrappy@hub.org, tgl@sss.pgh.pa.us,
webmaster@postgreSQL.org, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Those are the two major user-visible loose ends with this feature.
What about ALTER TABLE table DROP CONSTRAINT? I see this:
alter table t1 drop constraint t1_fk cascade;
ERROR: ALTER TABLE / DROP CONSTRAINT is not implementedNote that we seem to have ALTER TABLE table ADD CONSTRAINT, though.
I thought that was going in. According to Marc, if it sufficiently
warned users, and required them to type it twice, it would do Peter's
alter table code. Perhaps Peter decided to wait for 7.1?
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 22 00:26:06 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA03483;
Tue, 22 Feb 2000 00:25:23 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id VAA01458;
Mon, 21 Feb 2000 21:24:46 -0800 (PST)
Message-Id: <3.0.1.32.20000221211505.007a7d10@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 21 Feb 2000 21:15:05 -0800
To: Tatsuo Ishii <t-ishii@sra.co.jp>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
Cc: scrappy@hub.org, tgl@sss.pgh.pa.us, webmaster@postgreSQL.org,
pgsql-hackers@postgreSQL.org
In-Reply-To: <20000222134539N.t-ishii@sra.co.jp>
References: <Your message of "Mon, 21 Feb 2000 16:34:48
-0800"<3.0.1.32.20000221163448.010940d0@mail.pacifier.com>
<3.0.1.32.20000221163448.010940d0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 01:45 PM 2/22/00 +0900, Tatsuo Ishii wrote:
Those are the two major user-visible loose ends with this feature.
What about ALTER TABLE table DROP CONSTRAINT? I see this:
alter table t1 drop constraint t1_fk cascade;
ERROR: ALTER TABLE / DROP CONSTRAINT is not implementedNote that we seem to have ALTER TABLE table ADD CONSTRAINT, though.
"ALTER TABLE ... DROP CONSTRAINT" I view as being a more general
problem not simply restricted to referential integrity. My comment
was meant to be strictly interpreted within the realm of RI. Obviously,
general dropping of columns and constraints needs to be solved, but these
aren't RI issues specifically.
And, no, you don't have ALTER TABLE ... ADD CONSTRAINT. What you have
is the ability to add foreign key constraints only. When this was
added, we (Stephan Szabo, myself, and Jan Wieck) discussed doing
general constraints, too, but Jan pointed out that we were all busy
with RI-specific stuff and that we should concentrate on those issue.
A good call, IMO, as I was buried in trying to understand "NO ACTION"
and "MATCH <unspecified>" at the same; Stephan was working on pg_dump;
and Jan was really busy with his real job. I only had one weekend to
pour into implementing the proper semantics for the RI triggers, and
as a result of our decision to concentrate on RI-specific issues was
able to complete the necessary work for fully SQL92 compliant "MATCH
<unspecified>" foreign keys.
However, Stephan's ALTER TABLE ... work to allow you to add foreign
keys should be fairly easy to extend to general constraints, he and
Jan discussed this a couple of weeks ago.
7.1 would seem to be the likely target for this.
- 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 Feb 22 00:32:05 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 AAA04883
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 00:31: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 AAA22429;
Tue, 22 Feb 2000 00:31:34 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-reply-to: <200002220509.AAA27880@candle.pha.pa.us>
References: <200002220509.AAA27880@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Tue, 22 Feb 2000 00:09:11 -0500"
Date: Tue, 22 Feb 2000 00:31:34 -0500
Message-ID: <22426.951197494@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
ERROR: ALTER TABLE / DROP CONSTRAINT is not implemented
I thought that was going in. According to Marc, if it sufficiently
warned users, and required them to type it twice, it would do Peter's
alter table code. Perhaps Peter decided to wait for 7.1?
I thought the rest of us beat him up until he took it out ;-)
regards, tom lane
From bouncefilter Tue Feb 22 00:34:06 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA05363;
Tue, 22 Feb 2000 00:34:02 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id OAA27021;
Tue, 22 Feb 2000 14:34:00 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id OAA07201;
Tue, 22 Feb 2000 14:33:59 +0900
To: dhogaza@pacifier.com
Cc: scrappy@hub.org, tgl@sss.pgh.pa.us, webmaster@postgreSQL.org,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: Your message of "Mon, 21 Feb 2000 21:15:05 -0800"
<3.0.1.32.20000221211505.007a7d10@mail.pacifier.com>
References: <3.0.1.32.20000221211505.007a7d10@mail.pacifier.com>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000222143359C.t-ishii@sra.co.jp>
Date: Tue, 22 Feb 2000 14:33:59 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 15
"ALTER TABLE ... DROP CONSTRAINT" I view as being a more general
problem not simply restricted to referential integrity. My comment
was meant to be strictly interpreted within the realm of RI. Obviously,
general dropping of columns and constraints needs to be solved, but these
aren't RI issues specifically.
That's ok, as long as stated somewhere in TODO or whatever.
And, no, you don't have ALTER TABLE ... ADD CONSTRAINT. What you have
is the ability to add foreign key constraints only. When this was
This is more than ok:-) Since without ADD CONSTRAINTS, we could not
define a circular referential integrity at all. Good job!
--
Tatsuo Ishii
From bouncefilter Tue Feb 22 00:49:06 2000
Received: from tycho.webline.dk (needles@[194.255.48.20])
by hub.org (8.9.3/8.9.3) with SMTP id AAA08557
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 00:48:55 -0500 (EST) (envelope-from kar@webline.dk)
Received: (qmail 11789 invoked from network); 22 Feb 2000 05:48:51 -0000
Received: from 33.ppp3-3.image.dk (HELO bohr.webline.dk) (root@212.54.82.33)
by tycho.webline.dk with SMTP; 22 Feb 2000 05:48:51 -0000
Received: from bering (kar@bering.webline.dk [192.168.1.10])
by bohr.webline.dk (8.9.3/8.8.8) with SMTP id GAA09475
for <pgsql-hackers@postgreSQL.org>; Tue, 22 Feb 2000 06:48:57 +0100
From: Kaare Rasmussen <kar@webline.dk>
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO list / why 7.0 ?
Date: Tue, 22 Feb 2000 06:40:25 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <200002211757.MAA07106@candle.pha.pa.us>
<00022121082604.00287@bering> <29560.951171675@sss.pgh.pa.us>
In-Reply-To: <29560.951171675@sss.pgh.pa.us>
MIME-Version: 1.0
Message-Id: <00022206444508.00287@bering>
Content-Transfer-Encoding: 8bit
A number of people thought 6.5 should have been called 7.0 because of
MVCC. A number of other people thought that this release should be 6.6,
You know, I actually woke in the middle of the night and said to myself, Why
did you call MVCC for MSVC. My only answer is that it was late, after a 16
hours work day.
and the next one (which should have outer joins and much better VIEWs
thanks to a redesigned querytree representation) should be 7.0.
Can't wait for this one. If you throw large objects in also, let's go straight
to 8.0 :-)
OTOH, if you look less at bullet points on a feature list and more at
reliability and quality of implementation, there's plenty of material
I didn't try to pick on the development or the state of PostgreSQL. I'm
impressed with the current speed of development and also the number of new
people joining in (you, Peter Eisentraut, maybe more) that relatively easy
understands and becomes productive.
From bouncefilter Tue Feb 22 00:45:06 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 AAA07736
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 00:44: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
AAA29726;
Tue, 22 Feb 2000 00:43:37 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002220543.AAA29726@candle.pha.pa.us>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <22426.951197494@sss.pgh.pa.us> from Tom Lane at "Feb 22,
2000 00:31:34 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 22 Feb 2000 00:43:37 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian <pgman@candle.pha.pa.us> writes:
ERROR: ALTER TABLE / DROP CONSTRAINT is not implemented
I thought that was going in. According to Marc, if it sufficiently
warned users, and required them to type it twice, it would do Peter's
alter table code. Perhaps Peter decided to wait for 7.1?I thought the rest of us beat him up until he took it out ;-)
Yes, he was badly beaten up about it, but I felt that the code as is was
pretty good, considering how bad CLUSTER is. If people are told the
limitations, it could be a win.
I felt that the more advanced features like not using 2x disk space were
quite hard to implement, considering the other TODO items. Marc agreed
and was going to e-mail him to tell him that with proper user warning,
we wanted the patch.
Do people disagree?
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 22 00:54:06 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 AAA09489
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 00:53:38 -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 AAA22575;
Tue, 22 Feb 2000 00:53:31 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-reply-to: <200002220543.AAA29726@candle.pha.pa.us>
References: <200002220543.AAA29726@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Tue, 22 Feb 2000 00:43:37 -0500"
Date: Tue, 22 Feb 2000 00:53:30 -0500
Message-ID: <22572.951198810@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I felt that the more advanced features like not using 2x disk space were
quite hard to implement, considering the other TODO items. Marc agreed
and was going to e-mail him to tell him that with proper user warning,
we wanted the patch.
Do people disagree?
Hmmm ... well ... I really don't want to restart that argument, but
I thought the plurality of opinion was that we didn't want it until
a more complete implementation could be provided.
Certainly I'm not enthused about shoehorning it in *after* we've
gone to feature-freeze mode. If beta means anything around here,
it means "you missed the bus for adding features".
regards, tom lane
From bouncefilter Tue Feb 22 01:33:07 2000
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA18606;
Tue, 22 Feb 2000 01:32:09 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.34.146]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Tue, 22 Feb 2000 00:32:42 -0600
Sender: ed
Message-ID: <38B22DD9.99FFAB3D@austin.rr.com>
Date: Tue, 22 Feb 2000 00:34:01 -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: Don Baccus <dhogaza@pacifier.com>
CC: The Hermit Hacker <scrappy@hub.org>, Tom Lane <tgl@sss.pgh.pa.us>,
webmaster@postgresql.org, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
References: <29004.951164832@sss.pgh.pa.us>
<3.0.1.32.20000221163448.010940d0@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Don Baccus wrote:
At 07:57 PM 2/21/00 -0400, The Hermit Hacker wrote:
* -Add referential integrity(Jan)[primary]
This is only PARTIALLY complete:
MATCH FULL and MATCH <unspecified> foreign keys and their related
referential actions are complete. MATCH PARTIAL isn't in - I'll be
doing that for 7.1.
Can anyone point me to a written description of the expected
functionality (and maybe limitations) provided by this release of RI?
I'm not asking for a definition of RI, but rather the status of
*current* (7.0) pgsql RI functionality, i.e., what one should
expect...
Cheers,
Ed Loehr
From bouncefilter Tue Feb 22 01:58:06 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA23598
for <pgsql-hackers@postgresql.org>;
Tue, 22 Feb 2000 01:57:34 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id PAA03043
for <pgsql-hackers@postgresql.org>;
Tue, 22 Feb 2000 15:57:31 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id PAA14109
for <pgsql-hackers@postgresql.org>; Tue, 22 Feb 2000 15:57:31 +0900
To: pgsql-hackers@postgresql.org
Subject: psql and pager
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000222155730Q.t-ishii@sra.co.jp>
Date: Tue, 22 Feb 2000 15:57:30 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 5
Does anybody know how to disable "pager" of psql? It's really annoying
when I use psql in my emacs's shell buffer...
--
Tatsuo Ishii
From bouncefilter Tue Feb 22 01:58:07 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 BAA23627
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 01:58:02 -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 BAA22799;
Tue, 22 Feb 2000 01:57:40 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-reply-to: <Pine.BSF.4.21.0002211952550.86931-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0002211952550.86931-100000@thelab.hub.org>
Comments: In-reply-to The Hermit Hacker <scrappy@hub.org>
message dated "Mon, 21 Feb 2000 19:57:56 -0400"
Date: Tue, 22 Feb 2000 01:57:40 -0500
Message-ID: <22796.951202660@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
Working on the Release Announcement now ...
* -SELECT ... UNION ... ORDER BY fails when sort expr not in result list,
ORDER BY is applied only to the first SELECT
This is still broken AFAIK. Not sure how it got marked as done.
* -Make type equivalency apply to aggregates
IIRC, Peter should get the credit for that one.
* -Certain indexes will not shrink, i.e. oid indexes with many
inserts(Vadim)
AFAIK that isn't done either.
* -Document/trigger/rule so changes to pgshadow recreate pgpwd
[pg_shadow]
Peter's work also...
* -fix memory leak in cache code when non-existant table is referenced In
WHERE tab1.x=3 AND tab1.x=tab2.y, add tab2.y=3
This looks like 2 items got merged somehow. AFAIK only the first is
done.
Looking at my own notes about completed changes, it sure seems like
there have been one heck of a lot of bugfixes and performance
improvements that don't correspond to anything on the official TODO
list. It might be worth making some opening remarks along that line
rather than just presenting the checked-off items.
regards, tom lane
From bouncefilter Tue Feb 22 05:34:09 2000
Received: from design.nl (lexington.design.nl [193.78.77.101])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA16288
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 05:33:53 -0500 (EST)
(envelope-from jeroen@design.nl)
Received: from benny (ranger.design.nl [212.206.76.159])
by design.nl (General Design 1.1) with ESMTP
id KAA27700; Tue, 22 Feb 2000 10:54:07 +0100 (NLD)
Message-Id: <4.2.2.20000222103948.00ac8d10@mail.design.nl>
X-Sender: jeroenv@mail.design.nl
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Date: Tue, 22 Feb 2000 10:55:13 +0100
To: Peter Eisentraut <peter_e@gmx.net>
From: Jeroen van Vianen <jeroen@design.nl>
Subject: Re: [PATCHES] Patch for more readable parse error messages
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <Pine.LNX.4.21.0002212140410.349-100000@localhost.localdoma
in>
References: <4.2.0.58.20000220151757.00956ba0@mail.design.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 00:56 22-02-00 +0100, Peter Eisentraut wrote:
On 2000-02-20, Jeroen van Vianen mentioned:
The format of the error messages is changed to:
jeroen=# create abc ( a int4, b int4 );
ERROR: parser: parse error at or near "abc":
create abc ( a int4, b int4 )
*I believe this is the wrong approach because it's highly psql specific. If
you use PHP or JDBC or something not character cell based you will get
misleading output.You might want to start thinking about putting a little more information
into an ERROR than just a text string, such as error codes or
supplementary information like this. psql could then choose to print a
star, other interfaces might set the cursor to the specified place, etc.
Much more flexible.
Good idea. As far as I understand things, libpq uses special datastructures
to access the error code and message and it's up to the application (psql,
and others) to do what it wants to do with it (let's say print the error).
These structures might be enhanced with an error location, but this might
be breaking things. And my question is how to do this.
Note that this location part is only filled now when yyerror() throws an
error, but other parts of the backend might use a similar approach. OTOH it
might be nice then to have every token know its location in the query
string (as Don suggested), so you might end up with error messages like:
mydb-> select * from t1, t2 where ...
ERROR: table t2 not found:
select * from t1, t2 where ...
^
(which may be nice, or not).
What I see now is something like this (for psql):
psql sends a query
psql reads response
if response is error
get error location and find context in which error occurred
print error message, with error location and context
otherwise
do what it used to do
and for the other interfaces nothing changes.
This is something I might be able to implement for 7.1.
What do you think?
Jeroen
From bouncefilter Tue Feb 22 05:11:09 2000
Received: from tech.com.au (IDENT:root@techpt.lnk.telstra.net
[139.130.75.122])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA10984
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 05:10:17 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: from bitmead.com (tardis [203.41.180.243])
by tech.com.au (8.9.3/8.9.3) with ESMTP id VAA10598;
Tue, 22 Feb 2000 21:09:56 +1100
Sender: chris@tech.com.au
Message-ID: <38B26073.9EFA1267@bitmead.com>
Date: Tue, 22 Feb 2000 21:09:55 +1100
From: Chris <chris@bitmead.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tatsuo Ishii <t-ishii@sra.co.jp>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] psql and pager
References: <20000222155730Q.t-ishii@sra.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tatsuo Ishii wrote:
Does anybody know how to disable "pager" of psql? It's really annoying
when I use psql in my emacs's shell buffer...
One way is to unset the PAGER environment variable.
--
Chris Bitmead
mailto:chris@bitmead.com
From bouncefilter Tue Feb 22 05:16:09 2000
Received: from feivel.fam-meskes.de (p3E9B98E9.dip0.t-ipconnect.de
[62.155.152.233]) by hub.org (8.9.3/8.9.3) with ESMTP id FAA11975
for <pgsql-hackers@postgresql.org>;
Tue, 22 Feb 2000 05:15:19 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 8C34D2BD59; Tue, 22 Feb 2000 11:10:52 +0100 (CET)
Date: Tue, 22 Feb 2000 11:10:52 +0100
From: Michael Meskes <meskes@postgresql.org>
To: Rafael Jesus Alcantara Perez <rafa@dedalo-ing.com>
Cc: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: Re: UESQLC
Message-ID: <20000222111052.A5866@fam-meskes.de>
Mail-Followup-To: Rafael Jesus Alcantara Perez <rafa@dedalo-ing.com>,
PostgreSQL Hacker <pgsql-hackers@postgresql.org>
References: <00021912251300.00851@mastermind.home.ma.es>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <00021912251300.00851@mastermind.home.ma.es>;
from rafa@dedalo-ing.com on Sat, Feb 19, 2000 at 12:17:16PM +0100
Sender: michael@fam-meskes.de
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id FAB12162
On Sat, Feb 19, 2000 at 12:17:16PM +0100, Rafael Jesus Alcantara Perez wrote:
I'm the main author of UESQLC, an embedded SQL compiler that, (now) can g=
...
example of C++ with embedded SQL (UESQL). It is under the GPL and this is=
As you might imagine I'm interested in this. After all I maintain ECPG the
embedded SQL preprocessor for C distributed with PostgreSQL. So I tried
looking into your source, but I cannot get mpcl to compile:
dia2dfaml.cc: In function oid _CheckIntegrity()':
dia2dfaml.cc:180: using `typename' outside of template
dia2dfaml.cc: In function oid
_ParseUmlClass(mpcl::TRegularExpressionMatcher &, const string &)':
dia2dfaml.cc:421: using `typename' outside of template
dia2dfaml.cc: In function oid _ResolveStates()':
dia2dfaml.cc:467: using `typename' outside of template
dia2dfaml.cc:468: using `typename' outside of template
dia2dfaml.cc: In function oid _WriteActions()':
dia2dfaml.cc:502: using `typename' outside of template
dia2dfaml.cc: In function oid _WriteDfaml(const string &)':
dia2dfaml.cc:520: using `typename' outside of template
dia2dfaml.cc: In function oid _WriteTransitions(const string &)':
dia2dfaml.cc:592: using `typename' outside of template
make[3]: *** [dia2dfaml.o] Error 1
I hvae not found the time to dig into it myself.
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 Tue Feb 22 05:14:09 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA11622
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 05:13:29 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id TAA15437;
Tue, 22 Feb 2000 19:13:26 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id TAA17199;
Tue, 22 Feb 2000 19:13:26 +0900
To: chris@bitmead.com
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] psql and pager
In-Reply-To: Your message of "Tue, 22 Feb 2000 21:09:55 +1100"
<38B26073.9EFA1267@bitmead.com>
References: <38B26073.9EFA1267@bitmead.com>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000222191325U.t-ishii@sra.co.jp>
Date: Tue, 22 Feb 2000 19:13:25 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 8
Does anybody know how to disable "pager" of psql? It's really annoying
when I use psql in my emacs's shell buffer...One way is to unset the PAGER environment variable.
New psql seems to try to use more even PAGER is not set.
--
Tatsuo Ishii
From bouncefilter Tue Feb 22 05:06:18 2000
Received: from hu.tm.ee (ppp770.tele2.ee [212.107.37.70])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA10287
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 05:06:08 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id DD4193AC4; Tue, 22 Feb 2000 12:14:39 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38B2618F.E12DB5@tm.ee>
Date: Tue, 22 Feb 2000 12:14:39 +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: Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
References: <200002220509.AAA27880@candle.pha.pa.us>
<22426.951197494@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
ERROR: ALTER TABLE / DROP CONSTRAINT is not implemented
I thought that was going in. According to Marc, if it sufficiently
warned users, and required them to type it twice, it would do Peter's
alter table code. Perhaps Peter decided to wait for 7.1?I thought the rest of us beat him up until he took it out ;-)
Was'nt that DROP COLUMN ?
Is'nt DROP CONSTRAINT something completely different ?
AFAIK constraints are not (should not;) be implemented as extra columns,
even though they look like it in CREATE TABLE clause.
So removing them would actually mean deleting some rows from some system
table(s). And you don't even have to check the validity of existing data as
have to when doing ADD CONSTRAINT.
----------------
Hannu
From bouncefilter Tue Feb 22 05:28:10 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 FAA14553;
Tue, 22 Feb 2000 05:27:52 -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 LAA05509;
Tue, 22 Feb 2000 11:26:11 +0100
Date: Tue, 22 Feb 2000 11:26:11 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: The Hermit Hacker <scrappy@hub.org>, Tom Lane <tgl@sss.pgh.pa.us>,
webmaster@postgreSQL.org, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <200002220053.TAA19367@candle.pha.pa.us>
Message-ID: <Pine.LNX.3.96.1000222110924.310B-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 21 Feb 2000, Bruce Momjian wrote:
Should be accurate. I usually make a release list after the feature
freeze/beta starts.
I'am not sure that TODO is accurate. The 7.0 has non-TODO (small) features
too --> The Oracle compatible TO_CHAR() for date/time, numbers
(int/float/numeric) formatting and (reverse) TO_DATE() / TO_TIMESTAMP() /
TO_NUMBER() for string to number or data/time conversion.
Number part (TO_NUMBER() and TO_CHAR()) support locale and allow you convert
number to locale-like number.
Karel
PS. for exact changes: "diff -r --new-file 6.5.x 7.0" :-))
From bouncefilter Tue Feb 22 05:30:09 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 FAA14983
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 05:29:29 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (max01-036.enterprise.net [194.72.195.36])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id KAA22036;
Tue, 22 Feb 2000 10:29:25 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 KAA31505;
Tue, 22 Feb 2000 10:32:05 GMT
Message-Id: <200002221032.KAA31505@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: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgreSQL.org, olly@linda.lfix.co.uk
Subject: Re: [HACKERS] psql and pager
In-Reply-To: Message from Tatsuo Ishii <t-ishii@sra.co.jp> of "Tue,
22 Feb 2000 15:57:30 +0900." <20000222155730Q.t-ishii@sra.co.jp>
References: <20000222155730Q.t-ishii@sra.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 22 Feb 2000 10:32:05 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
Tatsuo Ishii wrote:
Does anybody know how to disable "pager" of psql? It's really annoying
when I use psql in my emacs's shell buffer...
Before you start psql, do `export PAGER=cat'
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"The LORD bless thee, and keep thee; The LORD make his
face shine upon thee, and be gracious unto thee; The
LORD lift up his countenance upon thee, and give thee
peace." Numbers 6:24-26
From bouncefilter Tue Feb 22 06:28:12 2000
Received: from sapphire.albourne.com (sapphire.albourne.com [195.212.241.227])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA29130
for <pgsql-hackers@postgresql.org>;
Tue, 22 Feb 2000 06:27:08 -0500 (EST)
(envelope-from alessio@albourne.com)
Received: from albourne.com (akamas.albourne.com [195.212.241.254])
by sapphire.albourne.com (8.9.3/8.9.3/Albourne/CYS/1.8/MAPS) with ESMTP
id NAA24980; Tue, 22 Feb 2000 13:27:00 +0200 (EET)
Sender: alessio@albourne.com
Message-ID: <38B27283.12AEB679@albourne.com>
Date: Tue, 22 Feb 2000 13:26:59 +0200
From: Alessio Bragadini <alessio@albourne.com>
Organization: APL Financial Services (Overseas) Ltd.
X-Mailer: Mozilla 4.7 [en] (X11; I; OSF1 V4.0 alpha)
X-Accept-Language: it, en, sv
MIME-Version: 1.0
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
CC: Adriaan Joubert <a.joubert@albourne.com>
Subject: Big join breaks psql
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The following (rather long) query run fine for some time when executed
through Micro$oft Query via Psqlodbc. We never tried it under psql.
Today it appeared broken (some trickery on the Excel worksheet seems to
have fix that) and for the first time I tried to run it from the command
line. I never managed, psql always breaks in the same way:
cb=> \i /home/alessio/check.sql
SELECT peergroup.id, convid.name, convid.bb_cb, convid.bb_eq,
convdaily.date, convdaily.paritygross, convdaily.bidprice,
convdaily.askprice, convdaily.stockprice, tradingsignal.job,
tradingsignal.buysell, tradingsignal.delta, tradingsignal.premium
FROM convdaily convdaily, convid convid, peergroup peergroup,
tradingsignal tradingsignal
WHERE convid.id = peergroup.id AND peergroup.id = tradingsignal.id AND
convdaily.id = peergroup.id AND convdaily.date = tradingsignal.date AND
((tradingsignal.job=6) AND (tradingsignal.buysell='B') AND
(peergroup.pgid=45) AND (convdaily.date='21-02-2000') OR
(tradingsignal.job=7) AND
(tradingsignal.buysell='B') AND (peergroup.pgid=45) AND
(convdaily.date='21-02-2000') OR (tradingsignal.job=8) AND
(tradingsignal.buysell='B') AND (peergroup.pgid=45) AND
(convdaily.date='21-02-2000') OR (tradingsignal.job=210) AND
(tradingsignal.buysell='B') AND (peergroup.pgid=45) AND
(convdaily.date='21-02-2000') OR (tradingsignal.job=211) AND
(tradingsignal.buysell='B') AND (peergroup.pgid=45) AND
(convdaily.date='21-02-2000') OR (tradingsignal.job=6) AND
(tradingsignal.buysell='U') AND (peergroup.pgid=45) AND
(convdaily.date='21-02-2000') OR (tradingsignal.job=7) AND
(tradingsignal.buysell='U') AND (peergroup.pgid=45) AND
(convdaily.date='21-02-2000') OR (tradingsignal.job=8) AND
(tradingsignal.buysell='U') AND (peergroup.pgid=45) AND
(convdaily.date='21-02-2000') OR (tradingsignal.job=210) AND
(tradingsignal.buysell='U') AND (peergroup.pgid=45) AND
(convdaily.date='21-02-2000') OR (tradingsignal.job=211) AND
(tradingsignal.buysell='U') AND (peergroup.pgid=45) AND
(convdaily.date='21-02-2000') OR (tradingsignal.job=212) AND
(tradingsignal.buysell='B') AND (peergroup.pgid=45) AND
(convdaily.date='21-02-2000') OR (tradingsignal.job=212) AND
(tradingsignal.buysell='U') AND (peergroup.pgid=45) AND
(convdaily.date='21-02-2000'))
ORDER BY peergroup.id, tradingsignal.job;
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
We have lost the connection to the backend, so further processing is
impossible. Terminating.
Some info on the tables:
cb=> select count(*) from convdaily;
count
-------
2260691
(1 row)
cb=> select count(*) from convid;
count
-----
3666
(1 row)
cb=> select count(*) from peergroup;
count
-----
730
(1 row)
cb=> select count(*) from tradingsignal;
count
------
221374
(1 row)
Is it a problem on the backend or on psql? Is simply the query using a
too big 4-table join? I am wondering, since postmaster.log states
FATAL 1: Memory exhausted in AllocSetAlloc()
We are running PostgreSQL 6.5.2 on alphaev6-dec-osf4.0f, compiled by cc.
Any idea would be greatly appreciated.
Thanks in advance.
--
Alessio F. Bragadini alessio@albourne.com
APL Financial Services http://www.sevenseas.org/~alessio
Nicosia, Cyprus phone: +357-2-750652
"It is more complicated than you think"
-- The Eighth Networking Truth from RFC 1925
From bouncefilter Tue Feb 22 06:49:10 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 GAA33047;
Tue, 22 Feb 2000 06:48:47 -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 MAA08977;
Tue, 22 Feb 2000 12:48:41 +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 12NEkz-0007qb-00; Tue, 22 Feb 2000 12:49:37 +0000
Message-ID: <38B27760.DB921B57@sferacarta.com>
Date: Tue, 22 Feb 2000 12:47:44 +0100
From: Jose Soares <jose@sferacarta.com>
Organization: Sfera Carta
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: hackers <pgsql-hackers@postgresql.org>,
general <pgsql-general@postgresql.org>
Subject: TRANSACTIONS
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi all,
The transactions should be the way to distinguish a relational database
from others no-relational databases, (MySQL is the right example).
We are very proud of PostgreSQL transactions but seems that it doesn't
work in the right way.
It shoud be important to be sure that PostgreSQL is compliant with
SQL92.
I need absolutely to use transactions but until now I could not use it,
in my case it is completely unusable.
I tried transactions in other databases and I compared it with
PostgreSQL and no one of which I tried has the same PostgreSQL behavior.
I tried the following script:
-------------------------------------------------------
PostgreSQL:
-------------------------------------------------------
begin transaction;
create table tmp(a int);
insert into tmp values (1);
insert into tmp values (1000000000000000000000000000000000);
ERROR: pg_atoi: error reading "1000000000000000000000000000000000":
Numerical result out of range
commit;
select * from tmp;
ERROR: tmp: Table does not exist.
-------------------------------------------------------
Interbase, Oracle,Informix,Solid,Ms-Access,DB2:
-------------------------------------------------------
connect hygea.gdb;
create table temp(a int);
insert into temp values (1);
insert into temp values (1000000000000000000000000000000000);
commit;
select * from temp;
arithmetic exception, numeric overflow, or string truncation
A
===========
1
I would like to know what the Standard says and who is in the rigth path
PostgreSQL or the others, considering the two examples reported below.
Comments?
--
Jose' Soares
Bologna, Italy Jose@sferacarta.com
From bouncefilter Tue Feb 22 07:00:10 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA35013;
Tue, 22 Feb 2000 06:59:10 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Haj.DoCS.UU.SE (e99re41@Haj.DoCS.UU.SE [130.238.9.164])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id MAA01013;
Tue, 22 Feb 2000 12:58:53 +0100 (MET)
Received: from localhost (e99re41@localhost) by Haj.DoCS.UU.SE (8.6.12/8.6.12)
with SMTP id MAA14781; Tue, 22 Feb 2000 12:58:52 +0100
X-Authentication-Warning: Haj.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 22 Feb 2000 12:58:52 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tatsuo Ishii <t-ishii@sra.co.jp>, dhogaza@pacifier.com, scrappy@hub.org,
tgl@sss.pgh.pa.us, webmaster@postgreSQL.org, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <200002220509.AAA27880@candle.pha.pa.us>
Message-ID: <Pine.GSO.4.02A.10002221256140.14754-100000@Haj.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 22 Feb 2000, Bruce Momjian wrote:
What about ALTER TABLE table DROP CONSTRAINT? I see this:
Note that we seem to have ALTER TABLE table ADD CONSTRAINT, though.
Perhaps Peter decided to wait for 7.1?
Yes and no. I never had anything like this. I was afraid to get crossed up
with Jan. Anyway, to add/drop unique constraints create/drop the index. To
add/drop foreign keys, use create/drop constraint trigger(????). To
add/drop check contraints you're on your own. Not so bad all in all.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Feb 22 07:08:10 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA37280
for <pgsql-hackers@postgresql.org>;
Tue, 22 Feb 2000 07:07:38 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Haj.DoCS.UU.SE (e99re41@Haj.DoCS.UU.SE [130.238.9.164])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id NAA02107;
Tue, 22 Feb 2000 13:07:30 +0100 (MET)
Received: from localhost (e99re41@localhost) by Haj.DoCS.UU.SE (8.6.12/8.6.12)
with SMTP id NAA14788; Tue, 22 Feb 2000 13:07:30 +0100
X-Authentication-Warning: Haj.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 22 Feb 2000 13:07:29 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: The Hermit Hacker <scrappy@HUB.ORG>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <Pine.BSF.4.21.0002211952550.86931-100000@thelab.hub.org>
Message-ID: <Pine.GSO.4.02A.10002221259170.14754-100000@Haj.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 21 Feb 2000, The Hermit Hacker wrote:
* -Add BIT, BIT VARYING
This is currently suffering from BIT rot in contrib. Not really usable.
And we can't squeeze it in until the bootstrap scanner recognizes tokens
with spaces in it. (Does it?)
* -Add ALTER TABLE DROP/ALTER COLUMN feature(Peter E)
Since there seems to be some confusion here: What currently exists all
done is ALTER TABLE ALTER COLUMN (which allows you to set and drop
defaults). What does not exist is DROP COLUMN and ADD/DROP CONTRAINT in
its full glory.
If someone cares for accuracy, I also did these:
* -pg_dump should preserve primary key information
* -Allow flag to control COPY input/output of NULLs
* -Allow psql \copy to allow delimiters
* -Allow psql to print nulls as distinct from "" [null]
* -Make configure --enable-debug add -g on compile line
* -Pre-generate lex and yacc output so not required for install
* -Make Absolutetime/Relativetime int4 because time_t can be int8 on some ports
* -Make type equivalency apply to aggregates
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Feb 22 07:14:10 2000
Received: from relay.wplus.net (relay.wplus.net [195.131.52.179])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA38702;
Tue, 22 Feb 2000 07:13:38 -0500 (EST)
(envelope-from dms@woland.wplus.net)
Received: from woland.wplus.net (woland.wplus.net [195.131.0.39])
by relay.wplus.net (8.9.1/8.9.1/wplus.2) with ESMTP id PAA42709;
Tue, 22 Feb 2000 15:12:53 +0300 (MSK)
X-Real-To: pgsql-hackers@postgreSQL.org
Received: (from dms@localhost)
by woland.wplus.net (8.9.3/8.9.1/wplus.2) id PAA45382;
Tue, 22 Feb 2000 15:13:12 +0300 (MSK)
Message-ID: <XFMail.20000222151312.dms@wplus.net>
X-Mailer: XFMail 1.4.4 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <38B27760.DB921B57@sferacarta.com>
Date: Tue, 22 Feb 2000 15:13:12 +0300 (MSK)
Sender: dms@woland.wplus.net
From: Dmitry Samersoff <dms@wplus.net>
To: Jose Soares <jose@sferacarta.com>
Subject: RE: [HACKERS] TRANSACTIONS
Cc: general <pgsql-general@postgreSQL.org>,
hackers <pgsql-hackers@postgreSQL.org>
On 22-Feb-2000 Jose Soares wrote:
begin transaction;
create table tmp(a int);
insert into tmp values (1);
insert into tmp values (1000000000000000000000000000000000);
ERROR: pg_atoi: error reading "1000000000000000000000000000000000":
Numerical result out of range
commit;
select * from tmp;
ERROR: tmp: Table does not exist.
-------------------------------------------------------
Interbase, Oracle,Informix,Solid,Ms-Access,DB2:
^^^^^^^^^
AFAIK, MS Access have no transactions inside it,
Informix (at least old versions I worked with) always
perform create,drop, alter object outside transaction
but IMHO it's not right behavior.
I believe postgres's behavior more meaningful,
but IMHO, this example is quite far from real life.
--
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...
From bouncefilter Tue Feb 22 07:18:11 2000
Received: from homeworld.bigpanda.org
(IDENT:root@client-151-198-27-104.bellatlantic.net [151.198.27.104])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA39669
for <pgsql-hackers@postgresql.org>;
Tue, 22 Feb 2000 07:17:49 -0500 (EST)
(envelope-from acroyear@homeworld.bigpanda.org)
Received: from homeworld.bigpanda.org (IDENT:acroyear@localhost.awc.net
[127.0.0.1])
by homeworld.bigpanda.org (8.9.3/8.9.3) with ESMTP id HAA10531;
Tue, 22 Feb 2000 07:15:20 -0500
Message-Id: <200002221215.HAA10531@homeworld.bigpanda.org>
To: Ed Loehr <eloehr@austin.rr.com>
CC: pgsql-hackers@postgresql.org
From: sszabo@bigpanda.com
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: Your message of "Tue, 22 Feb 2000 00:34:01 CST."
<38B22DD9.99FFAB3D@austin.rr.com>
Date: Tue, 22 Feb 2000 07:15:20 -0500
Sender: acroyear@bigpanda.com
Don Baccus wrote:
At 07:57 PM 2/21/00 -0400, The Hermit Hacker wrote:
* -Add referential integrity(Jan)[primary]
This is only PARTIALLY complete:
MATCH FULL and MATCH <unspecified> foreign keys and their related
referential actions are complete. MATCH PARTIAL isn't in - I'll be
doing that for 7.1.Can anyone point me to a written description of the expected
functionality (and maybe limitations) provided by this release of RI?
I'm not asking for a definition of RI, but rather the status of
*current* (7.0) pgsql RI functionality, i.e., what one should
expect...
Well, I have some documentation patches currently out for the people
in the FK project, but we haven't gotten that completely finished,
and there are a few subtle differences right now due to some stuff
that we weren't able to get finished, in the meantime, while we're
working on that, I believe the following should sum it up:
* You can make both column and table constraints for foreign key
constraints. Currently, column FK constraints may not
specify NOT DEFERRABLE or INITIALLY (DEFERRED|IMMEDIATE)
due to shift/reduce problems in the parser.
* You can only specify MATCH FULL or use MATCH unspecified for
the matching types. MATCH PARTIAL should be in 7.1.
* If you do not specify the referenced columns, it will look for
the primary key on the referenced table, but if you specify
referenced columns, it will not guarantee that those columns
actually are a foreign key or have a unique constraint upon
them.
* It does not enforce uniqueness of constraint names. (A big
reason that I didn't also due an FK version of ALTER TABLE
DROP CONSTRAINT) Theoretically the constraint names for
unique, check and fk constraints must all be checked to
guarantee uniqueness. Also, constraint names made by the
system must also not conflict with existing constraint
names, and probably should not fail, but instead have
a way of forcing a unique name.
* ALTER TABLE ADD CONSTRAINT will allow the adding of any
foreign key constraint that would be legal in the
table constraint context (hopefully). It also checks
the current table data and refuses to add the constraint
if the constraint would be immediately violated (again
hopefully -- it's worked for our tests, but let's see
what happens in the real world).
* pg_dump will dump CREATE CONSTRAINT TRIGGER statements for
tables with foreign key constraints. In data only dumps,
pg_dump does a little bit of magic with the system catalogs
to turn off all triggers on user defined tables and turn
them back on at the end. It currently does not enforce
that the data in between does not violate the constraint.
This is unfortunate, but we didn't come up with a good
way to do this for possibly circular fk constraints and
still be able to deal with the possibility that the user
may have changed the constraints since the dump, since
it's data-only.
[Anything you can think of to add to this Don?]
Stephan
From bouncefilter Tue Feb 22 07:19:11 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA39762
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 07:18:33 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Haj.DoCS.UU.SE (e99re41@Haj.DoCS.UU.SE [130.238.9.164])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id NAA03400;
Tue, 22 Feb 2000 13:18:26 +0100 (MET)
Received: from localhost (e99re41@localhost) by Haj.DoCS.UU.SE (8.6.12/8.6.12)
with SMTP id NAA14809; Tue, 22 Feb 2000 13:18:26 +0100
X-Authentication-Warning: Haj.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 22 Feb 2000 13:18:25 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error
messages
In-Reply-To: <22061.951191794@sss.pgh.pa.us>
Message-ID: <Pine.GSO.4.02A.10002221316290.14754-100000@Haj.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 21 Feb 2000, Tom Lane wrote:
For the same sort of reasons I'd prefer that our scanner worked
with vanilla lex, not just flex. I'm not sure how far away we are
from that; it may be an unrealistic goal. But if it is within reach
then we shouldn't give it up lightly.
I concur. Somewhere in between vanilla lex and flex is also POSIX lex,
which does support exclusive start conditions but no <<EOF>>.
Anyone for getting rid of GNU make?
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Feb 22 07:21:10 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA40236
for <pgsql-hackers@postgresql.org>;
Tue, 22 Feb 2000 07:20:28 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Haj.DoCS.UU.SE (e99re41@Haj.DoCS.UU.SE [130.238.9.164])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id NAA03571;
Tue, 22 Feb 2000 13:20:08 +0100 (MET)
Received: from localhost (e99re41@localhost) by Haj.DoCS.UU.SE (8.6.12/8.6.12)
with SMTP id NAA14819; Tue, 22 Feb 2000 13:20:07 +0100
X-Authentication-Warning: Haj.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 22 Feb 2000 13:20:07 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] psql and pager
In-Reply-To: <20000222155730Q.t-ishii@sra.co.jp>
Message-ID: <Pine.GSO.4.02A.10002221319030.14754-100000@Haj.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 22 Feb 2000, Tatsuo Ishii wrote:
Does anybody know how to disable "pager" of psql? It's really annoying
when I use psql in my emacs's shell buffer...
\pset pager
Put it in .psqlrc if you like. (Or in .psqlrc-7.0.0 to not affect the old
one.)
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Feb 22 07:24:10 2000
Received: from homeworld.bigpanda.org
(IDENT:root@client-151-198-27-104.bellatlantic.net [151.198.27.104])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA40958
for <pgsql-hackers@postgresql.org>;
Tue, 22 Feb 2000 07:24:04 -0500 (EST)
(envelope-from acroyear@homeworld.bigpanda.org)
Received: from homeworld.bigpanda.org (IDENT:acroyear@localhost.awc.net
[127.0.0.1])
by homeworld.bigpanda.org (8.9.3/8.9.3) with ESMTP id HAA10554;
Tue, 22 Feb 2000 07:21:28 -0500
Message-Id: <200002221221.HAA10554@homeworld.bigpanda.org>
To: Tatsuo Ishii <t-ishii@sra.co.jp>
CC: pgsql-hackers@postgresql.org
From: sszabo@bigpanda.com
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: Your message of "Tue, 22 Feb 2000 13:45:39 +0900."
<20000222134539N.t-ishii@sra.co.jp>
Date: Tue, 22 Feb 2000 07:21:28 -0500
Sender: acroyear@bigpanda.com
At 07:57 PM 2/21/00 -0400, The Hermit Hacker wrote:
* -Add referential integrity(Jan)[primary]
This is only PARTIALLY complete:
MATCH FULL and MATCH <unspecified> foreign keys and their related
referential actions are complete. MATCH PARTIAL isn't in - I'll be
doing that for 7.1.It doesn't check that the columns referenced in a foreign key
form a primary key or are contrained by UNIQUE in the referenced
table. This will be checked in 7.1, not sure who will do it (who
ever gets to it first, probably).Those are the two major user-visible loose ends with this feature.
What about ALTER TABLE table DROP CONSTRAINT? I see this:
alter table t1 drop constraint t1_fk cascade;
ERROR: ALTER TABLE / DROP CONSTRAINT is not implementedNote that we seem to have ALTER TABLE table ADD CONSTRAINT, though.
I looked at drop constraint for the foreign key case while I was doing
add constraint, but right now the system doesn't generate unique
constraint names (although it should) so drop constraint could be
dangerous if you're not careful. Yeah, let me drop this RI constraint
'<unknown>' that I just created... oops... And unfortunately, to be
really compliant, all of the constraint names have to be unique, and
I really didn't want to hack something in that was going to make it
harder to do it right later.
Stephan
From bouncefilter Tue Feb 22 07:31:18 2000
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA42389
for <pgsql-hackers@postgresql.org>;
Tue, 22 Feb 2000 07:30:11 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id VAA23284;
Tue, 22 Feb 2000 21:30:08 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id VAA19576;
Tue, 22 Feb 2000 21:30:08 +0900
To: peter_e@gmx.net, e99re41@DoCS.UU.SE
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] psql and pager
In-Reply-To: Your message of "Tue, 22 Feb 2000 13:20:07 +0100 (MET)"
<Pine.GSO.4.02A.10002221319030.14754-100000@Haj.DoCS.UU.SE>
References: <Pine.GSO.4.02A.10002221319030.14754-100000@Haj.DoCS.UU.SE>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000222213007B.t-ishii@sra.co.jp>
Date: Tue, 22 Feb 2000 21:30:07 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 21
Does anybody know how to disable "pager" of psql? It's really annoying
when I use psql in my emacs's shell buffer...\pset pager
Put it in .psqlrc if you like. (Or in .psqlrc-7.0.0 to not affect the old
one.)
Thansk. I have read the man page of psql. However I misunderstood:
Toggles the list of a pager to do table output. If the environment
variable PAGER is set, the output is piped to the specified program.
Otherwise more is used.In any case, psql only uses the pager if it seems appropriate.
I thought psql may use a pager even if \pset toggles off a pager. I
need to learn English more:-)
--
Tatsuo Ishii
From bouncefilter Tue Feb 22 07:47:11 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA46695
for <pgsql-hackers@postgresql.org>;
Tue, 22 Feb 2000 07:46:56 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Haj.DoCS.UU.SE (e99re41@Haj.DoCS.UU.SE [130.238.9.164])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id NAA06384;
Tue, 22 Feb 2000 13:46:52 +0100 (MET)
Received: from localhost (e99re41@localhost) by Haj.DoCS.UU.SE (8.6.12/8.6.12)
with SMTP id NAA15054; Tue, 22 Feb 2000 13:46:51 +0100
X-Authentication-Warning: Haj.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 22 Feb 2000 13:46:51 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] psql and pager
In-Reply-To: <20000222213007B.t-ishii@sra.co.jp>
Message-ID: <Pine.GSO.4.02A.10002221345040.14754-100000@Haj.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 22 Feb 2000, Tatsuo Ishii wrote:
I thought psql may use a pager even if \pset toggles off a pager.
No, only if it's toggled on.
In the old version the use of the pager was determined by whether or not
the environment variable PAGER was set. This behaviour is not very
cooperative with other programs that might use the same variable.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Feb 22 07:50:11 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA47295
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 07:49:59 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Haj.DoCS.UU.SE (e99re41@Haj.DoCS.UU.SE [130.238.9.164])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id NAA06647;
Tue, 22 Feb 2000 13:49:42 +0100 (MET)
Received: from localhost (e99re41@localhost) by Haj.DoCS.UU.SE (8.6.12/8.6.12)
with SMTP id NAA15066; Tue, 22 Feb 2000 13:49:41 +0100
X-Authentication-Warning: Haj.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 22 Feb 2000 13:49:41 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: sszabo@bigpanda.com
cc: Ed Loehr <eloehr@austin.rr.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <200002221215.HAA10531@homeworld.bigpanda.org>
Message-ID: <Pine.GSO.4.02A.10002221347320.14754-100000@Haj.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 22 Feb 2000 sszabo@bigpanda.com wrote:
* pg_dump will dump CREATE CONSTRAINT TRIGGER statements for
tables with foreign key constraints. In data only dumps,
pg_dump does a little bit of magic with the system catalogs
to turn off all triggers on user defined tables and turn
them back on at the end.
Whatever happened to the idea of a SET command for this? IIRC, SQL already
has a contraint related set command (for deferring, etc.). Why not
overload that to turn off foreign keys? I could imagine that being useful
for people developing database schemas.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Feb 22 08:13:27 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA51810;
Tue, 22 Feb 2000 08:12:29 -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 JAA74001;
Tue, 22 Feb 2000 09:09:48 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 22 Feb 2000 09:09:47 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tatsuo Ishii <t-ishii@sra.co.jp>, dhogaza@pacifier.com, tgl@sss.pgh.pa.us,
webmaster@postgreSQL.org, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <200002220509.AAA27880@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0002220909110.86931-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 22 Feb 2000, Bruce Momjian wrote:
Those are the two major user-visible loose ends with this feature.
What about ALTER TABLE table DROP CONSTRAINT? I see this:
alter table t1 drop constraint t1_fk cascade;
ERROR: ALTER TABLE / DROP CONSTRAINT is not implementedNote that we seem to have ALTER TABLE table ADD CONSTRAINT, though.
I thought that was going in. According to Marc, if it sufficiently
warned users, and required them to type it twice, it would do Peter's
alter table code. Perhaps Peter decided to wait for 7.1?
Ummm...I don't recall ever talking about DROP CONTRAINT *raised eyebrow*
From bouncefilter Tue Feb 22 08:15:19 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA52229
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 08:14:39 -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 JAA74011;
Tue, 22 Feb 2000 09:12:35 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 22 Feb 2000 09:12:35 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <200002220543.AAA29726@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0002220910360.86931-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 22 Feb 2000, Bruce Momjian wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
ERROR: ALTER TABLE / DROP CONSTRAINT is not implemented
I thought that was going in. According to Marc, if it sufficiently
warned users, and required them to type it twice, it would do Peter's
alter table code. Perhaps Peter decided to wait for 7.1?I thought the rest of us beat him up until he took it out ;-)
Yes, he was badly beaten up about it, but I felt that the code as is was
pretty good, considering how bad CLUSTER is. If people are told the
limitations, it could be a win.
god, I hate this argument: we did it badly for CLUSTER, so its okay to do
it badly here too :(
I felt that the more advanced features like not using 2x disk space were
quite hard to implement, considering the other TODO items. Marc agreed
and was going to e-mail him to tell him that with proper user warning,
we wanted the patch.
"agreed" is a weak word in this sense ... :)
Do people disagree?
I don't like it, and think with some effort, it could be done better, and
will stick with that ... but if "its the best that can be done" ...
*shrug*
But, after 7.0 is released ... I still believe that the outstanding issues
were such that putting it into 7.0 was a bad thing ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Tue Feb 22 08:15:11 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA52213
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 08:14:32 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Haj.DoCS.UU.SE (e99re41@Haj.DoCS.UU.SE [130.238.9.164])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id OAA09920;
Tue, 22 Feb 2000 14:14:23 +0100 (MET)
Received: from localhost (e99re41@localhost) by Haj.DoCS.UU.SE (8.6.12/8.6.12)
with SMTP id OAA15113; Tue, 22 Feb 2000 14:14:23 +0100
X-Authentication-Warning: Haj.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 22 Feb 2000 14:14:23 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Kaare Rasmussen <kar@webline.dk>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO list / why 7.0 ?
In-Reply-To: <00022206444508.00287@bering>
Message-ID: <Pine.GSO.4.02A.10002221412080.14754-100000@Haj.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 22 Feb 2000, Kaare Rasmussen wrote:
Can't wait for this one. If you throw large objects in also, let's go straight
to 8.0 :-)
IMHO, 8.0 should be reserved for the first SQL Entry level (direct entry)
compliant release. A recent survey lead me to believe that, if we really
make a push, this is only two or three releases away.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Feb 22 09:08:13 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 JAA72843
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 09:07:59 -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
JAA15051;
Tue, 22 Feb 2000 09:07:11 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002221407.JAA15051@candle.pha.pa.us>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <22796.951202660@sss.pgh.pa.us> from Tom Lane at "Feb 22,
2000 01:57:40 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 22 Feb 2000 09:07:11 -0500 (EST)
CC: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
The Hermit Hacker <scrappy@hub.org> writes:
Working on the Release Announcement now ...
* -SELECT ... UNION ... ORDER BY fails when sort expr not in result list,
ORDER BY is applied only to the first SELECTThis is still broken AFAIK. Not sure how it got marked as done.
Not marked as done on my copy.
* -Make type equivalency apply to aggregates
IIRC, Peter should get the credit for that one.
Added.
* -Certain indexes will not shrink, i.e. oid indexes with many
inserts(Vadim)AFAIK that isn't done either.
Fixed.
* -Document/trigger/rule so changes to pgshadow recreate pgpwd
[pg_shadow]
Added.
Peter's work also...
* -fix memory leak in cache code when non-existant table is referenced In
WHERE tab1.x=3 AND tab1.x=tab2.y, add tab2.y=3This looks like 2 items got merged somehow. AFAIK only the first is
done.
Split.
Looking at my own notes about completed changes, it sure seems like
there have been one heck of a lot of bugfixes and performance
improvements that don't correspond to anything on the official TODO
list. It might be worth making some opening remarks along that line
rather than just presenting the checked-off items.
Yes, that is what I will do by going through CVS. It is better for Marc
to just specify the release and wait for my full release blurb coming in
a few days.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 22 09:13:12 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 JAA74034;
Tue, 22 Feb 2000 09:12:59 -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
JAA15418;
Tue, 22 Feb 2000 09:11:52 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002221411.JAA15418@candle.pha.pa.us>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <Pine.GSO.4.02A.10002221256140.14754-100000@Haj.DoCS.UU.SE> from
Peter Eisentraut at "Feb 22, 2000 12:58:52 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Tue, 22 Feb 2000 09:11:52 -0500 (EST)
CC: Tatsuo Ishii <t-ishii@sra.co.jp>, dhogaza@pacifier.com, scrappy@hub.org,
tgl@sss.pgh.pa.us, webmaster@postgreSQL.org, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Tue, 22 Feb 2000, Bruce Momjian wrote:
What about ALTER TABLE table DROP CONSTRAINT? I see this:
Note that we seem to have ALTER TABLE table ADD CONSTRAINT, though.
Perhaps Peter decided to wait for 7.1?
I was speaking off DROP COLUMN. Sorry to have added to the confusion.
Yes and no. I never had anything like this. I was afraid to get crossed up
with Jan. Anyway, to add/drop unique constraints create/drop the index. To
add/drop foreign keys, use create/drop constraint trigger(????). To
add/drop check contraints you're on your own. Not so bad all in all.--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 22 09:17:16 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 JAA75023
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 09:16:52 -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
JAA15918;
Tue, 22 Feb 2000 09:15:54 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002221415.JAA15918@candle.pha.pa.us>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <Pine.GSO.4.02A.10002221259170.14754-100000@Haj.DoCS.UU.SE> from
Peter Eisentraut at "Feb 22, 2000 01:07:29 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Tue, 22 Feb 2000 09:15:54 -0500 (EST)
CC: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Mon, 21 Feb 2000, The Hermit Hacker wrote:
* -Add BIT, BIT VARYING
This is currently suffering from BIT rot in contrib. Not really usable.
And we can't squeeze it in until the bootstrap scanner recognizes tokens
with spaces in it. (Does it?)
Aw man, I promised to put that into the main tree. Is it not usable?
Spaces?
* -Add ALTER TABLE DROP/ALTER COLUMN feature(Peter E)
Since there seems to be some confusion here: What currently exists all
done is ALTER TABLE ALTER COLUMN (which allows you to set and drop
defaults). What does not exist is DROP COLUMN and ADD/DROP CONTRAINT in
its full glory.If someone cares for accuracy, I also did these:
* -pg_dump should preserve primary key information
* -Allow flag to control COPY input/output of NULLs
* -Allow psql \copy to allow delimiters
* -Allow psql to print nulls as distinct from "" [null]
* -Make configure --enable-debug add -g on compile line
* -Pre-generate lex and yacc output so not required for install
* -Make Absolutetime/Relativetime int4 because time_t can be int8 on some ports
* -Make type equivalency apply to aggregates
TODO updated.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 22 09:19:13 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 JAA75501;
Tue, 22 Feb 2000 09:18: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
JAA16211;
Tue, 22 Feb 2000 09:18:02 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002221418.JAA16211@candle.pha.pa.us>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <Pine.BSF.4.21.0002220909110.86931-100000@thelab.hub.org> from
The
Hermit Hacker at "Feb 22, 2000 09:09:47 am"
To: The Hermit Hacker <scrappy@hub.org>
Date: Tue, 22 Feb 2000 09:18:02 -0500 (EST)
CC: Tatsuo Ishii <t-ishii@sra.co.jp>, dhogaza@pacifier.com, tgl@sss.pgh.pa.us,
webmaster@postgreSQL.org, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Tue, 22 Feb 2000, Bruce Momjian wrote:
Those are the two major user-visible loose ends with this feature.
What about ALTER TABLE table DROP CONSTRAINT? I see this:
alter table t1 drop constraint t1_fk cascade;
ERROR: ALTER TABLE / DROP CONSTRAINT is not implementedNote that we seem to have ALTER TABLE table ADD CONSTRAINT, though.
I thought that was going in. According to Marc, if it sufficiently
warned users, and required them to type it twice, it would do Peter's
alter table code. Perhaps Peter decided to wait for 7.1?Ummm...I don't recall ever talking about DROP CONTRAINT *raised eyebrow*
Again, I am a goof. I was thinking of DROP COLUMN.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 22 10:25:36 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 KAA90773;
Tue, 22 Feb 2000 10:24:30 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by clio.trends.ca (8.9.3+Sun/8.9.3) with ESMTP id KAA06881;
Tue, 22 Feb 2000 10:24:26 -0500 (EST)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA16447;
Tue, 22 Feb 2000 07:23:35 -0800 (PST)
Message-Id: <3.0.1.32.20000222064332.010ac040@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 22 Feb 2000 06:43:32 -0800
To: Tatsuo Ishii <t-ishii@sra.co.jp>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
Cc: scrappy@hub.org, tgl@sss.pgh.pa.us, webmaster@postgreSQL.org,
pgsql-hackers@postgreSQL.org
In-Reply-To: <20000222143359C.t-ishii@sra.co.jp>
References: <Your message of "Mon, 21 Feb 2000 21:15:05
-0800"<3.0.1.32.20000221211505.007a7d10@mail.pacifier.com>
<3.0.1.32.20000221211505.007a7d10@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 02:33 PM 2/22/00 +0900, Tatsuo Ishii wrote:
And, no, you don't have ALTER TABLE ... ADD CONSTRAINT. What you have
is the ability to add foreign key constraints only. When this wasThis is more than ok:-) Since without ADD CONSTRAINTS, we could not
define a circular referential integrity at all. Good job!
Stephan Szabo did that particular piece of work, and, yeah, good job
indeed, Stephan!
- 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 Feb 22 10:26:16 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA90921;
Tue, 22 Feb 2000 10:24:54 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA16464;
Tue, 22 Feb 2000 07:23:37 -0800 (PST)
Message-Id: <3.0.1.32.20000222065543.010a4ec0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 22 Feb 2000 06:55:43 -0800
To: Ed Loehr <eloehr@austin.rr.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
Cc: The Hermit Hacker <scrappy@hub.org>, Tom Lane <tgl@sss.pgh.pa.us>,
webmaster@postgreSQL.org, pgsql-hackers@postgreSQL.org
In-Reply-To: <38B22DD9.99FFAB3D@austin.rr.com>
References: <29004.951164832@sss.pgh.pa.us>
<3.0.1.32.20000221163448.010940d0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 12:34 AM 2/22/00 -0600, Ed Loehr wrote:
Can anyone point me to a written description of the expected
functionality (and maybe limitations) provided by this release of RI?
I'm not asking for a definition of RI, but rather the status of
*current* (7.0) pgsql RI functionality, i.e., what one should
expect...
Jan was working on docs, and I think maybe Stephan Szabo? But Jan
seems to have dropped out of site, again - total immersion at work
is my diagnosis. I actually enjoy doing documentation but I'm swamped
at the moment, too.
In short...if you read Date's SQL primer, all foreign key functionality
is there EXCEPT "MATCH PARTIAL" and the check on the target columns being
constrained UNIQUE or PRIMARY KEY. We also need to assign a unique name
to the foreign key constraint if you don't give one (right now they're
just listed "unnamed") because otherwise you don't know which of several
foreign key constraints failed unless you explicitly name them yourself.
(I forgot that one in my previous note).
- 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 Feb 22 09:58:15 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 JAA84409
for <pgsql-hackers@postgresql.org>;
Tue, 22 Feb 2000 09:57:57 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (max02-013.enterprise.net [194.72.195.133])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id OAA07229;
Tue, 22 Feb 2000 14:57:50 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 PAA11690;
Tue, 22 Feb 2000 15:00:29 GMT
Message-Id: <200002221500.PAA11690@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: pgsql-hackers@postgresql.org
cc: Vladimir.Benes@pvt.cz
Subject: Out of memory problem (forwarded bug report)
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0
Date: Tue, 22 Feb 2000 15:00:29 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id JAA84450
Can someone advise, please, how to deal with this problem in 6.5.3?
This is the second message, after debugging was enabled in the backend:
------- Forwarded Message
Date: Tue, 22 Feb 2000 15:28:44 +0100
From: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" <Vladimir.Benes@pvt.cz>
To: "Oliver Elphick" <olly@lfix.co.uk>, <58689@bugs.debian.org>
cc: "=?iso-8859-2?Q?M=FChlpachr_Michal?=" <michalm@pvt.net>
Subject: Re: Bug#58689: Problem: database connection termination while processi
ng select command
Hi,
I tried this and this problem is reported in the log here:
query: select comm_type,name,tot_bytes,tot_packets from
flow_sums_days_send_200002_view where day='2000-02-21' and name not l
ProcessQuery
FATAL 1: Memory exhausted in AllocSetAlloc()
This message is invoked by unsuccess malloc() operation :-(
Well, I tried to use instead of simple select command this:
create temporary table xx as select ...
create table yy as select
select ... into zz from ...
I expected that Postgres will use less memory and that he will
continously send data to new tables but not. This hasn't any effect.
Command "top" wrote this report while my select ran:
CPU states: 98.6% user, 1.3% system, 0.0% nice, 0.0% idle
Mem: 127256K av, 124316K used, 2940K free, 29812K shrd, 2620K buff
Swap: 128516K av, 51036K used, 77480K free 7560K cached
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
2942 postgres 20 0 141M 99M 17348 R 0 99.0 80.4 1:22 postmaster
Thank You, V. Benes
- -----P���vodn��� zpr���va-----
Od: Oliver Elphick <olly@lfix.co.uk>
Komu: Vladim���r Bene��� <Vladimir.Benes@pvt.cz>; 58689@bugs.debian.org
<58689@bugs.debian.org>
Datum: 22. ���nora 2000 15:04
P���edm���t: Re: Bug#58689: Problem: database connection termination while
processing select command
"=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" wrote:
Package: postgresql
Version: 6.5.3-11Postgres reports error:
"pg.error pqReadData() -- backend closed the channel unexpectedly. This
probably means the backend terminated abnormally before or while
processing
the request."
Please turn on debugging in the backend by editing
/etc/postgresql/postmaster.init and setting the value of PGDEBUG to 2; you
should also turn on PGECHO.Then restart the postmaster (/etc/init.d/postgresql restart), rerun
the query and examine the end of the log to see what error is reported
there.
------- End of Forwarded Message
and this was the original message:
------- Forwarded Message
Date: Tue, 22 Feb 2000 12:07:42 +0100
From: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" <Vladimir.Benes@pvt.cz>
To: <submit@bugs.debian.org>
cc: "=?iso-8859-2?Q?M=FChlpachr_Michal?=" <michalm@pvt.net>
Subject: Bug#58689: Problem: database connection termination while processing s
elect command
Package: postgresql
Version: 6.5.3-11
Postgres reports error:
"pg.error pqReadData() -- backend closed the channel unexpectedly. This
probably means the backend terminated abnormally before or while processing
the request."
This error is produced by processing of this correct instruction:
select comm_type,name,tot_bytes,tot_packets
from flow_sums_days_send_200002_view
where day='2000-02-21' and name not like '@%'
union all
select comm_type,name,tot_bytes,tot_packets
from flow_sums_days_receive_200002_view
where day='2000-02-21' and name not like '@%'
Both flow_sums_days_send_200002_view and
flow_sums_days_receive_200002_view are views upon table with very many rows
(today about 3 000 000). I guess limit of this data count about 10 000 000
rows.
This operation can run arbitrary long - never mind. The program
providing this select (one times per day) inserts every 5 minut new data
into this table.
I tried stop this program (daemon) and then I ran this select from psql
(with clause "limit 10"). It was success (no database session termination).
I'am sure that any TIMEOUT expired.
Perhaps cause of this problem is "commuting" of insert commands at time
when this select is executed. I can remove clause "union all" and the
program can perform sleep instruction before select processing BUT then this
problem will occures later again.
My environment at /etc/postgresql/postmaster.init:
PGBACKENDCOUNT=64
PGBUFFERS=2048
PGSORTMEM=262144
KERNEL_FILE_MAX=1032
Thank You very much, V. Benes
___________________________________________________
Ing. Vladimir Benes, pvt.net
PVT, a.s., OZ Chomutov
e-mail: vladimir.benes@pvt.cz, vladimir.benes@sms.paegas.cz
------- End of Forwarded Message
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"The LORD bless thee, and keep thee; The LORD make his
face shine upon thee, and be gracious unto thee; The
LORD lift up his countenance upon thee, and give thee
peace." Numbers 6:24-26
From bouncefilter Tue Feb 22 10:06:12 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA86370
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 10:05:26 -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 LAA74954;
Tue, 22 Feb 2000 11:02:42 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 22 Feb 2000 11:02:42 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <200002221407.JAA15051@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0002221101590.86931-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 22 Feb 2000, Bruce Momjian wrote:
Yes, that is what I will do by going through CVS. It is better for Marc
to just specify the release and wait for my full release blurb coming in
a few days.
'K, will do that ... I also wanted to give a day for the miror sites to
pick up the beta ...
From bouncefilter Tue Feb 22 10:26:13 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA90957;
Tue, 22 Feb 2000 10:25:11 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA16513;
Tue, 22 Feb 2000 07:23:44 -0800 (PST)
Message-Id: <3.0.1.32.20000222070954.010af070@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 22 Feb 2000 07:09:54 -0800
To: Peter Eisentraut <peter_e@gmx.net>, Bruce Momjian <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
Cc: Tatsuo Ishii <t-ishii@sra.co.jp>, scrappy@hub.org, tgl@sss.pgh.pa.us,
webmaster@postgreSQL.org, pgsql-hackers@postgreSQL.org
In-Reply-To: <Pine.GSO.4.02A.10002221256140.14754-100000@Haj.DoCS.UU.SE>
References: <200002220509.AAA27880@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 12:58 PM 2/22/00 +0100, Peter Eisentraut wrote:
Yes and no. I never had anything like this. I was afraid to get crossed up
with Jan. Anyway, to add/drop unique constraints create/drop the index. To
add/drop foreign keys, use create/drop constraint trigger(????).
To add a foreign key try "alter table foo add foreign key(column)
references bar".
You'll like what you see.
- 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 Feb 22 10:25:13 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA90751
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 10:24:26 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA16522;
Tue, 22 Feb 2000 07:23:46 -0800 (PST)
Message-Id: <3.0.1.32.20000222071240.0108fdb0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 22 Feb 2000 07:12:40 -0800
To: sszabo@bigpanda.com, Ed Loehr <eloehr@austin.rr.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <200002221215.HAA10531@homeworld.bigpanda.org>
References: <Your message of "Tue,
22 Feb 2000 00:34:01 CST." <38B22DD9.99FFAB3D@austin.rr.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 07:15 AM 2/22/00 -0500, sszabo@bigpanda.com wrote:
* You can make both column and table constraints for foreign key
constraints. Currently, column FK constraints may not
specify NOT DEFERRABLE or INITIALLY (DEFERRED|IMMEDIATE)
due to shift/reduce problems in the parser.
Fixed by Thomas, I believe...though I've not tested it myself.
- 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 Feb 22 10:25:19 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA90757;
Tue, 22 Feb 2000 10:24: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 LAA75074;
Tue, 22 Feb 2000 11:24:27 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 22 Feb 2000 11:24:26 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-announce@postgreSQL.org
cc: pgsql-hackers@postgreSQL.org
Subject: PostgreSQL v7.0 goes Beta ...
Message-ID: <Pine.BSF.4.21.0002211940040.86931-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Feb 22, 2000
Today, after 8 months of intensive development since our last release,
the PostgreSQL Global Development Group is proud to announce the first
Beta release of PostgreSQL 7.0.
Available at ftp://ftp.postgresql.org/pub/postgresql-7.0beta1.tar.gz and
mirror sites around the world, this represents our first public view of
the upcoming release, schedualed for April 1st.
Please report any bugs to pgsql-bugs@postgresql.org ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Tue Feb 22 10:47:13 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 KAA96710
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 10:46:20 -0500 (EST) (envelope-from vev@michvhf.com)
Received: (qmail 15314 invoked by uid 1001); 22 Feb 2000 15:46:06 -0000
Date: Tue, 22 Feb 2000 10:46:06 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: The Hermit Hacker <scrappy@hub.org>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <Pine.BSF.4.21.0002221101590.86931-100000@thelab.hub.org>
Message-ID: <Pine.BSF.4.05.10002221044480.14970-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 22 Feb 2000, The Hermit Hacker wrote:
On Tue, 22 Feb 2000, Bruce Momjian wrote:
Yes, that is what I will do by going through CVS. It is better for Marc
to just specify the release and wait for my full release blurb coming in
a few days.'K, will do that ... I also wanted to give a day for the miror sites to
pick up the beta ...
Anyone have a **SHORT** list of highlights for the initial website
announcement?
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 Feb 22 10:49:13 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 KAA97704
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 10:48:39 -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 QAA26605
for <pgsql-hackers@postgreSQL.org>; Tue, 22 Feb 2000 16:48:36 +0100
Date: Tue, 22 Feb 2000 16:48:35 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Cache query (PREPARE/EXECUTE)
Message-ID: <Pine.LNX.3.96.1000222160403.23918A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi,
as I said, I tring implement PREPARE / EXECUTE command for user a
controllable query cache (in TODO: Cache most recent query plan(s)).
I have implement first usable version now (I know that it is not
interesting for current feature-freeze state, but I believe that
it is interesting for next release and for major developers). See:
test=# prepare sel as select * from tab where id = $1 and data
like $2 using int, text;
PREPARE
test=# execute sel using 1, '%a';
id | data
----+------
1 | aaaa
(1 row)
test=# prepare ins as insert into tab (data) values($1) using text;
PREPARE
test=# execute ins_tab using 'cccc';
INSERT 18974 1
The queryTree and planTree are save in hash table and in the
TopMemoryContext (Is it good space for this cache?). All is
without change-schema detection (IMHO is user problem if he
changes DB schema and use old cached plan). In future I try
add any 'change-schema' detection (to alter/drop table,rule..etc).
I'am not sure with syntax, now is:
PREPARE name AS optimizable-statement [ USING type, ... ]
EXECUTE name [ USING value, ... ]
Comments? Suggestions? (SQL92?)
(Note: I try test speed and speed for cached query plan (select) executed
via EXECUTE rise very very up (70% !).)
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 Tue Feb 22 10:50:13 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 KAA98250
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 10:50: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 KAA23582;
Tue, 22 Feb 2000 10:50:03 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error
messages
In-reply-to: <Pine.GSO.4.02A.10002221316290.14754-100000@Haj.DoCS.UU.SE>
References: <Pine.GSO.4.02A.10002221316290.14754-100000@Haj.DoCS.UU.SE>
Comments: In-reply-to Peter Eisentraut <e99re41@DoCS.UU.SE>
message dated "Tue, 22 Feb 2000 13:18:25 +0100"
Date: Tue, 22 Feb 2000 10:50:03 -0500
Message-ID: <23579.951234603@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
... Somewhere in between vanilla lex and flex is also POSIX lex,
which does support exclusive start conditions but no <<EOF>>.
I noticed that in the flex manual. Does it help us any? That is,
are there a useful number of lexes out there that do the full POSIX
spec? If flex is our only real choice for exclusive start conditions
then it's pointless to avoid <<EOF>>.
Anyone for getting rid of GNU make?
No ;-). GNU make has enough important features that there is no
near-equivalent non-GNU make. VPATH, for example. One thing I hope
we will be able to do sometime soon is build in an object directory
tree separate from the source tree... can't realistically do that
with any non-GNU make that I've heard of.
regards, tom lane
From bouncefilter Tue Feb 22 11:01:14 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 LAA08990
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 11:01: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
KAA29455;
Tue, 22 Feb 2000 10:51:47 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002221551.KAA29455@candle.pha.pa.us>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <Pine.BSF.4.21.0002221101590.86931-100000@thelab.hub.org> from
The
Hermit Hacker at "Feb 22, 2000 11:02:42 am"
To: The Hermit Hacker <scrappy@hub.org>
Date: Tue, 22 Feb 2000 10:51:47 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Tue, 22 Feb 2000, Bruce Momjian wrote:
Yes, that is what I will do by going through CVS. It is better for Marc
to just specify the release and wait for my full release blurb coming in
a few days.'K, will do that ... I also wanted to give a day for the miror sites to
pick up the beta ...
The cvs logs since 6.5.0 are 108k lines, and the merged file with
duplicates removed is 21k lines. Man, that's big.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 22 11:08:16 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 LAA12282
for <pgsql-hackers@postgresql.org>;
Tue, 22 Feb 2000 11:07:48 -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 LAA06176
for <pgsql-hackers@postgresql.org>; Tue, 22 Feb 2000 11:07:49 -0500
Message-ID: <38B2B44F.A0078699@wgcr.org>
Date: Tue, 22 Feb 2000 11:07:43 -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: 7.0beta1-0.2 testing RPMS are now available.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Testing RPMs for the 7.0beta1 release are now available on
ftp.postgresql.org. Please note that these RPMS are BETA -- the
packaging is still rough in spots. It would not be a good idea to try
to upgrade a production system from the stable 6.5.3-3 RPM set to this
set -- please use a development system to test with. The following are
known to be things that need fixing that are packaging related:
1.) Alpha patches are needed -- Ryan K or Uncle George?
2.) Better logging support -- the current logging frankly stinks.
3.) Smoother upgrade from previous releases -- the only major change is
the location of PGDATA, which is now /var/lib/pgsql/data, from
/var/lib/pgsql -- you will need to move the data over manually.
4.) Currently I am not using pg_ctl -- this will be implemented in a
future beta RPM.
5.) This release is lacking pl/perl due to my Linux system not building
plperl.so -- I am looking into it, but I didn't want to delay the first
preliminary release, as I want people to bang hard on these RPMS.
6.) Logrotate functionality is implemented, but at high cost -- each
time the log is rolled, postmaster has to be restarted. If you do not
want log rolling, remove /etc/logrotate.d/postgres.
7.) Logging is done to /var/log/postgresql -- however, for whatever
reason postmaster still spouts debugging messages to the tty -- even
after a 2>&1 redirect. Logging is not at this time timestamped -- but
it will be as I get feedback about the logging.
If you notice something I left out, let me know. Above all read
/usr/doc/postgresql-7.0beta1/README.rpm -- there is more documentation
there about what I know is broken in this very preliminary RPM, and
other changes.
RPMs are located at ftp.postgresql.org/pub/bindist/RPM/beta
Binaries have only been generated for RedHat 6.1/Intel -- I will be
building RedHat 5.2/Intel RPM's sometime later this week.
If you wish to rebuild from the source RPM, you need a RedHat 6.1 system
with C development, C++ development, X development, Perl, Tcl/Tk, and
python-devel installed.
On a minor note, there is one additional package -- postgresql-tk, which
contains the tk client and pgaccess, which was removed from the
postgresql-tcl package due to some people running X-less servers that
wanted to use the tcl client and pltcl.
Regression passes on these binaries under RedHat 6.1.
Let me know of any problems you find by either e-mailing me direct or by
e-mailing pgsql-ports@postgresql.org.
TIA
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Tue Feb 22 11:13:21 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 LAA13692
for <pgsql-hackers@postgresql.org>;
Tue, 22 Feb 2000 11:12:29 -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 LAA23761;
Tue, 22 Feb 2000 11:12:15 -0500 (EST)
To: Jeroen van Vianen <jeroen@design.nl>
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error
messages
In-reply-to: <4.2.2.20000222103948.00ac8d10@mail.design.nl>
References: <4.2.0.58.20000220151757.00956ba0@mail.design.nl>
<4.2.2.20000222103948.00ac8d10@mail.design.nl>
Comments: In-reply-to Jeroen van Vianen <jeroen@design.nl>
message dated "Tue, 22 Feb 2000 10:55:13 +0100"
Date: Tue, 22 Feb 2000 11:12:14 -0500
Message-ID: <23758.951235934@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Jeroen van Vianen <jeroen@design.nl> writes:
What I see now is something like this (for psql):
psql sends a query
psql reads response
if response is error
get error location and find context in which error occurred
print error message, with error location and context
otherwise
do what it used to do
and for the other interfaces nothing changes.
This is something I might be able to implement for 7.1.
This looks much better to me than doing it in the backend. What still
needs a little thought is how to send back the error location from
backend to client app.
I'd be inclined to say that the location info should be imbedded as
text in the existing textual error message, rather than trying to add
a separate message with a machine-readable location value. The first
way is much less likely to create compatibility problems with old client
apps. One way to do it is to say that if the last line of the error
message looks like
Error-location: nnn
then libpq should recognize that, strip the line out of the saved
textual error message, and make the location value available through
a new API call.
The reason I suggest a label is that we could further extend this
protocol to handle some other things that people have been griping
about for a long time: providing identifying error code numbers that
client code could rely on instead of trying to match against the error
text, and separating out the info about which routine generated the
error (which is mighty handy for backend debugging but is useless
info for Joe Average user). Someday the message being sent back
might look less like
ERROR: relation_info: Relation 12345 not found
and more like
ERROR: Failed to find relation OID 12345 in system catalogs
Error-code: 4242
Reporting-routine: relation_info, plancat.c line 543
of which only the first line is really meant for the user.
Of course, making that happen will be a lot of work, and I'm not
asking you to volunteer for it. But what you do now should fit
in with further development of the error handling stuff...
regards, tom lane
From bouncefilter Tue Feb 22 11:21:14 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 LAA16302
for <pgsql-hackers@postgresql.org>;
Tue, 22 Feb 2000 11:20:44 -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 LAA23844;
Tue, 22 Feb 2000 11:20:24 -0500 (EST)
To: Alessio Bragadini <alessio@albourne.com>
cc: PostgreSQL Hacker <pgsql-hackers@postgresql.org>,
Adriaan Joubert <a.joubert@albourne.com>
Subject: Re: [HACKERS] Big join breaks psql
In-reply-to: <38B27283.12AEB679@albourne.com>
References: <38B27283.12AEB679@albourne.com>
Comments: In-reply-to Alessio Bragadini <alessio@albourne.com>
message dated "Tue, 22 Feb 2000 13:26:59 +0200"
Date: Tue, 22 Feb 2000 11:20:24 -0500
Message-ID: <23841.951236424@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Alessio Bragadini <alessio@albourne.com> writes:
The following (rather long) query run fine for some time when executed
through Micro$oft Query via Psqlodbc. We never tried it under psql.
Today it appeared broken (some trickery on the Excel worksheet seems to
have fix that) and for the first time I tried to run it from the command
line. I never managed, psql always breaks in the same way:
Try doing
set ksqo = 'on';
in psql before you run the query. I think the ODBC driver does that for
you automatically.
The regular 6.5 optimizer tends to blow up when faced with large
OR-of-ANDs WHERE clauses. 7.0 will be a lot better about it...
but in the meantime you need the KSQO hack.
regards, tom lane
From bouncefilter Tue Feb 22 11:25:14 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 LAA18263
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 11:25: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
LAA00720;
Tue, 22 Feb 2000 11:24:10 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002221624.LAA00720@candle.pha.pa.us>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <Pine.BSF.4.05.10002221044480.14970-100000@paprika.michvhf.com>
from Vince Vielhaber at "Feb 22, 2000 10:46:06 am"
To: Vince Vielhaber <vev@michvhf.com>
Date: Tue, 22 Feb 2000 11:24:10 -0500 (EST)
CC: The Hermit Hacker <scrappy@hub.org>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Working on that now. Give me until the end of the day. I will have the
usual paragraphs and a long list. Looks like no billable work today.
On Tue, 22 Feb 2000, The Hermit Hacker wrote:
On Tue, 22 Feb 2000, Bruce Momjian wrote:
Yes, that is what I will do by going through CVS. It is better for Marc
to just specify the release and wait for my full release blurb coming in
a few days.'K, will do that ... I also wanted to give a day for the miror sites to
pick up the beta ...Anyone have a **SHORT** list of highlights for the initial website
announcement?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
==========================================================================
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 22 11:28:14 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA19474
for <pgsql-hackers@postgresql.org>;
Tue, 22 Feb 2000 11:27:48 -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 MAA75514;
Tue, 22 Feb 2000 12:27:41 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 22 Feb 2000 12:27:40 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Cache query (PREPARE/EXECUTE)
In-Reply-To: <Pine.LNX.3.96.1000222160403.23918A-100000@ara.zf.jcu.cz>
Message-ID: <Pine.BSF.4.21.0002221223460.86931-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 22 Feb 2000, Karel Zak - Zakkr wrote:
The queryTree and planTree are save in hash table and in the
TopMemoryContext (Is it good space for this cache?). All is
without change-schema detection (IMHO is user problem if he
changes DB schema and use old cached plan). In future I try
Just curious, but a new 'PREPARE name AS...' with the same name just
overrides the previously saved plan?
Actually, can someone who may know the internals of DBI comment on
this? If I have a CGI that runs the same SELECT call each and every time,
this would come in handy ... but how does DBI do its prepare? Would it
set a new name for each invocation, so you would have several 'cached
plans' for the exact same SELECT call?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Tue Feb 22 11:33:19 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 LAA21981;
Tue, 22 Feb 2000 11:32:56 -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 LAA23938;
Tue, 22 Feb 2000 11:32:51 -0500 (EST)
To: Jose Soares <jose@sferacarta.com>
cc: hackers <pgsql-hackers@postgreSQL.org>,
general <pgsql-general@postgreSQL.org>
Subject: Re: [HACKERS] TRANSACTIONS
In-reply-to: <38B27760.DB921B57@sferacarta.com>
References: <38B27760.DB921B57@sferacarta.com>
Comments: In-reply-to Jose Soares <jose@sferacarta.com>
message dated "Tue, 22 Feb 2000 12:47:44 +0100"
Date: Tue, 22 Feb 2000 11:32:51 -0500
Message-ID: <23935.951237171@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Jose Soares <jose@sferacarta.com> writes:
-------------------------------------------------------
Interbase, Oracle,Informix,Solid,Ms-Access,DB2:
-------------------------------------------------------
connect hygea.gdb;
create table temp(a int);
insert into temp values (1);
insert into temp values (1000000000000000000000000000000000);
commit;
select * from temp;
arithmetic exception, numeric overflow, or string truncation
A
===========
1
I would like to know what the Standard says and who is in the rigth path
PostgreSQL or the others, considering the two examples reported below.
I think those other guys are unquestionably failing to conform to SQL92.
6.10 general rule 3.a says
a) If SD is exact numeric or approximate numeric, then
Case:
i) If there is a representation of SV in the data type TD
that does not lose any leading significant digits after
rounding or truncating if necessary, then TV is that rep-
resentation. The choice of whether to round or truncate is
implementation-defined.
ii) Otherwise, an exception condition is raised: data exception-
numeric value out of range.
and 3.3.4.1 says
The phrase "an exception condition is raised:", followed by the
name of a condition, is used in General Rules and elsewhere to
indicate that the execution of a statement is unsuccessful, ap-
plication of General Rules, other than those of Subclause 12.3,
"<procedure>", and Subclause 20.1, "<direct SQL statement>", may
be terminated, diagnostic information is to be made available,
and execution of the statement is to have no effect on SQL-data or
schemas. The effect on <target specification>s and SQL descriptor
areas of an SQL-statement that terminates with an exception condi-
tion, unless explicitly defined by this International Standard, is
implementation-dependent.
I see no way that allowing the transaction to commit after an overflow
can be called consistent with the spec.
regards, tom lane
From bouncefilter Tue Feb 22 11:35:14 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 LAA22925
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 11:35:09 -0500 (EST) (envelope-from vev@michvhf.com)
Received: (qmail 15508 invoked by uid 1001); 22 Feb 2000 16:35:11 -0000
Date: Tue, 22 Feb 2000 11:35:11 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: The Hermit Hacker <scrappy@hub.org>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <200002221624.LAA00720@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.05.10002221134210.14970-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 22 Feb 2000, Bruce Momjian wrote:
Working on that now. Give me until the end of the day. I will have the
usual paragraphs and a long list. Looks like no billable work today.
Ok. I'm using Marc's announcement for the announcements and news, when
I get yours I'll replace the one on news and put in a pointer.
Vince.
On Tue, 22 Feb 2000, The Hermit Hacker wrote:
On Tue, 22 Feb 2000, Bruce Momjian wrote:
Yes, that is what I will do by going through CVS. It is better for Marc
to just specify the release and wait for my full release blurb coming in
a few days.'K, will do that ... I also wanted to give a day for the miror sites to
pick up the beta ...Anyone have a **SHORT** list of highlights for the initial website
announcement?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
==========================================================================
--
==========================================================================
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 Feb 22 11:57:14 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 LAA28703
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 11:57:01 -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 LAA24092;
Tue, 22 Feb 2000 11:56:41 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PostgreSQL v7.0 goes Beta ...
In-reply-to: <Pine.BSF.4.21.0002211940040.86931-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0002211940040.86931-100000@thelab.hub.org>
Comments: In-reply-to The Hermit Hacker <scrappy@hub.org>
message dated "Tue, 22 Feb 2000 11:24:26 -0400"
Date: Tue, 22 Feb 2000 11:56:41 -0500
Message-ID: <24089.951238601@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
Available at ftp://ftp.postgresql.org/pub/postgresql-7.0beta1.tar.gz and
mirror sites around the world, this represents our first public view of
the upcoming release, schedualed for April 1st.
Hmm, is it bad luck to plan a release for April Fools' Day?
regards, tom lane
From bouncefilter Tue Feb 22 12:07:14 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 MAA31660
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 12:06:20 -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 MAA24191;
Tue, 22 Feb 2000 12:06:12 -0500 (EST)
To: "Oliver Elphick" <olly@lfix.co.uk>
cc: pgsql-hackers@postgreSQL.org, Vladimir.Benes@pvt.cz
Subject: Re: [HACKERS] Out of memory problem (forwarded bug report)
In-reply-to: <200002221500.PAA11690@linda.lfix.co.uk>
References: <200002221500.PAA11690@linda.lfix.co.uk>
Comments: In-reply-to "Oliver Elphick" <olly@lfix.co.uk>
message dated "Tue, 22 Feb 2000 15:00:29 +0000"
Date: Tue, 22 Feb 2000 12:06:12 -0500
Message-ID: <24188.951239172@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Oliver Elphick" <olly@lfix.co.uk> writes:
Can someone advise, please, how to deal with this problem in 6.5.3?
My guess is that the cause is memory leaks during expression evaluation;
but without seeing the complete view definitions and underlying table
definitions, it's impossible to know what processing is being invoked
by this query...
regards, tom lane
From bouncefilter Tue Feb 22 12:13: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 MAA38360
for <pgsql-hackers@postgresql.org>;
Tue, 22 Feb 2000 12:12:32 -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 SAA30264;
Tue, 22 Feb 2000 18:12:22 +0100
Date: Tue, 22 Feb 2000 18:12:22 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Cache query (PREPARE/EXECUTE)
In-Reply-To: <Pine.BSF.4.21.0002221223460.86931-100000@thelab.hub.org>
Message-ID: <Pine.LNX.3.96.1000222173109.28804B-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 22 Feb 2000, The Hermit Hacker wrote:
On Tue, 22 Feb 2000, Karel Zak - Zakkr wrote:
The queryTree and planTree are save in hash table and in the
TopMemoryContext (Is it good space for this cache?). All is
without change-schema detection (IMHO is user problem if he
changes DB schema and use old cached plan). In future I tryJust curious, but a new 'PREPARE name AS...' with the same name just
overrides the previously saved plan?
Current code return you:
test=# prepare one as select * from aaa;
PREPARE
test=# prepare one as select * from aaa;
ERROR: Query plan with name 'one' already exist.
test=#
I prefer any DROP command instead overriding. But I open for any other
suggestions...
Actually, can someone who may know the internals of DBI comment on
this? If I have a CGI that runs the same SELECT call each and every time,
this would come in handy ... but how does DBI do its prepare? Would it
set a new name for each invocation, so you would have several 'cached
plans' for the exact same SELECT call?
I not sure if I good understand you. But..
1/ this cache is in memory only (it is not across re-connection persistent),
not save in any table..etc.
2/ you can have (equil or differnet) several plans in this cache, number of
plans is not limited.
3/ you can't have two same query's name in cache (name is hash key)
4/ after EXECUTE is plan still in cache, you can run it again...
potential usage:
example - you start connection to PG and you know that you need use
20x same question (example INSERT). You can PREPARE plan for this query,
and run fast EXECUTE only (instead 20x full insert);
Karel
From bouncefilter Tue Feb 22 12:17:16 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA39308
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 12:16:25 -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 NAA75873;
Tue, 22 Feb 2000 13:16:12 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 22 Feb 2000 13:16:12 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PostgreSQL v7.0 goes Beta ...
In-Reply-To: <24089.951238601@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0002221315350.86931-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 22 Feb 2000, Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
Available at ftp://ftp.postgresql.org/pub/postgresql-7.0beta1.tar.gz and
mirror sites around the world, this represents our first public view of
the upcoming release, schedualed for April 1st.Hmm, is it bad luck to plan a release for April Fools' Day?
Hrmmmm...since we've yet to actually release when we state we will, maybe
we'll release on time? :)
From bouncefilter Tue Feb 22 12:17:16 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 MAA39323
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 12:16:34 -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 MAA24217;
Tue, 22 Feb 2000 12:16:16 -0500 (EST)
To: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Cache query (PREPARE/EXECUTE)
In-reply-to: <Pine.LNX.3.96.1000222160403.23918A-100000@ara.zf.jcu.cz>
References: <Pine.LNX.3.96.1000222160403.23918A-100000@ara.zf.jcu.cz>
Comments: In-reply-to Karel Zak - Zakkr <zakkr@zf.jcu.cz>
message dated "Tue, 22 Feb 2000 16:48:35 +0100"
Date: Tue, 22 Feb 2000 12:16:15 -0500
Message-ID: <24214.951239775@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Karel Zak - Zakkr <zakkr@zf.jcu.cz> writes:
as I said, I tring implement PREPARE / EXECUTE command for user a
controllable query cache (in TODO: Cache most recent query plan(s)).
Looks cool.
The queryTree and planTree are save in hash table and in the
TopMemoryContext (Is it good space for this cache?).
Probably not. I'd suggest making a separate memory context for
this purpose --- they're cheap, and that gives you more control.
Look at the creation and use of CacheMemoryContext for an example.
I'am not sure with syntax, now is:
PREPARE name AS optimizable-statement [ USING type, ... ]
EXECUTE name [ USING value, ... ]
Comments? Suggestions? (SQL92?)
This seems to be quite at variance with SQL92, unfortunately, so it
might not be a good idea to use the same keywords they do...
regards, tom lane
From bouncefilter Tue Feb 22 12:33:25 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 MAA43340
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 12:32:37 -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 SAA30728;
Tue, 22 Feb 2000 18:30:48 +0100
Date: Tue, 22 Feb 2000 18:30:48 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Cache query (PREPARE/EXECUTE)
In-Reply-To: <24214.951239775@sss.pgh.pa.us>
Message-ID: <Pine.LNX.3.96.1000222182125.28804C-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 22 Feb 2000, Tom Lane wrote:
Karel Zak - Zakkr <zakkr@zf.jcu.cz> writes:
as I said, I tring implement PREPARE / EXECUTE command for user a
controllable query cache (in TODO: Cache most recent query plan(s)).Looks cool.
Thanks.
The queryTree and planTree are save in hash table and in the
TopMemoryContext (Is it good space for this cache?).Probably not. I'd suggest making a separate memory context for
this purpose --- they're cheap, and that gives you more control.
Look at the creation and use of CacheMemoryContext for an example.
Yes, I agree (TopMemoryContext was simpl for first hacking).
But I not sure how create new (across transaction persistent?)
MemoryContext. It needs new portal? (Sorry I not thoroughly explore
PG's memory management.)
I'am not sure with syntax, now is:
PREPARE name AS optimizable-statement [ USING type, ... ]
EXECUTE name [ USING value, ... ]Comments? Suggestions? (SQL92?)
This seems to be quite at variance with SQL92, unfortunately, so it
might not be a good idea to use the same keywords they do...
Hmm, I inspire with Jan's TODO item. What use:
CREATE PLAN
DROP PLAN
EXECUTE PLAN
IMHO these kaywords are better.
Karel
From bouncefilter Tue Feb 22 12:49:15 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 MAA47379;
Tue, 22 Feb 2000 12:48: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
MAA01451;
Tue, 22 Feb 2000 12:46:38 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002221746.MAA01451@candle.pha.pa.us>
Subject: Re: [ANNOUNCE] PostgreSQL v7.0 goes Beta ...
In-Reply-To: <02a901bf7d6c$1e59ba00$02010101@duncan> from Duncan Kinder at
"Feb
22, 2000 11:36:27 am"
To: Duncan Kinder <dckinder@mountain.net>
Date: Tue, 22 Feb 2000 12:46:38 -0500 (EST)
CC: The Hermit Hacker <scrappy@hub.org>, pgsql-announce@postgreSQL.org,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I am working on it now. Give me a day.
[Charset iso-8859-1 unsupported, filtering to ASCII...]
Marvelous.
May I ask what is new about v. 7.0?
Duncan C. Kinder
dckinder@mountain.net----- Original Message -----
From: The Hermit Hacker <scrappy@hub.org>
To: <pgsql-announce@postgreSQL.org>
Cc: <pgsql-hackers@postgreSQL.org>
Sent: Tuesday, February 22, 2000 7:24 AM
Subject: [ANNOUNCE] PostgreSQL v7.0 goes Beta ...Feb 22, 2000
Today, after 8 months of intensive development since our last release,
the PostgreSQL Global Development Group is proud to announce the first
Beta release of PostgreSQL 7.0.Available at ftp://ftp.postgresql.org/pub/postgresql-7.0beta1.tar.gz and
mirror sites around the world, this represents our first public view of
the upcoming release, schedualed for April 1st.Please report any bugs to pgsql-bugs@postgresql.org ...
Marc G. Fournier ICQ#7615664 IRC Nick:
Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary:scrappy@{freebsd|postgresql}.org
************
************
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 22 13:45:15 2000
Received: from correo.data.net.mx (correo.data.net.mx [200.13.16.5])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA60634
for <pgsql-hackers@postgresql.org>;
Tue, 22 Feb 2000 13:44:29 -0500 (EST)
(envelope-from nora@mailuno.com)
Received: from mailuno.com ([200.39.108.38]) by correo.data.net.mx
(Post.Office MTA v3.5.2 release 221 ID# 0-63037U22000L10200S0V35)
with ESMTP id mx for <pgsql-hackers@postgresql.org>;
Tue, 22 Feb 2000 12:43:52 -0600
Message-ID: <38B2D8BF.E1A40AFA@mailuno.com>
Date: Tue, 22 Feb 2000 12:43:11 -0600
From: Nora Luz Escobar =?iso-8859-1?Q?L=F3pez?= <nora@mailuno.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: subcription
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From bouncefilter Tue Feb 22 14:00:17 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA63414;
Tue, 22 Feb 2000 13:59:32 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id KAA14390;
Tue, 22 Feb 2000 10:58:38 -0800 (PST)
Message-Id: <3.0.1.32.20000222104716.010bd050@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 22 Feb 2000 10:47:16 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, Jose Soares <jose@sferacarta.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] TRANSACTIONS
Cc: hackers <pgsql-hackers@postgreSQL.org>,
general <pgsql-general@postgreSQL.org>
In-Reply-To: <23935.951237171@sss.pgh.pa.us>
References: <38B27760.DB921B57@sferacarta.com>
<38B27760.DB921B57@sferacarta.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 11:32 AM 2/22/00 -0500, Tom Lane wrote:
I see no way that allowing the transaction to commit after an overflow
can be called consistent with the spec.
You are absolutely right. The whole point is that either a) everything
commits or b) nothing commits.
Having some kinds of exceptions allow a partial commit while other
exceptions rollback the transaction seems like a very error-prone
programming environment to me.
- 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 Feb 22 14:01:15 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA63908
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 14:00:24 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id KAA14521;
Tue, 22 Feb 2000 10:58:54 -0800 (PST)
Message-Id: <3.0.1.32.20000222104954.0106e0c0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 22 Feb 2000 10:49:54 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, The Hermit Hacker <scrappy@hub.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] PostgreSQL v7.0 goes Beta ...
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <24089.951238601@sss.pgh.pa.us>
References: <Pine.BSF.4.21.0002211940040.86931-100000@thelab.hub.org>
<Pine.BSF.4.21.0002211940040.86931-100000@thelab.hub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 11:56 AM 2/22/00 -0500, Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
Available at ftp://ftp.postgresql.org/pub/postgresql-7.0beta1.tar.gz and
mirror sites around the world, this represents our first public view of
the upcoming release, schedualed for April 1st.Hmm, is it bad luck to plan a release for April Fools' Day?
It has always been my favorite release date. We plan to release
the first full PG port of Ars Digita's web toolkit, including ecommmerce,
on April Fools Day. I didn't realize that was the offical
PG7.0 release date but since we plan to use PG7.0 as our supported
platform I like the date even 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 Tue Feb 22 14:00:16 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 NAA63419
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 13:59:37 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by clio.trends.ca (8.9.3+Sun/8.9.3) with ESMTP id NAA20237
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 13:59:33 -0500 (EST)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id KAA14529;
Tue, 22 Feb 2000 10:58:56 -0800 (PST)
Message-Id: <3.0.1.32.20000222105607.0106c2f0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 22 Feb 2000 10:56:07 -0800
To: Karel Zak - Zakkr <zakkr@zf.jcu.cz>, Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Cache query (PREPARE/EXECUTE)
Cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
In-Reply-To: <Pine.LNX.3.96.1000222182125.28804C-100000@ara.zf.jcu.cz>
References: <24214.951239775@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 06:30 PM 2/22/00 +0100, Karel Zak - Zakkr wrote:
Yes, I agree (TopMemoryContext was simpl for first hacking).
But I not sure how create new (across transaction persistent?)
MemoryContext. It needs new portal? (Sorry I not thoroughly explore
PG's memory management.)
Jan is caching the plans needed for referential integrity checking
and referential actions - look at ri_triggers.c in src/backend/utils/adt.
ri_InitHashTables initializes the RI cache.
(I *assume* Jan, with his great experience, is doing it right, I'm
in no position to judge!)
- 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 Feb 22 11:37:18 2000
Received: from Namesrv.Mountain.Net (root@Namesrv.Mountain.Net [198.77.1.1])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA23277;
Tue, 22 Feb 2000 11:36:32 -0500 (EST)
(envelope-from dckinder@mountain.net)
Received: from duncan (AM6-28.Wheeling-WV.Mountain.Net [198.77.41.128])
by Namesrv.Mountain.Net (8.9.3/8.9.0) with SMTP id LAA13074;
Tue, 22 Feb 2000 11:36:27 -0500 (EST)
Message-ID: <02a901bf7d6c$1e59ba00$02010101@duncan>
Reply-To: "Duncan Kinder" <dckinder@mountain.net>
From: "Duncan Kinder" <dckinder@mountain.net>
To: "The Hermit Hacker" <scrappy@hub.org>, <pgsql-announce@postgreSQL.org>
Cc: <pgsql-hackers@postgreSQL.org>
References: <Pine.BSF.4.21.0002211940040.86931-100000@thelab.hub.org>
Subject: Re: [ANNOUNCE] PostgreSQL v7.0 goes Beta ...
Date: Tue, 22 Feb 2000 11:36:27 -0800
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.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Marvelous.
May I ask what is new about v. 7.0?
Duncan C. Kinder
dckinder@mountain.net
----- Original Message -----
From: The Hermit Hacker <scrappy@hub.org>
To: <pgsql-announce@postgreSQL.org>
Cc: <pgsql-hackers@postgreSQL.org>
Sent: Tuesday, February 22, 2000 7:24 AM
Subject: [ANNOUNCE] PostgreSQL v7.0 goes Beta ...
Feb 22, 2000
Today, after 8 months of intensive development since our last release,
the PostgreSQL Global Development Group is proud to announce the first
Beta release of PostgreSQL 7.0.Available at ftp://ftp.postgresql.org/pub/postgresql-7.0beta1.tar.gz and
mirror sites around the world, this represents our first public view of
the upcoming release, schedualed for April 1st.Please report any bugs to pgsql-bugs@postgresql.org ...
Marc G. Fournier ICQ#7615664 IRC Nick:
Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary:
scrappy@{freebsd|postgresql}.org
************
From bouncefilter Tue Feb 22 14:55:16 2000
Received: from feivel.fam-meskes.de (h-62.96.159.70.host.de.colt.net
[62.96.159.70]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA84871
for <pgsql-hackers@postgresql.org>;
Tue, 22 Feb 2000 14:54:15 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 829762BB95; Tue, 22 Feb 2000 20:52:54 +0100 (CET)
Date: Tue, 22 Feb 2000 20:52:54 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: ECPG / Release
Message-ID: <20000222205254.A2371@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
Sender: michael@fam-meskes.de
When will we release 7.0? I just checked and found that I'm way behind my
schedule. The parser is in sync, but there are quite some open bugs. So
hopefully there is either enough time left or someone who would like to
spend some time on fixing bugs. :-)
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 Tue Feb 22 15:19:21 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 PAA90346
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 15:19:00 -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 VAA00855;
Tue, 22 Feb 2000 21:18:47 +0100
Date: Tue, 22 Feb 2000 21:18:47 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Don Baccus <dhogaza@pacifier.com>
cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Cache query (PREPARE/EXECUTE)
In-Reply-To: <3.0.1.32.20000222105607.0106c2f0@mail.pacifier.com>
Message-ID: <Pine.LNX.3.96.1000222211018.704A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 22 Feb 2000, Don Baccus wrote:
At 06:30 PM 2/22/00 +0100, Karel Zak - Zakkr wrote:
Yes, I agree (TopMemoryContext was simpl for first hacking).
But I not sure how create new (across transaction persistent?)
MemoryContext. It needs new portal? (Sorry I not thoroughly explore
PG's memory management.)Jan is caching the plans needed for referential integrity checking
and referential actions - look at ri_triggers.c in src/backend/utils/adt.
ri_InitHashTables initializes the RI cache.
My cache table routines for PREPARE = Jan's RI routines :-)
(I copy and a little modify Jan's code (*Thanks* Jan for good inspiration..).
But if I good look at Jan use SPI context for this, not any specific
context.
Karel
From bouncefilter Tue Feb 22 15:33:19 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA99541;
Tue, 22 Feb 2000 15:32: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 QAA77393;
Tue, 22 Feb 2000 16:32:32 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 22 Feb 2000 16:32:32 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Michael Meskes <meskes@postgreSQL.org>
cc: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Splitting distributions (Was: Re: [HACKERS] ECPG / Release)
In-Reply-To: <20000222205254.A2371@fam-meskes.de>
Message-ID: <Pine.BSF.4.21.0002221624070.86931-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 22 Feb 2000, Michael Meskes wrote:
When will we release 7.0? I just checked and found that I'm way behind my
schedule. The parser is in sync, but there are quite some open bugs. So
hopefully there is either enough time left or someone who would like to
spend some time on fixing bugs. :-)
April 1st is what I announced, but I'll be shocked if that actually
happens :) You should have loads of time ...
As far as I'm concerned, stuff like ECPG and JDBC and ODBC are changeable
pretty much up to the release date ... they are generally touched, and
modified by only one person ...
One of the things I'd like to look at for 7.1 is start to split off the
distributions ... we're up to a 7meg distribution and growing ...
We should be able to do a pgsql-docs.tar.gz and pgsql-src.tar.gz at the
very least ... putting 'doc' in a seperate tar file would reduce the size
by ~3meg:
total 3024
-rw-r--r-- 1 scrappy wheel 2969424 Feb 22 15:27 doc.tar.gz
Actually, is there a reason we can't do this now? I can change the 'tar
build' system so that we have split systems that way ... this would at
least safe testers from downloading 3meg worth of tar file that most
likely won't get touched often ...
I'm going to do this tonight, put it up and see what ppl thing ... if
nothing else, it makes it easier for ppl to download smaller chunks ...
Marc G. Fournier ICQ#7615664 IRC
Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Tue Feb 22 15:47:26 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 PAA04166;
Tue, 22 Feb 2000 15:46:34 -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 PAA06707;
Tue, 22 Feb 2000 15:46:40 -0500
Message-ID: <38B2F5A7.C3989CAE@wgcr.org>
Date: Tue, 22 Feb 2000 15:46:31 -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: Michael Meskes <meskes@postgresql.org>,
PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: Re: Splitting distributions (Was: Re: [HACKERS] ECPG / Release)
References: <Pine.BSF.4.21.0002221624070.86931-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The Hermit Hacker wrote:
We should be able to do a pgsql-docs.tar.gz and pgsql-src.tar.gz at the
very least ... putting 'doc' in a seperate tar file would reduce the size
by ~3meg:
[snip]
I'm going to do this tonight, put it up and see what ppl thing ... if
nothing else, it makes it easier for ppl to download smaller chunks ...
Kindof like how the RPM distribution is split, but not as fine, right?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Tue Feb 22 15:56:17 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 PAA06756;
Tue, 22 Feb 2000 15:55:54 -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
PAA04289;
Tue, 22 Feb 2000 15:55:29 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002222055.PAA04289@candle.pha.pa.us>
Subject: Re: Splitting distributions (Was: Re: [HACKERS] ECPG / Release)
In-Reply-To: <Pine.BSF.4.21.0002221624070.86931-100000@thelab.hub.org> from
The
Hermit Hacker at "Feb 22, 2000 04:32:32 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Tue, 22 Feb 2000 15:55:29 -0500 (EST)
CC: Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
One of the things I'd like to look at for 7.1 is start to split off the
distributions ... we're up to a 7meg distribution and growing ...We should be able to do a pgsql-docs.tar.gz and pgsql-src.tar.gz at the
very least ... putting 'doc' in a seperate tar file would reduce the size
by ~3meg:total 3024
-rw-r--r-- 1 scrappy wheel 2969424 Feb 22 15:27 doc.tar.gzActually, is there a reason we can't do this now? I can change the 'tar
build' system so that we have split systems that way ... this would at
least safe testers from downloading 3meg worth of tar file that most
likely won't get touched often ...I'm going to do this tonight, put it up and see what ppl thing ... if
nothing else, it makes it easier for ppl to download smaller chunks ...
Seems like a good idea. Only RPM packages would have to know of the
split.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 22 16:17:20 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA17568;
Tue, 22 Feb 2000 16:16:33 -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 RAA77818;
Tue, 22 Feb 2000 17:16:29 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 22 Feb 2000 17:16:29 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Lamar Owen <lamar.owen@wgcr.org>
cc: Michael Meskes <meskes@postgresql.org>,
PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: Re: Splitting distributions (Was: Re: [HACKERS] ECPG / Release)
In-Reply-To: <38B2F5A7.C3989CAE@wgcr.org>
Message-ID: <Pine.BSF.4.21.0002221654210.86931-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 22 Feb 2000, Lamar Owen wrote:
The Hermit Hacker wrote:
We should be able to do a pgsql-docs.tar.gz and pgsql-src.tar.gz at the
very least ... putting 'doc' in a seperate tar file would reduce the size
by ~3meg:[snip]
I'm going to do this tonight, put it up and see what ppl thing ... if
nothing else, it makes it easier for ppl to download smaller chunks ...Kindof like how the RPM distribution is split, but not as fine, right?
Pretty much ... longer term goal, IMHO, is to make a more compact
distribution so that if I want libpq on a clint machine, I don't have to
download the whole backend code too ...
But, for now, I'm just creating simple .tar.gz files that all have to be
downloaded, but, for instance, for those with slow links, they don't have
to hope all 7meg gets down ... they can download smaller files.
I'm creating them right now, broken down as:
docs -> pgsql/docs
test -> pgsql/src/test
support -> pgsql/src/{interfaces,bin}
base -> pgsql (minus the above)
Basically, it makes this:
-rw-r--r-- 1 pgsql wheel 7543517 Feb 22 16:04 postgresql.snapshot.tar.gz
Download as:
-rw-r--r-- 1 pgsql wheel 2261079 Feb 22 16:06 postgresql.snapshot.base.tar.gz
-rw-r--r-- 1 pgsql wheel 2973217 Feb 22 16:04 postgresql.snapshot.docs.tar.gz
-rw-r--r-- 1 pgsql wheel 1318456 Feb 22 16:06 postgresql.snapshot.support.tar.gz
-rw-r--r-- 1 pgsql wheel 987847 Feb 22 16:05 postgresql.snapshot.test.tar.gz
I've just split the 7.0beta1.tar.gz file up also:
-rw-r--r-- 1 pgsql wheel 7533458 Feb 21 18:34 postgresql-7.0beta1.tar.gz
-rw-r--r-- 1 pgsql wheel 2260487 Feb 22 16:14 postgresql-7.0beta1.base.tar.gz
-rw-r--r-- 1 pgsql wheel 1310901 Feb 22 16:14 postgresql-7.0beta1.support.tar.gz
-rw-r--r-- 1 pgsql wheel 987270 Feb 22 16:13 postgresql-7.0beta1.test.tar.gz
-rw-r--r-- 1 pgsql wheel 2973182 Feb 22 16:13 postgresql-7.0beta1.docs.tar.gz
Vince, can you put something on the Web page showing the 'split' files as
well, so that ppl know they exist and can download those ones instead?
From bouncefilter Tue Feb 22 16:25:17 2000
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA19326
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 16:24:36 -0500 (EST) (envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.3/8.9.3) with SMTP id AAA05259
for <pgsql-hackers@postgreSQL.org>;
Wed, 23 Feb 2000 00:24:30 +0300 (GMT)
Date: Wed, 23 Feb 2000 00:24:30 +0300 (GMT)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: pgsql-hackers@postgreSQL.org
Subject: 'now' in 7.0
Message-ID: <Pine.GSO.3.96.SK.1000223000757.1714H-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi,
sorry if I miss something - there are so many changes in current
development and I didn't track them thoroughly in mailing list.
I've tried to port my db scheme which works with 6.5 to 7.0 and
got little problem:
create view www_auth as select a.account as user_name, a.password, b.nick as
group_name from users a, resources b, privilege_user_map c
where a.auth_id = c.auth_id and b.res_id = c.res_id and
(a.account_valid_until is null or a.account_valid_until > datetime('now'::text))
and c.perm_id = 1;
ERROR: No such function 'datetime' with the specified attributes
I had to use datetime('now'::text) as a workaround of bug in 6.5.3.
I tried just datetime('now') but still have the same problem.
Does the above view will works with now() ?
Another problem:
create table tt (i int4, a datetime default 'now');
doesn't works and I still need
create table tt (i int4, a datetime default now());
We have discussed this problem some time ago.
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
From bouncefilter Tue Feb 22 16:33:24 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA21435;
Tue, 22 Feb 2000 16:32: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 RAA77898;
Tue, 22 Feb 2000 17:32:19 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 22 Feb 2000 17:32:19 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: Splitting distributions (Was: Re: [HACKERS] ECPG / Release)
In-Reply-To: <200002222055.PAA04289@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0002221732110.86931-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 22 Feb 2000, Bruce Momjian wrote:
One of the things I'd like to look at for 7.1 is start to split off the
distributions ... we're up to a 7meg distribution and growing ...We should be able to do a pgsql-docs.tar.gz and pgsql-src.tar.gz at the
very least ... putting 'doc' in a seperate tar file would reduce the size
by ~3meg:total 3024
-rw-r--r-- 1 scrappy wheel 2969424 Feb 22 15:27 doc.tar.gzActually, is there a reason we can't do this now? I can change the 'tar
build' system so that we have split systems that way ... this would at
least safe testers from downloading 3meg worth of tar file that most
likely won't get touched often ...I'm going to do this tonight, put it up and see what ppl thing ... if
nothing else, it makes it easier for ppl to download smaller chunks ...Seems like a good idea. Only RPM packages would have to know of the
split.
Huh? *raised eyebrow*
From bouncefilter Tue Feb 22 17:12:17 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 RAA29837
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 17:11:33 -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 RAA25933;
Tue, 22 Feb 2000 17:11:29 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: Splitting distributions (Was: Re: [HACKERS] ECPG / Release)
In-reply-to: <Pine.BSF.4.21.0002221654210.86931-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0002221654210.86931-100000@thelab.hub.org>
Comments: In-reply-to The Hermit Hacker <scrappy@hub.org>
message dated "Tue, 22 Feb 2000 17:16:29 -0400"
Date: Tue, 22 Feb 2000 17:11:29 -0500
Message-ID: <25930.951257489@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
I'm creating them right now, broken down as:
docs -> pgsql/docs
test -> pgsql/src/test
support -> pgsql/src/{interfaces,bin}
base -> pgsql (minus the above)
One gripe on this --- the docs are sort-of optional, and the test stuff
is certainly optional, but the interfaces and bin directories are *not*
optional. It'd be a good idea to make sure this is noted on the webpage
or in the FTP directory's README file...
regards, tom lane
From bouncefilter Tue Feb 22 17:20:21 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 RAA31549;
Tue, 22 Feb 2000 17:19:59 -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
RAA05569;
Tue, 22 Feb 2000 17:19:20 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002222219.RAA05569@candle.pha.pa.us>
Subject: Re: Splitting distributions (Was: Re: [HACKERS] ECPG / Release)
In-Reply-To: <Pine.BSF.4.21.0002221654210.86931-100000@thelab.hub.org> from
The
Hermit Hacker at "Feb 22, 2000 05:16:29 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Tue, 22 Feb 2000 17:19:20 -0500 (EST)
CC: Lamar Owen <lamar.owen@wgcr.org>, Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Keep in mind psql needs the doc/src/sgml files for psql help.
On Tue, 22 Feb 2000, Lamar Owen wrote:
The Hermit Hacker wrote:
We should be able to do a pgsql-docs.tar.gz and pgsql-src.tar.gz at the
very least ... putting 'doc' in a seperate tar file would reduce the size
by ~3meg:[snip]
I'm going to do this tonight, put it up and see what ppl thing ... if
nothing else, it makes it easier for ppl to download smaller chunks ...Kindof like how the RPM distribution is split, but not as fine, right?
Pretty much ... longer term goal, IMHO, is to make a more compact
distribution so that if I want libpq on a clint machine, I don't have to
download the whole backend code too ...But, for now, I'm just creating simple .tar.gz files that all have to be
downloaded, but, for instance, for those with slow links, they don't have
to hope all 7meg gets down ... they can download smaller files.I'm creating them right now, broken down as:
docs -> pgsql/docs
test -> pgsql/src/test
support -> pgsql/src/{interfaces,bin}
base -> pgsql (minus the above)Basically, it makes this:
-rw-r--r-- 1 pgsql wheel 7543517 Feb 22 16:04 postgresql.snapshot.tar.gz
Download as:
-rw-r--r-- 1 pgsql wheel 2261079 Feb 22 16:06 postgresql.snapshot.base.tar.gz
-rw-r--r-- 1 pgsql wheel 2973217 Feb 22 16:04 postgresql.snapshot.docs.tar.gz
-rw-r--r-- 1 pgsql wheel 1318456 Feb 22 16:06 postgresql.snapshot.support.tar.gz
-rw-r--r-- 1 pgsql wheel 987847 Feb 22 16:05 postgresql.snapshot.test.tar.gzI've just split the 7.0beta1.tar.gz file up also:
-rw-r--r-- 1 pgsql wheel 7533458 Feb 21 18:34 postgresql-7.0beta1.tar.gz
-rw-r--r-- 1 pgsql wheel 2260487 Feb 22 16:14 postgresql-7.0beta1.base.tar.gz
-rw-r--r-- 1 pgsql wheel 1310901 Feb 22 16:14 postgresql-7.0beta1.support.tar.gz
-rw-r--r-- 1 pgsql wheel 987270 Feb 22 16:13 postgresql-7.0beta1.test.tar.gz
-rw-r--r-- 1 pgsql wheel 2973182 Feb 22 16:13 postgresql-7.0beta1.docs.tar.gzVince, can you put something on the Web page showing the 'split' files as
well, so that ppl know they exist and can download those ones instead?************
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 22 17:20:29 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 RAA31665;
Tue, 22 Feb 2000 17:20:12 -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
RAA05578;
Tue, 22 Feb 2000 17:19:50 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002222219.RAA05578@candle.pha.pa.us>
Subject: Re: Splitting distributions (Was: Re: [HACKERS] ECPG / Release)
In-Reply-To: <Pine.BSF.4.21.0002221732110.86931-100000@thelab.hub.org> from
The
Hermit Hacker at "Feb 22, 2000 05:32:19 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Tue, 22 Feb 2000 17:19:50 -0500 (EST)
CC: Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I'm going to do this tonight, put it up and see what ppl thing ... if
nothing else, it makes it easier for ppl to download smaller chunks ...Seems like a good idea. Only RPM packages would have to know of the
split.Huh? *raised eyebrow*
Don't RPM's have to know to download two tarballs?
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 22 17:21:18 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 RAA31799
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 17:21:00 -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
RAA05591;
Tue, 22 Feb 2000 17:20:35 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002222220.RAA05591@candle.pha.pa.us>
Subject: Re: Splitting distributions (Was: Re: [HACKERS] ECPG / Release)
In-Reply-To: <25930.951257489@sss.pgh.pa.us> from Tom Lane at "Feb 22,
2000 05:11:29 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 22 Feb 2000 17:20:35 -0500 (EST)
CC: The Hermit Hacker <scrappy@hub.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
The Hermit Hacker <scrappy@hub.org> writes:
I'm creating them right now, broken down as:
docs -> pgsql/docs
test -> pgsql/src/test
support -> pgsql/src/{interfaces,bin}
base -> pgsql (minus the above)One gripe on this --- the docs are sort-of optional, and the test stuff
is certainly optional, but the interfaces and bin directories are *not*
optional. It'd be a good idea to make sure this is noted on the webpage
or in the FTP directory's README file...
psql needs the sgml files for help, so none are optional, I think.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 22 17:32:18 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA34590
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 17:31:58 -0500 (EST)
(envelope-from chrisb@nimrod.itg.telstra.com.au)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
JAA04069; Wed, 23 Feb 2000 09:31:09 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdHfdiV_;
Wed Feb 23 09:30:52 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
JAA24153; Wed, 23 Feb 2000 09:30:51 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdH15N5_; Wed Feb 23 09:30:03 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id JAA00484;
Wed, 23 Feb 2000 09:30:02 +1100 (EST)
Received: from nimrod.itg.telecom.com.au (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
JAA28258; Wed, 23 Feb 2000 09:29:16 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <38B30D7E.740E44D2@nimrod.itg.telecom.com.au>
Date: Wed, 23 Feb 2000 09:28:14 +1100
From: Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Reply-To: chris@bitmead.com
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PostgreSQL v7.0 goes Beta ...
References: <Pine.BSF.4.21.0002211940040.86931-100000@thelab.hub.org>
<24089.951238601@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
Available at ftp://ftp.postgresql.org/pub/postgresql-7.0beta1.tar.gz and
mirror sites around the world, this represents our first public view of
the upcoming release, schedualed for April 1st.Hmm, is it bad luck to plan a release for April Fools' Day?
The benefit is that if you accidently stuff up and people lose all their
data, you can always fall back to "APRIL FOOL!". :-)
From bouncefilter Tue Feb 22 17:29:18 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 RAA33509
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 17:28:41 -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 RAA26073;
Tue, 22 Feb 2000 17:28:26 -0500 (EST)
To: Oleg Bartunov <oleg@sai.msu.su>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] 'now' in 7.0
In-reply-to: <Pine.GSO.3.96.SK.1000223000757.1714H-100000@ra>
References: <Pine.GSO.3.96.SK.1000223000757.1714H-100000@ra>
Comments: In-reply-to Oleg Bartunov <oleg@sai.msu.su>
message dated "Wed, 23 Feb 2000 00:24:30 +0300"
Date: Tue, 22 Feb 2000 17:28:25 -0500
Message-ID: <26070.951258505@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Oleg Bartunov <oleg@sai.msu.su> writes:
create view www_auth as select a.account as user_name, a.password, b.nick as
group_name from users a, resources b, privilege_user_map c
where a.auth_id = c.auth_id and b.res_id = c.res_id and
(a.account_valid_until is null or a.account_valid_until > datetime('now'::text))
and c.perm_id = 1;
ERROR: No such function 'datetime' with the specified attributes
Apparently the datetime() function got renamed to timestamp() in the
recent consolidation of date/time types. I'd actually recommend that
you write CURRENT_TIMESTAMP, which is the SQL-approved notation...
Does the above view will works with now() ?
That should work too.
Another problem:
create table tt (i int4, a datetime default 'now');
doesn't works and I still need
create table tt (i int4, a datetime default now());
? Works for me:
regression=# create table tt (i int4, a datetime default 'now');
CREATE
regression=# insert into tt values(1);
INSERT 653163 1
regression=# insert into tt values(1);
INSERT 653164 1
regression=# select * from tt;
i | a
---+------------------------
1 | 2000-02-22 17:15:16-05
1 | 2000-02-22 17:15:18-05
(2 rows)
although here also I think now() or CURRENT_TIMESTAMP would be safer
coding.
regards, tom lane
From bouncefilter Tue Feb 22 17:44:18 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 RAA37371
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 17:43:36 -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 RAA26204;
Tue, 22 Feb 2000 17:38:17 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: The Hermit Hacker <scrappy@hub.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: Splitting distributions (Was: Re: [HACKERS] ECPG / Release)
In-reply-to: <200002222220.RAA05591@candle.pha.pa.us>
References: <200002222220.RAA05591@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Tue, 22 Feb 2000 17:20:35 -0500"
Date: Tue, 22 Feb 2000 17:38:17 -0500
Message-ID: <26201.951259097@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
One gripe on this --- the docs are sort-of optional, and the test stuff
is certainly optional, but the interfaces and bin directories are *not*
optional. It'd be a good idea to make sure this is noted on the webpage
or in the FTP directory's README file...
psql needs the sgml files for help, so none are optional, I think.
But the tarball has a prebuilt psql help file, or should.
regards, tom lane
From bouncefilter Tue Feb 22 18:00:18 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 RAA52705;
Tue, 22 Feb 2000 17:59:45 -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 RAA07022;
Tue, 22 Feb 2000 17:59:45 -0500
Message-ID: <38B314D8.DE0275D2@wgcr.org>
Date: Tue, 22 Feb 2000 17:59:36 -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: The Hermit Hacker <scrappy@hub.org>,
Michael Meskes <meskes@postgresql.org>,
PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: Re: Splitting distributions (Was: Re: [HACKERS] ECPG / Release)
References: <200002222219.RAA05578@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
I'm going to do this tonight, put it up and see what ppl thing ... if
nothing else, it makes it easier for ppl to download smaller chunks ...Seems like a good idea. Only RPM packages would have to know of the
split.Huh? *raised eyebrow*
Don't RPM's have to know to download two tarballs?
Or three, or ten..... In the case of our RPM's, there are eight source
files needed. Not a big deal, though.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Tue Feb 22 18:44:18 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA60940
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 18:43:26 -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 TAA78828;
Tue, 22 Feb 2000 19:42:06 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 22 Feb 2000 19:42:06 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: Splitting distributions (Was: Re: [HACKERS] ECPG / Release)
In-Reply-To: <25930.951257489@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0002221940300.86931-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 22 Feb 2000, Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
I'm creating them right now, broken down as:
docs -> pgsql/docs
test -> pgsql/src/test
support -> pgsql/src/{interfaces,bin}
base -> pgsql (minus the above)One gripe on this --- the docs are sort-of optional, and the test stuff
is certainly optional, but the interfaces and bin directories are *not*
optional. It'd be a good idea to make sure this is noted on the webpage
or in the FTP directory's README file...
Already done...see README.dist-split :) As I note in that file, all
chunks have to be downloaded, since I didn't want to differentiate at this
time between what is optional and what isn't. The purpose, for v7.0, was
just to make it 4 smaller tar files then one large one ... for v7.1, I'd
like to work on cleaning up the 'optional' stuff ...
From bouncefilter Tue Feb 22 18:44:19 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA60995;
Tue, 22 Feb 2000 18:44:16 -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 TAA78832;
Tue, 22 Feb 2000 19:43:28 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 22 Feb 2000 19:43:28 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: Splitting distributions (Was: Re: [HACKERS] ECPG / Release)
In-Reply-To: <200002222219.RAA05578@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0002221942180.86931-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 22 Feb 2000, Bruce Momjian wrote:
I'm going to do this tonight, put it up and see what ppl thing ... if
nothing else, it makes it easier for ppl to download smaller chunks ...Seems like a good idea. Only RPM packages would have to know of the
split.Huh? *raised eyebrow*
Don't RPM's have to know to download two tarballs?
the RPMs are totally seperate tarballs ... unrelated to this ... about the
only thing that would/could be affected is the FreeBSD ports collection,
but I'm still making the 'all-inclusive tar ball', so if ppl have a high
speed connection and want to download it all at once, they can ... just
increasing the options
From bouncefilter Tue Feb 22 18:48:19 2000
Received: from thelab.hub.org (nat197.96.mpoweredpc.net [142.177.197.96])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA61621
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 18:47: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 TAA78839;
Tue, 22 Feb 2000 19:45:05 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 22 Feb 2000 19:45:05 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: Splitting distributions (Was: Re: [HACKERS] ECPG / Release)
In-Reply-To: <200002222220.RAA05591@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0002221943370.86931-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 22 Feb 2000, Bruce Momjian wrote:
The Hermit Hacker <scrappy@hub.org> writes:
I'm creating them right now, broken down as:
docs -> pgsql/docs
test -> pgsql/src/test
support -> pgsql/src/{interfaces,bin}
base -> pgsql (minus the above)One gripe on this --- the docs are sort-of optional, and the test stuff
is certainly optional, but the interfaces and bin directories are *not*
optional. It'd be a good idea to make sure this is noted on the webpage
or in the FTP directory's README file...psql needs the sgml files for help, so none are optional, I think.
Technically, there should be a way of buildling a release distribution
that can build psql without requiring anything but libpq being installed
... its stuff I'm currently looking into ... but not for v7.0 ...
From bouncefilter Tue Feb 22 19:15:19 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 TAA67013
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 19:15:05 -0500 (EST) (envelope-from vev@michvhf.com)
Received: (qmail 16976 invoked by uid 1001); 23 Feb 2000 00:15:09 -0000
Message-ID: <XFMail.000222191509.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: <Pine.BSF.4.21.0002221942180.86931-100000@thelab.hub.org>
Date: Tue, 22 Feb 2000 19:15:09 -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: The Hermit Hacker <scrappy@hub.org>
Subject: Re: Splitting distributions (Was: Re: [HACKERS] ECPG / Release)
Cc: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
On 22-Feb-00 The Hermit Hacker wrote:
On Tue, 22 Feb 2000, Bruce Momjian wrote:
I'm going to do this tonight, put it up and see what ppl thing ... if
nothing else, it makes it easier for ppl to download smaller chunks ...Seems like a good idea. Only RPM packages would have to know of the
split.Huh? *raised eyebrow*
Don't RPM's have to know to download two tarballs?
the RPMs are totally seperate tarballs ... unrelated to this ... about the
only thing that would/could be affected is the FreeBSD ports collection,
Speaking of which, I sent a note back to Andreas about that.
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 Feb 22 20:19:36 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA74794;
Tue, 22 Feb 2000 20:18:31 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64697 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S276497AbQBWBRc>;
Wed, 23 Feb 2000 02:17:32 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12NQTG-0000pF-00; Wed, 23 Feb 2000 02:20:06 +0100
Date: Wed, 23 Feb 2000 02:20:06 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: The Hermit Hacker <scrappy@hub.org>
cc: Lamar Owen <lamar.owen@wgcr.org>, Michael Meskes <meskes@postgresql.org>,
PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: Re: Splitting distributions (Was: Re: [HACKERS] ECPG / Release)
In-Reply-To: <Pine.BSF.4.21.0002221654210.86931-100000@thelab.hub.org>
Message-ID: <Pine.LNX.4.21.0002230057580.415-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-02-22, The Hermit Hacker mentioned:
Pretty much ... longer term goal, IMHO, is to make a more compact
distribution so that if I want libpq on a clint machine, I don't have to
download the whole backend code too ...
Unfortunately there are currently some severe bogosities in the build
process that will prevent this. Certain subdirectories reach half way
across the source tree to get the stuff they need. I've thrown several
hints around in this direction, I would like to give the build process a
serious massage for the next release. This item would be considered.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Feb 22 20:19:26 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA74780
for <pgsql-hackers@postgresql.org>;
Tue, 22 Feb 2000 20:18:24 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64545 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S276488AbQBWBRY>;
Wed, 23 Feb 2000 02:17:24 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12NQTM-0000pj-00; Wed, 23 Feb 2000 02:20:12 +0100
Date: Wed, 23 Feb 2000 02:20:12 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error
messages
In-Reply-To: <23579.951234603@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0002230103390.415-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-02-22, Tom Lane mentioned:
Anyone for getting rid of GNU make?
No ;-). GNU make has enough important features that there is no
near-equivalent non-GNU make. VPATH, for example.
There are other makes that support this too. While I love GNU make, too,
all the talk about allowing vanilla lex, etc. is pointless while GNU make
is required. Users don't see lex at all, they do see make.
OTOH, it is very hard for me to get an overview these days what's actually
out there in terms of other make's, other lex's, other yacc's, other
compilers. You should have an edge there (HPUX and all). Most
installations of commercial Unix vendors I get to nowadays use gcc, gmake,
flex as system tools. Yesterday I read that Sun builds Java proper with
GNU make!
The best way of going about this seems to take one of the perpetrators
(make file, gram.y, etc.) and try to port it to some given non-GNU tool
and take a look at the consequences. For example, if we get PostgreSQL to
compile with FreeBSD's make without crippling everything, that would be a
win for the user base. This may in fact be the first experiment.
One thing I hope we will be able to do sometime soon is build in an
object directory tree separate from the source tree... can't
realistically do that with any non-GNU make that I've heard of.
I'm planning to work on that for 7.1. But here's an interesting tidbit:
Automake does support this feature but in its manual it claims that it
does not use any GNU make specific features. And in fact, VPATH exists in
both System V's and 4.3 BSD's make.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Feb 22 20:19:21 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA74812
for <pgsql-hackers@postgresql.org>;
Tue, 22 Feb 2000 20:18:52 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61170 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S276497AbQBWBSD>;
Wed, 23 Feb 2000 02:18:03 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12NQTx-0000qC-00; Wed, 23 Feb 2000 02:20:49 +0100
Date: Wed, 23 Feb 2000 02:20:49 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <200002221415.JAA15918@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.21.0002230145260.415-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-02-22, Bruce Momjian mentioned:
On Mon, 21 Feb 2000, The Hermit Hacker wrote:
* -Add BIT, BIT VARYING
This is currently suffering from BIT rot in contrib. Not really usable.
And we can't squeeze it in until the bootstrap scanner recognizes tokens
with spaces in it. (Does it?)Aw man, I promised to put that into the main tree. Is it not usable?
Spaces?
Somehow you have to do something similar to
insert OID = 9999 ( bit varying PGUID 1 1 t b t \054 0 0 bitvaryingin ... )
And no, naming the type bit_varying internally is not an acceptable
answer. ;) We might want to start thinking about this item before national
character comes our way. (Or just document the solution, if it already
exists.)
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Feb 22 20:19:26 2000
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA74830
for <pgsql-hackers@postgresql.org>;
Tue, 22 Feb 2000 20:19:02 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61530 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S278535AbQBWBSS>;
Wed, 23 Feb 2000 02:18:18 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12NQUC-0000qE-00; Wed, 23 Feb 2000 02:21:04 +0100
Date: Wed, 23 Feb 2000 02:21:04 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: bhirt@mobygames.com, Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Numeric with '-'
In-Reply-To: <22122.951192349@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0002230151000.415-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-02-21, Tom Lane mentioned:
Is there a good reason that a character literal is unknown? I'm sure the
reasons lie somewhere in the extensible type system, but if I wanted it to
be something else explicitly then I would have written DATE 'yesterday'.Remember that constants of random types like "line segment" have to
start out as character literals
A constant of type line segment looks like this:
LSEG 'whatever'
This is an obvious extension of the standard. (Also note that this is
*not* a cast.)
The semantics of SQL throughout are that if I write something of the form
quote-characters-quote, it's a character literal. No questions asked. Now
if I pass a character literal to a datetimeish function, it's on obvious
cast. If I pass it to a geometry function, it's an obvious cast. If I pass
it to a generic function, it's a character string.
It seems that for the benefit of a small crowd -- those actually using
geometric types and being too lazy to type their literals in the above
manner -- we are creating all sorts of problems for two much larger
crowds: those trying to use their databases in an normal manner with
strings and numbers, and those trying develop for this database that never
know what type a literal is, when it should be obvious. I am definitely
for a close examination of this one.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Feb 22 20:30:20 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 UAA75776
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 20:29: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
UAA09518;
Tue, 22 Feb 2000 20:21:28 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002230121.UAA09518@candle.pha.pa.us>
Subject: Re: Splitting distributions (Was: Re: [HACKERS] ECPG / Release)
In-Reply-To: <26201.951259097@sss.pgh.pa.us> from Tom Lane at "Feb 22,
2000 05:38:17 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 22 Feb 2000 20:21:28 -0500 (EST)
CC: The Hermit Hacker <scrappy@hub.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Ooh, good point. Never mind.
Bruce Momjian <pgman@candle.pha.pa.us> writes:
One gripe on this --- the docs are sort-of optional, and the test stuff
is certainly optional, but the interfaces and bin directories are *not*
optional. It'd be a good idea to make sure this is noted on the webpage
or in the FTP directory's README file...psql needs the sgml files for help, so none are optional, I think.
But the tarball has a prebuilt psql help file, or should.
regards, tom lane
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 22 20:28:20 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 UAA75639
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 20:27:55 -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
UAA09531;
Tue, 22 Feb 2000 20:23:17 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002230123.UAA09531@candle.pha.pa.us>
Subject: Re: Feature Request
In-Reply-To: <38B3254C.D0780368@jumpline.com> from Philip Yuengling at "Feb
22,
2000 07:09:48 pm"
To: Philip Yuengling <philip@jumpline.com>
Date: Tue, 22 Feb 2000 20:23:17 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Dear Mr Momjian
Just a quick suggestion for an added feature: "DROP COLUMN columnname
FROM table..." and "ALTER COLUMN columname FROM table..." queries would
spare my hair when I make mistakes in table creation.
We have the DROP, but will not appear in 7.0.
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 22 20:31:20 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 UAA75960
for <pgsql-hackers@postgreSQL.org>;
Tue, 22 Feb 2000 20:30:53 -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
UAA09867;
Tue, 22 Feb 2000 20:30:18 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002230130.UAA09867@candle.pha.pa.us>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <Pine.LNX.4.21.0002230145260.415-100000@localhost.localdomain>
from Peter Eisentraut at "Feb 23, 2000 02:20:49 am"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Tue, 22 Feb 2000 20:30:18 -0500 (EST)
CC: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL71 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
On 2000-02-22, Bruce Momjian mentioned:
On Mon, 21 Feb 2000, The Hermit Hacker wrote:
* -Add BIT, BIT VARYING
This is currently suffering from BIT rot in contrib. Not really usable.
And we can't squeeze it in until the bootstrap scanner recognizes tokens
with spaces in it. (Does it?)Aw man, I promised to put that into the main tree. Is it not usable?
Spaces?Somehow you have to do something similar to
insert OID = 9999 ( bit varying PGUID 1 1 t b t \054 0 0 bitvaryingin ... )And no, naming the type bit_varying internally is not an acceptable
answer. ;) We might want to start thinking about this item before national
character comes our way. (Or just document the solution, if it already
exists.)
Huh, I still don't get it. What is the matter with that insert?
--
Bruce Momjian | http://www.op.net/~candle
pgman@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 Feb 22 22:51:21 2000
Received: from mecomb.com (gw.mecomb.com [161.142.249.98])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA85554
for <pgsql-general@postgreSQL.org>;
Tue, 22 Feb 2000 22:50:35 -0500 (EST)
(envelope-from lylyeoh@mecomb.com)
Received: (from mail@localhost) by mecomb.com (8.8.7/8.8.7) id LAA01572
for <pgsql-general@postgreSQL.org>; Wed, 23 Feb 2000 11:51:47 +0800
Received: from <lylyeoh@mecomb.com> (ilab2.mecomb.po.my [192.168.3.22]) by
ns.mecomb.com via smap (V2.1)
id xma001564; Wed, 23 Feb 00 11:51:18 +0800
Message-Id: <3.0.5.32.20000223115026.008b2b90@pop.mecomb.po.my>
X-Sender: lylyeoh@pop.mecomb.po.my
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Wed, 23 Feb 2000 11:50:26 +0800
To: general <pgsql-general@postgreSQL.org>
From: Lincoln Yeoh <lylyeoh@mecomb.com>
Subject: Re: [GENERAL] TRANSACTIONS
In-Reply-To: <38B27760.DB921B57@sferacarta.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 12:47 PM 22-02-2000 +0100, Jose Soares wrote:
begin transaction;
create table tmp(a int);
insert into tmp values (1);
insert into tmp values (1000000000000000000000000000000000);
ERROR: pg_atoi: error reading "1000000000000000000000000000000000":
Numerical result out of range
commit;
select * from tmp;
ERROR: tmp: Table does not exist.
-------------------------------------------------------
Interbase, Oracle,Informix,Solid,Ms-Access,DB2:
-------------------------------------------------------
connect hygea.gdb;
create table temp(a int);
insert into temp values (1);
insert into temp values (1000000000000000000000000000000000);
commit;
select * from temp;arithmetic exception, numeric overflow, or string truncation
A
===========
1
Stuff done in a transaction cannot be committed if there is an error. So
looks like Postgres is right and the rest are wrong ;).
Also I believe Oracle does a commit behind your back whenever you do a
create table or stuff like that.
However I did have problems rolling back a create table in Postgres before-
after rolling back I could not recreate a table of the same name. I had to
manually unlink the table at filesystem level. Not sure if that has been
fixed.
On a different note I wonder if there could be layers of transactions
(without having to create two separate connections)..
Begin transaction A
Try to do transaction B
Depending on whether B succeeds or fails we do the following stuff differently
blahblahblah
If blahblablah fails then rollback the whole thingy, including nested
transaction B (even if "committed")
commit transaction A
Sounds like a headache to implement tho (performance hits etc), and
probably more an academic feature than anything. So I'm just wondering just
for the sake of wondering ;). If we go that way lots of people will have a
new toy to play with (to sell as well) and things will get even more
complex.. <grin>.
Cheerio,
Link.
From bouncefilter Wed Feb 23 00:13:26 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 AAA93246
for <pgsql-hackers@postgreSQL.org>;
Wed, 23 Feb 2000 00:12:51 -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 AAA00970;
Wed, 23 Feb 2000 00:12:32 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: bhirt@mobygames.com, Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Numeric with '-'
In-reply-to: <Pine.LNX.4.21.0002230151000.415-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0002230151000.415-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Wed, 23 Feb 2000 02:21:04 +0100"
Date: Wed, 23 Feb 2000 00:12:31 -0500
Message-ID: <965.951282751@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
Remember that constants of random types like "line segment" have to
start out as character literals
A constant of type line segment looks like this:
LSEG 'whatever'
This is an obvious extension of the standard. (Also note that this is
*not* a cast.)
Yes it is. On what grounds would you assert that it isn't? Certainly
not on the basis of what comes out of gram.y; all three of these
produce exactly the same parsetree:
LSEG 'whatever'
'whatever'::LSEG
CAST('whatever' AS LSEG)
It seems that for the benefit of a small crowd -- those actually using
geometric types and being too lazy to type their literals in the above
manner -- we are creating all sorts of problems for two much larger
crowds
Au contraire. The real issue here is how to decide which numeric type
to use for an undecorated but numeric-looking literal token. I don't
think that's a non-mainstream problem, and I definitely don't think
that telling the odd-datatype crowd to take a hike will help fix it.
regards, tom lane
From bouncefilter Wed Feb 23 00:42:28 2000
Received: from mailgw1.prontomail.com (mailgw1.prontomail.com
[209.185.149.197]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA95517
for <pgsql-hackers@postgresql.org>;
Wed, 23 Feb 2000 00:41:50 -0500 (EST)
(envelope-from rob.c@virgilio.it)
Received: from web05 (209.185.149.205) by mailgw1.prontomail.com (NPlex
2.0.123); Tue, 22 Feb 2000 21:40:42 -0800
From: "Roberto Cornacchia" <rob.c@virgilio.it>
Message-Id: <F39B9D83EA9E3D1178F20005B817149D@rob.c.virgilio.it>
Date: Wed, 23 Feb 2000 00:40:43 -0500
X-Priority: Normal
Content-Type: text/plain; charset=iso-8859-1
To: tgl@sss.pgh.pa.us
Subject: about 7.0 LIMIT optimization
CC: pgsql-hackers@postgresql.org
X-Mailer: Web Based Pronto
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Hi there,
I've just had a look at the 7.0beta and I've seen your enhancements
about LIMIT optimization.
Did you read by chance my previous message intitled
"Generalized Top Queries on PostgreSQL"?
When I wrote it I hadn't read the thread
intitled "Solution for LIMIT cost estimation" yet.
What you did looks pretty similar to part of our extension
(cost model and pruning rules). The main differences are:
- the FOR EACH generalization.
- You cannot select the top N rows according to criterion A ordering
the results with a different criterion B.
- If you ask for the best 10 rows, from a relation including
100000 rows, you have to do a traditional sort on 100000 rows and
then retain only the first 10, doing more comparisons than requested.
- You can choose a "fast-start" plan (i.e., basically,
a pipelined plan), but you cannot performe an "early-stop" of
the stream when you have a "slow-start" plan (e.g. involving sorts
or hash tables). We noticed that this kind of plan often
outperforms the first one.
So, we are looking forward to see how the new LIMIT optimization works
(we will do some tests as soon as possible). Have you noticed
relevant improvements?
Actually, we should say we can't figure out the reason for
managing the LIMIT clause in a so complicated way, not providing
a node in the plan as any other operator.
In our opinion, the choice to provide a separated process of the
LIMIT clause has two problems:
1. We find it more complicated and not so natural.
2. It is an obstacle to some optimizations and to some functionalities
(how to use it in subselects or views?)
Best regards
R. Cornacchia (cornacch@cs.unibo.it) Computer Science, University of
Bologna
A. Ghidini (ghidini@cs.unibo.it) Computer Science, University of Bologna
Dr. Paolo Ciaccia (ciaccia@cs.unibo.it) DEIS CSITE-CNR, University of
Bologna
===========================================================
VIRGILIO MAIL - Il tuo indirizzo E-mail gratis e per sempre
http://mail.virgilio.it/
VIRGILIO - La guida italiana a Internet
http://www.virgilio.it/
From bouncefilter Wed Feb 23 00:48:26 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 AAA96423
for <pgsql-hackers@postgreSQL.org>;
Wed, 23 Feb 2000 00:48: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 AAA01179;
Wed, 23 Feb 2000 00:48:09 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error
messages
In-reply-to: <Pine.LNX.4.21.0002230103390.415-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0002230103390.415-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Wed, 23 Feb 2000 02:20:12 +0100"
Date: Wed, 23 Feb 2000 00:48:09 -0500
Message-ID: <1176.951284889@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
On 2000-02-22, Tom Lane mentioned:
Anyone for getting rid of GNU make?
No ;-). GNU make has enough important features that there is no
near-equivalent non-GNU make. VPATH, for example.
There are other makes that support this too. While I love GNU make, too,
all the talk about allowing vanilla lex, etc. is pointless while GNU make
is required. Users don't see lex at all, they do see make.
Huh? Assuming someone will have program X installed is not the same as
assuming they will have program Y installed. In this particular case,
a more exact way of putting it is that assuming program X is installed
is not the same as assuming that program Y's prebuilt-on-another-machine
output is usable on this platform.
OTOH, it is very hard for me to get an overview these days what's actually
out there in terms of other make's, other lex's, other yacc's, other
compilers.
Not much. The real problem here is "what set of tool features do you
assume you have, and what's it costing you in portability?" GNU make
provides a very rich feature set that's widely portable, although you
do have to port the particular implementation. If you don't want to
assume GNU make but just a generic make, there's a big gap in features
before you drop down to what's actually portable to a wide class of
vendor-provided makes. VPATH, for example, does exist in *some*
vendor makes, but as a practical matter if you use it then you'd better
tell people "my program requires GNU make". It's not worth the trouble
to keep track of the exceptions.
I will be the first to admit this is all a matter of judgment calls
rather than certainties. As far as I can see, it's not worth our
trouble to try to operate with non-GNU makes; it is worth the trouble
to work with non-GNU yaccs, because we're not really using any bison-
specific features; it's looking like we should forget about non-GNU
lexes, but I'm not quite convinced yet. You're free to hold different
opinions of course. I've been around for a few years in the portable-
software game, so I tend to think I know where the minefields are, but
perhaps my hard experiences are out of date.
The best way of going about this seems to take one of the perpetrators
(make file, gram.y, etc.) and try to port it to some given non-GNU tool
and take a look at the consequences.
But that only tells you about the one tool; in fact, only about the one
version of the one tool that you test. In practice, useful knowledge
in this area comes from the school of hard knocks: ship an open-source
program and see what complaints you get. I'd rather rely on experience
previously gained than learn those lessons again...
One thing I hope we will be able to do sometime soon is build in an
object directory tree separate from the source tree... can't
realistically do that with any non-GNU make that I've heard of.
I'm planning to work on that for 7.1. But here's an interesting tidbit:
Automake does support this feature but in its manual it claims that it
does not use any GNU make specific features.
Yeah? Do they claim not to need VPATH to do it? I suppose it might
be possible, if they are willing to write sufficiently ugly and
non-hand-maintainable makefiles. Not sure that's a good tradeoff
though.
And in fact, VPATH exists in both System V's and 4.3 BSD's make.
You're still confusing two datapoints with the wide world...
regards, tom lane
From bouncefilter Wed Feb 23 00:57:50 2000
Received: from mail.rdc1.sdca.home.com (imail@ha1.rdc1.sdca.home.com
[24.0.3.66]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA97436
for <pgsql-hackers@postgresql.org>;
Wed, 23 Feb 2000 00:57:04 -0500 (EST)
(envelope-from jconway2@home.com)
Received: from jec-nt1 ([24.0.42.111]) by mail.rdc1.sdca.home.com
(InterMail v4.01.01.00 201-229-111) with SMTP
id <20000223055659.IJDP22732.mail.rdc1.sdca.home.com@jec-nt1>
for <pgsql-hackers@postgresql.org>; Tue, 22 Feb 2000 21:56:59 -0800
Message-ID: <002401bf7dc2$ce8b8240$0505a8c0@jec-nt1.elcjn1.sdca.home.com>
Reply-To: "Joe Conway" <jconway2@home.com>
From: "Joe Conway" <jconway2@home.com>
To: <pgsql-hackers@postgresql.org>
Subject: pltcl and LDAP
Date: Tue, 22 Feb 2000 21:57:00 -0800
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 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Hi,
I posted this a few days ago on the pgsql-sql list, but got no response. Is
there any way to enable loading tclLDAP from within a pltcl function? I
would like to maintain an openldap directory using an update/insert trigger.
I modified pltcl.c to load a non-safe interpreter and recompiled. This
allowed me to use the "load" command, but the tclLDAP library still would
not load. The error message is:
ERROR: pltcl: couldn't load file "/usr/lib/tclLDAP/Ldap.so":
/usr/lib/tclLDAP/Ldap.so: undefined symbol: Tcl_PkgProvide (#1)
I am not even close to being fluent in c. I would greatly appreciate any
suggestions.
BTW, perhaps in some future release you might consider allowing a non-safe
tcl interpreter (or at least some kind of controlled external library
support) as an option.
Thanks,
Joe Conway
-----Original Message-----
From: Joe Conway <jconway2@home.com>
To: pgsql-sql@postgresql.org <pgsql-sql@postgresql.org>
Date: Sunday, February 20, 2000 11:55 AM
Subject: pltcl and LDAP
I'm working on a project right now which involves updating an LDAP
directory
from a PostgreSQL database. The database includes a table called
employee_data. I would like to use the tclLDAP library from within a pltcl
function and create a trigger on the employee_data table to update the LDAP
directory every time something changes.I have been able to get the tclLDAP functions to work properly from with
pgtclsh, but not from within pltcl. The documentation states that pltcl
uses
a safe interpreter which does not allow a tcl load command.
Has anyone else tried to do this, i.e. synch up a PostgreSQL database with
a
LDAP directory? If so, how? I have considered just writing a pgtclsh script
and running it from cron, but I would prefer real time updates via a
trigger
if possible.
Any help or suggestions would be much appreciated.
Thanks,
Joe
From bouncefilter Wed Feb 23 01:04: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 BAA99404
for <pgsql-hackers@postgresql.org>;
Wed, 23 Feb 2000 01:03:34 -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 BAA01349;
Wed, 23 Feb 2000 01:03:29 -0500 (EST)
To: "Roberto Cornacchia" <rob.c@virgilio.it>
cc: pgsql-hackers@postgresql.org
Subject: Re: about 7.0 LIMIT optimization
In-reply-to: <F39B9D83EA9E3D1178F20005B817149D@rob.c.virgilio.it>
References: <F39B9D83EA9E3D1178F20005B817149D@rob.c.virgilio.it>
Comments: In-reply-to "Roberto Cornacchia" <rob.c@virgilio.it>
message dated "Wed, 23 Feb 2000 00:40:43 -0500"
Date: Wed, 23 Feb 2000 01:03:28 -0500
Message-ID: <1346.951285808@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Did you read by chance my previous message intitled
"Generalized Top Queries on PostgreSQL"?
I vaguely recall it, but forget the details...
- You cannot select the top N rows according to criterion A ordering
the results with a different criterion B.
True, but I don't see how to do that with one indexscan (for that
matter, I don't even see how to express it in the SQL subset that
we support...)
- If you ask for the best 10 rows, from a relation including
100000 rows, you have to do a traditional sort on 100000 rows and
then retain only the first 10, doing more comparisons than requested.
Not if there's an index that implements the ordering --- and if there
is not, I don't see how to avoid the sort anyway.
- You can choose a "fast-start" plan (i.e., basically,
a pipelined plan), but you cannot performe an "early-stop" of
the stream when you have a "slow-start" plan (e.g. involving sorts
or hash tables).
Why not? The executor *will* stop when it has as many output rows as
the LIMIT demands.
We noticed that this kind of plan often outperforms the first one.
I'd be the first to admit that the cost model needs some fine-tuning
still. It's just a conceptual structure at this point.
Actually, we should say we can't figure out the reason for
managing the LIMIT clause in a so complicated way, not providing
a node in the plan as any other operator.
We will probably end up doing it like that sooner or later, in order to
allow attaching LIMIT to sub-selects. I don't take any credit or blame
for the execution-time implementation of LIMIT; I just worked with what
I found...
regards, tom lane
From bouncefilter Wed Feb 23 01:15: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 BAA00768
for <pgsql-hackers@postgreSQL.org>;
Wed, 23 Feb 2000 01:14:43 -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 BAA01425;
Wed, 23 Feb 2000 01:14:31 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-reply-to: <200002230130.UAA09867@candle.pha.pa.us>
References: <200002230130.UAA09867@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Tue, 22 Feb 2000 20:30:18 -0500"
Date: Wed, 23 Feb 2000 01:14:31 -0500
Message-ID: <1422.951286471@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Somehow you have to do something similar to
insert OID = 9999 ( bit varying PGUID 1 1 t b t \054 0 0 bitvaryingin ... )
Huh, I still don't get it. What is the matter with that insert?
The space in the type name is gonna confuse things.
And no, naming the type bit_varying internally is not an acceptable
answer. ;) We might want to start thinking about this item before national
character comes our way. (Or just document the solution, if it already
exists.)
AFAICS the solution would have to be similar to what we already do for
CHARACTER VARYING: parse the type declaration specially in gram.y,
and translate it to an internal type name.
gram.y already knows about NATIONAL CHARACTER [ VARYING ] too, BTW.
Seems to just translate it into bpchar or varchar :-( ... but the
syntax problem is solved.
regards, tom lane
From bouncefilter Wed Feb 23 02:26:26 2000
Received: from fw.pvt.cz (fw.pvt.cz [194.149.101.194])
by hub.org (8.9.3/8.9.3) with SMTP id CAA09287
for <pgsql-hackers@postgreSQL.org>;
Wed, 23 Feb 2000 02:26:23 -0500 (EST)
(envelope-from Vladimir.Benes@pvt.cz)
Received: by fw.pvt.cz; (5.65v4.0/1.3/10May95) id AA30203;
Wed, 23 Feb 2000 08:25:45 +0100
Received: from p53w02.chv.pvt.cz (p53w02.chv.pvt.cz [172.17.28.6])
by mh.pvt.cz (8.9.1/8.9.1) with ESMTP id IAA11169;
Wed, 23 Feb 2000 08:25:43 +0100 (MET)
Received: from p53apk (p53apk.chv.pvt.cz [172.17.28.69]) by p53w02.chv.pvt.cz
with SMTP (Microsoft Exchange Internet Mail Service Version
5.5.2650.21) id FLP7C0DH; Wed, 23 Feb 2000 08:25:41 +0100
Message-Id: <001e01bf7dcf$42506310$451c11ac@p53apk.chv.pvt.cz>
From: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" <Vladimir.Benes@pvt.cz>
To: "Tom Lane" <tgl@sss.pgh.pa.us>, "Oliver Elphick" <olly@lfix.co.uk>
Cc: <pgsql-hackers@postgreSQL.org>,
"=?iso-8859-2?Q?M=FChlpachr_Michal?=" <michalm@pvt.net>
Subject: Re: [HACKERS] Out of memory problem (forwarded bug report)
Date: Wed, 23 Feb 2000 08:26:11 +0100
Mime-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-2"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
-----P���vodn��� zpr���va-----
Od: Tom Lane <tgl@sss.pgh.pa.us>
Komu: Oliver Elphick <olly@lfix.co.uk>
Kopie: pgsql-hackers@postgreSQL.org <pgsql-hackers@postgreSQL.org>;
Vladimir.Benes@pvt.cz <Vladimir.Benes@pvt.cz>
Datum: 22. ���nora 2000 18:06
P���edm���t: Re: [HACKERS] Out of memory problem (forwarded bug report)
"Oliver Elphick" <olly@lfix.co.uk> writes:
Can someone advise, please, how to deal with this problem in 6.5.3?
My guess is that the cause is memory leaks during expression evaluation;
but without seeing the complete view definitions and underlying table
definitions, it's impossible to know what processing is being invoked
by this query...regards, tom lane
Well, I will append views and underlying table definition:
1) Once again - failure query:
select comm_type,name,tot_bytes,tot_packets
from flow_sums_days_send_200002_view
where day='2000-02-21' and name not like '@%'
union all
select comm_type,name,tot_bytes,tot_packets
from flow_sums_days_receive_200002_view
where day='2000-02-21' and name not like '@%'
2) views definition:
create view flow_sums_days_send_200002_view as
select
'send'::varchar as comm_type, date_trunc('day',start) as day,
src_name as name, sum(bytes) as tot_bytes, sum(packets) as tot_packets
from flow_sums_200002
group by day, src_name
create view flow_sums_days_receive_200002_view as
select
'receive'::varchar as comm_type, date_trunc('day',start) as day,
dst_name as name, sum(bytes) as tot_bytes, sum(packets) as tot_packets
from flow_sums_200002
group by day, dst_name
I wanted create only one usefull view:
create view flow_sums_days_200002_view as
select
'send'::varchar as comm_type, date_trunc('day',start) as day,
src_name as name, sum(bytes) as tot_bytes, sum(packets) as tot_packets
from flow_sums_200002
group by day, src_name
UNION ALL
select
'receive'::varchar as comm_type, date_trunc('day',start) as day,
dst_name as name, sum(bytes) as tot_bytes, sum(packets) as tot_packets
from flow_sums_200002
group by day, dst_name
...but Postgres cann't use clause UNION ALL at view definition. So I created
two views mentioned above and I wanted use this ones with UNION ALL clause
only.
3) underlaying table definition:
create table flow_sums_200002 (
primary_collector varchar(50) not null,
start datetime not null,
end_period datetime not null,
dead_time_rel float4 not null,
src_name varchar(50) not null,
dst_name varchar(50) not null,
bytes int8 not null,
packets int4 not null
)
Today this table has about 3 000 000 rows and the select command
mentioned above returns 190 + 255 rows.
Now I don't use clause "UNION ALL" and the program executes two queryes
and then adds both result to new result. I reduced time increment of number
rows to flow_sums_200002 table (three times less). This table contains data
of February 2000 and the program will create table flow_sums_200003 with
relevant views next month.
Well, now this solution solve my problem but always depends on number of
rows - I only moved limit of rows count.
Thank You, V. Benes
P.S.: I append part of top on my system while the query is running:
CPU states: 98.6% user, 1.3% system, 0.0% nice, 0.0% idle
Mem: 127256K av, 124316K used, 2940K free, 29812K shrd, 2620K buff
Swap: 128516K av, 51036K used, 77480K free 7560K cached
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
2942 postgres 20 0 141M 99M 17348 R 0 99.0 80.4 1:22 postmaster
=> postmaster later took 80 - 95% of memory, free memory decressed to 2 MB,
CPU was overloaded (0% idle and 99% by user process of postmaster). Have You
ever seen something similar :-) ?
From bouncefilter Wed Feb 23 03:27:25 2000
Received: from gandalf.it-austria.net (gandalf.it-austria.net [213.150.1.65])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA16899
for <hackers@postgresql.org>; Wed, 23 Feb 2000 03:27:06 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at (sdgtw.sd.spardat.at
[172.18.1.16])
by gandalf.it-austria.net (xxx/xxx) with ESMTP id JAA161150;
Wed, 23 Feb 2000 09:26:38 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <1TSZF5XA>; Wed, 23 Feb 2000 09:26:37 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C604AF7CEF@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'Dmitry Samersoff'" <dms@wplus.net>
Cc: "'hackers@postgresql.org'" <hackers@postgresql.org>
Subject: AW: [HACKERS] TRANSACTIONS
Date: Wed, 23 Feb 2000 09:26:32 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="koi8-r"
AFAIK, MS Access have no transactions inside it,
Informix (at least old versions I worked with) always
perform create,drop, alter object outside transaction
but IMHO it's not right behavior.
MS Access has transactions and Informix (Version 5.00 - 9.20) performs
create, drop, alter inside the transaction, same as Oracle and DB2.
I believe postgres's behavior more meaningful,
but IMHO, this example is quite far from real life.
I am pretty sure that the behavior of the others
is the standard.
What PostgreSQL currently also lacks, to make this really useful
is ANSI SQL SQLSTATE (most others also have an int sqlcode),
so you can decide wether this certain error can be ignored or fixed
inside this transaction.
The string parsing we can do is far from optimal.
Andreas
From bouncefilter Wed Feb 23 03:46:25 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 DAA18719
for <pgsql-hackers@postgreSQL.org>;
Wed, 23 Feb 2000 03:45:28 -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 RAA01148; Wed, 23 Feb 2000 17:44:31 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>, "Karel Zak - Zakkr" <zakkr@zf.jcu.cz>
Cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Cache query (PREPARE/EXECUTE)
Date: Wed, 23 Feb 2000 17:50:48 +0900
Message-ID: <000201bf7ddb$1442dfa0$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: <24214.951239775@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 LaneKarel Zak - Zakkr <zakkr@zf.jcu.cz> writes:
as I said, I tring implement PREPARE / EXECUTE command for user a
controllable query cache (in TODO: Cache most recent query plan(s)).Looks cool.
The queryTree and planTree are save in hash table and in the
TopMemoryContext (Is it good space for this cache?).Probably not. I'd suggest making a separate memory context for
this purpose --- they're cheap, and that gives you more control.
Look at the creation and use of CacheMemoryContext for an example.
Hmm,shoudn't per plan memory context be created ?
Though current SPI stuff saves prepared plans to TopMemory
Context,we couldn't remove them forever. It seems that SPI
should also be changed in its implementation about saving
plans.
Note that freeObject() is unavailable at all.
We would be able to free PREPAREd resources by destroying
corrsponding memory context.
If I recognize Jan's original idea correctly,he also suggested
the same way.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Wed Feb 23 03:54:25 2000
Received: from gandalf.it-austria.net (gandalf.it-austria.net [213.150.1.65])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA19737;
Wed, 23 Feb 2000 03:53:31 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at (sdgtw.sd.spardat.at
[172.18.1.16])
by gandalf.it-austria.net (xxx/xxx) with ESMTP id JAA86470;
Wed, 23 Feb 2000 09:53:15 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <1TSZF593>; Wed, 23 Feb 2000 09:53:14 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C604AF7CF0@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'Tom Lane'" <tgl@sss.pgh.pa.us>, "'Jose Soares'" <jose@sferacarta.com>
Cc: "'hackers'" <pgsql-hackers@postgreSQL.org>, "'general'"
<pgsql-general@postgreSQL.org>
Subject: AW: [HACKERS] TRANSACTIONS
Date: Wed, 23 Feb 2000 09:52:59 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Jose Soares <jose@sferacarta.com> writes:
-------------------------------------------------------
Interbase, Oracle,Informix,Solid,Ms-Access,DB2:
-------------------------------------------------------
connect hygea.gdb;
create table temp(a int);
insert into temp values (1);
insert into temp values (1000000000000000000000000000000000);
commit;
select * from temp;arithmetic exception, numeric overflow, or string truncation
A
===========
1I would like to know what the Standard says and who is in the rigth path
PostgreSQL or the others, considering the two examples reported below.I think those other guys are unquestionably failing to
conform to SQL92.
6.10 general rule 3.a says
All others also throw an error for this statement, and thus conform.
As you can see from the select only the first row is inserted.
I think the numeric is only an example of an error, it could also be
any other error, like "duplicate key" or the like.
......
and 3.3.4.1 says
The phrase "an exception condition is raised:", followed by the
name of a condition, is used in General Rules and elsewhere to
indicate that the execution of a statement is unsuccessful, ap-
plication of General Rules, other than those of Subclause 12.3,
"<procedure>", and Subclause 20.1, "<direct SQL statement>", may
be terminated, diagnostic information is to be made available,
and execution of the statement is to have no effect on SQL-data
or
Note here, that they say "the statement", which does not say anything about
other statements in the same transaction.
schemas. The effect on <target specification>s and SQL descriptor
areas of an SQL-statement that terminates with an exception
condi-
tion, unless explicitly defined by this International Standard,
is
implementation-dependent.
I see no way that allowing the transaction to commit after an overflow
can be called consistent with the spec.
Of course it can not commit this single statement that was in error.
All he wants is to commit all other statements, before and after the
error statement inside this same transaction.
Andreas
From bouncefilter Wed Feb 23 04:08:26 2000
Received: from gandalf.it-austria.net (gandalf.it-austria.net [213.150.1.65])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA21278;
Wed, 23 Feb 2000 04:07:37 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at (sdgtw.sd.spardat.at
[172.18.1.16])
by gandalf.it-austria.net (xxx/xxx) with ESMTP id KAA169150;
Wed, 23 Feb 2000 10:06:56 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <1TSZF6BS>; Wed, 23 Feb 2000 10:06:56 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C604AF7CF1@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'Don Baccus'" <dhogaza@pacifier.com>, "'Tom Lane'" <tgl@sss.pgh.pa.us>,
"'Jose Soares'" <jose@sferacarta.com>
Cc: "'hackers'" <pgsql-hackers@postgreSQL.org>, "'general'"
<pgsql-general@postgreSQL.org>
Subject: AW: [HACKERS] TRANSACTIONS
Date: Wed, 23 Feb 2000 10:06:46 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
I see no way that allowing the transaction to commit after an overflow
can be called consistent with the spec.You are absolutely right. The whole point is that either a) everything
commits or b) nothing commits.
Having some kinds of exceptions allow a partial commit while other
exceptions rollback the transaction seems like a very error-prone
programming environment to me.
There is no distinction between exceptions.
A statement that throws an error is not performed (including all
its triggered events) period.
There are sqlstates, that are only warnings, in which case the statement
is performed.
In this sense a commit is not partial. The commit should commit
all statements that were not in error.
All other DB's behave in this way.
Andreas
From bouncefilter Wed Feb 23 04:11:26 2000
Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net
[194.217.242.92]) by hub.org (8.9.3/8.9.3) with ESMTP id EAA21594;
Wed, 23 Feb 2000 04:10:40 -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 anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1)
id 12NXoZ-000EZf-0Y; Wed, 23 Feb 2000 09:10:35 +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 JAA14277;
Wed, 23 Feb 2000 09:10:35 GMT
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <FPX5WA5Q>; Wed, 23 Feb 2000 09:09:22 -0000
Message-ID:
<1B3D5E532D18D311861A00600865478C70C243@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'The Hermit Hacker'" <scrappy@hub.org>, Michael Meskes
<meskes@postgreSQL.org>
Cc: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: RE: Splitting distributions (Was: Re: [HACKERS] ECPG / Release)
Date: Wed, 23 Feb 2000 09:09:21 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
As usual when replying from here, replies prefixed with PM:
--
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, February 22, 2000 8:33 PM
To: Michael Meskes
Cc: PostgreSQL Hacker
Subject: Splitting distributions (Was: Re: [HACKERS] ECPG / Release)
On Tue, 22 Feb 2000, Michael Meskes wrote:
When will we release 7.0? I just checked and found that I'm way behind
my
schedule. The parser is in sync, but there are quite some open bugs.
So
hopefully there is either enough time left or someone who would like
to
spend some time on fixing bugs. :-)
April 1st is what I announced, but I'll be shocked if that actually
happens :) You should have loads of time ...
As far as I'm concerned, stuff like ECPG and JDBC and ODBC are
changeable
pretty much up to the release date ... they are generally touched, and
modified by only one person ...
PM: To be honest, I've been doing it this way at least since 6.5 :-)
Actually, I think that as long as it doesn't change the core (ie: JDBC
doesn't use any code outside of the src/interfaces/jdbc directory) then
it doesn't hurt. That doesn't mean I don't try to meet the beta deadline
however :-)
One of the things I'd like to look at for 7.1 is start to split off the
distributions ... we're up to a 7meg distribution and growing ...
We should be able to do a pgsql-docs.tar.gz and pgsql-src.tar.gz at the
very least ... putting 'doc' in a seperate tar file would reduce the
size
by ~3meg:
total 3024
-rw-r--r-- 1 scrappy wheel 2969424 Feb 22 15:27 doc.tar.gz
Actually, is there a reason we can't do this now? I can change the 'tar
build' system so that we have split systems that way ... this would at
least safe testers from downloading 3meg worth of tar file that most
likely won't get touched often ...
PM: I'm surprised we haven't done it earlier.
I'm going to do this tonight, put it up and see what ppl thing ... if
nothing else, it makes it easier for ppl to download smaller chunks ...
PM: Agreed.
From bouncefilter Wed Feb 23 05:32:26 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 FAA33117
for <pgsql-hackers@postgreSQL.org>;
Wed, 23 Feb 2000 05:32:19 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12NYwW-0003kgC; Wed, 23 Feb 100 11:22 MET
Message-Id: <m12NYwW-0003kgC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] pltcl and LDAP
In-Reply-To: <002401bf7dc2$ce8b8240$0505a8c0@jec-nt1.elcjn1.sdca.home.com>
from
Joe Conway at "Feb 22, 2000 09:57:00 pm"
To: Joe Conway <jconway2@home.com>
Date: Wed, 23 Feb 2000 11:22:52 +0100 (CET)
CC: pgsql-hackers@postgreSQL.org
Reply-To: Jan Wieck <wieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Joe Conway wrote:
Hi,
I posted this a few days ago on the pgsql-sql list, but got no response. Is
there any way to enable loading tclLDAP from within a pltcl function? I
would like to maintain an openldap directory using an update/insert trigger.I modified pltcl.c to load a non-safe interpreter and recompiled. This
allowed me to use the "load" command, but the tclLDAP library still would
not load. The error message is:ERROR: pltcl: couldn't load file "/usr/lib/tclLDAP/Ldap.so":
/usr/lib/tclLDAP/Ldap.so: undefined symbol: Tcl_PkgProvide (#1)
Um - and that's the only unresolved one?
Which version of Tcl is used from PL/Tcl, and which version
is the Ldap.so linked against?
I am not even close to being fluent in c. I would greatly appreciate any
suggestions.BTW, perhaps in some future release you might consider allowing a non-safe
tcl interpreter (or at least some kind of controlled external library
support) as an option.
Kinda that is on my personal TODO/wishlist. Splitting PL/Tcl
into two separate interpreters internally, identified by
different language names. The unsafe language, with full
access to OS under the postgres userID, would be an untrusted
language, so creation of functions is restricted to DB
superusers.
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 Feb 23 05:29:26 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 FAA32701
for <pgsql-hackers@postgreSQL.org>;
Wed, 23 Feb 2000 05:28:31 -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 LAA18904;
Wed, 23 Feb 2000 11:26:27 +0100
Date: Wed, 23 Feb 2000 11:26:27 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Hiroshi Inoue <Inoue@tpf.co.jp>
cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Cache query (PREPARE/EXECUTE)
In-Reply-To: <000201bf7ddb$1442dfa0$2801007e@tpf.co.jp>
Message-ID: <Pine.LNX.3.96.1000223105510.15474A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Though current SPI stuff saves prepared plans to TopMemory
Context,we couldn't remove them forever. It seems that SPI
should also be changed in its implementation about saving
plans.
Yes, I know about SPI plan saving... from here is my inspiration
with TopMemoryContext. But we have in current PG code very often
any cached queryPlan/Tree (PREPARE, SPI and Jan's RI saves plans
to TopM. too), I agree with Tom that is not bad idea saving all
plans to _one_ specific MemoryContext.
My idea is make any basic routines for query cache (hash table,
ExecuteCachedQuery() ...etc) and use these routines for more
operation (SPI, FKeys, PREPARE..). Comments?
Note that freeObject() is unavailable at all.
We would be able to free PREPAREd resources by destroying
corrsponding memory context.
If I good understand, we can't destroy any plan? We must
destroy _full_ memory context? If yes (please no), we can't
make a DROP PLAN command or we must create for each plan specific
memory context (and drop this specific Context (Jan's original idea)).
If I call SPI_saveplan(), is the plan forever save in
TopMemoryContext? (hmm, the SPI is memory feeder).
Karel
From bouncefilter Wed Feb 23 05:45:27 2000
Received: from sapphire.albourne.com (sapphire.albourne.com [195.212.241.227])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA33975
for <pgsql-hackers@postgresql.org>;
Wed, 23 Feb 2000 05:44:53 -0500 (EST)
(envelope-from alessio@albourne.com)
Received: from albourne.com (akamas.albourne.com [195.212.241.254])
by sapphire.albourne.com (8.9.3/8.9.3/Albourne/CYS/1.8/MAPS) with ESMTP
id MAA30157; Wed, 23 Feb 2000 12:43:49 +0200 (EET)
Sender: alessio@albourne.com
Message-ID: <38B3B9E5.269AD14A@albourne.com>
Date: Wed, 23 Feb 2000 12:43:49 +0200
From: Alessio Bragadini <alessio@albourne.com>
Organization: APL Financial Services (Overseas) Ltd.
X-Mailer: Mozilla 4.7 [en] (X11; I; OSF1 V4.0 alpha)
X-Accept-Language: it, en, sv
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: PostgreSQL Hacker <pgsql-hackers@postgresql.org>,
Adriaan Joubert <a.joubert@albourne.com>
Subject: Re: [HACKERS] Big join breaks psql
References: <38B27283.12AEB679@albourne.com> <23841.951236424@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Try doing
set ksqo = 'on';
in psql before you run the query. I think the ODBC driver does that for
you automatically.
Thanks for the suggestion, unfortunately I get the same behaviour.
--
Alessio F. Bragadini alessio@albourne.com
APL Financial Services http://www.sevenseas.org/~alessio
Nicosia, Cyprus phone: +357-2-750652
"It is more complicated than you think"
-- The Eighth Networking Truth from RFC 1925
From bouncefilter Wed Feb 23 10:57:34 2000
Received: from corvette.mascari.com (dhcp26136016.columbus.rr.com
[24.26.136.16]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA59908
for <hackers@postgreSQL.org>; Wed, 23 Feb 2000 10:57:14 -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 KAA04378;
Wed, 23 Feb 2000 10:54:41 -0500
Sender: mascarm@corvette.mascari.com
Message-ID: <38B3BC22.BC6AFA31@mascari.com>
Date: Wed, 23 Feb 2000 05:53:22 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Dmitry Samersoff <dms@wplus.net>
CC: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>,
"hackers@postgresql.org" <hackers@postgreSQL.org>
Subject: Re: AW: [HACKERS] TRANSACTIONS
References: <XFMail.20000223175313.dms@wplus.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dmitry Samersoff wrote:
On 23-Feb-2000 Zeugswetter Andreas SB wrote:
AFAIK, MS Access have no transactions inside it,
Informix (at least old versions I worked with) always
perform create,drop, alter object outside transaction
but IMHO it's not right behavior.MS Access has transactions and Informix (Version 5.00 - 9.20) performs
create, drop, alter inside the transaction, same as Oracle and DB2.
^^^^^^
OK. May be I miss something.
I don't think so. Not with respect to Oracle. Andreas knows that
Oracle implicitly commits your running transaction -- and starts
a new one whenever a DDL statement is encountered. A large
discussion about this arose about 4 months ago...I can't speak
for DB2.
--
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...************
From bouncefilter Wed Feb 23 05:04:33 2000
Received: from smtp.xs4all.be (IDENT:root@smtp.xs4all.be [195.144.67.21])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA28148
for <pgsql-general@postgreSQL.org>;
Wed, 23 Feb 2000 05:04:11 -0500 (EST)
(envelope-from wim.ceulemans@nice.be)
Received: from uni-box.nice.be (IDENT:0@nice.be [195.144.66.92])
by smtp.xs4all.be (8.9.3/8.9.3) with ESMTP id LAA15320
for <pgsql-general@postgreSQL.org>; Wed, 23 Feb 2000 11:04:03 +0100
Received: from nice.be ; Wed, 23 Feb 2000 11:03:07 +0100
Sender: Wim.Ceulemans@nice.be
Message-ID: <38B3BFDA.6476F0F7@nice.be>
Date: Wed, 23 Feb 2000 12:09:14 +0100
From: Wim Ceulemans <wim.ceulemans@nice.be>
Organization: Nice bvba
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "'general'" <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] AW: [HACKERS] TRANSACTIONS
References:
<219F68D65015D011A8E000006F8590C604AF7CF0@sdexcsrv1.f000.d0188.sd.spardat.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Zeugswetter Andreas SB wrote:
Jose Soares <jose@sferacarta.com> writes:
-------------------------------------------------------
Interbase, Oracle,Informix,Solid,Ms-Access,DB2:
-------------------------------------------------------
connect hygea.gdb;
create table temp(a int);
insert into temp values (1);
insert into temp values (1000000000000000000000000000000000);
commit;
select * from temp;arithmetic exception, numeric overflow, or string truncation
A
===========
1I would like to know what the Standard says and who is in the rigth path
PostgreSQL or the others, considering the two examples reported below.I think those other guys are unquestionably failing to
conform to SQL92.
6.10 general rule 3.a saysAll others also throw an error for this statement, and thus conform.
As you can see from the select only the first row is inserted.
I think the numeric is only an example of an error, it could also be
any other error, like "duplicate key" or the like.......
and 3.3.4.1 says
The phrase "an exception condition is raised:", followed by the
name of a condition, is used in General Rules and elsewhere to
indicate that the execution of a statement is unsuccessful, ap-
plication of General Rules, other than those of Subclause 12.3,
"<procedure>", and Subclause 20.1, "<direct SQL statement>", may
be terminated, diagnostic information is to be made available,
and execution of the statement is to have no effect on SQL-dataor
Note here, that they say "the statement", which does not say anything about
other statements in the same transaction.schemas. The effect on <target specification>s and SQL descriptor
areas of an SQL-statement that terminates with an exceptioncondi-
tion, unless explicitly defined by this International Standard,
is
implementation-dependent.
I see no way that allowing the transaction to commit after an overflow
can be called consistent with the spec.Of course it can not commit this single statement that was in error.
All he wants is to commit all other statements, before and after the
error statement inside this same transaction.
Isn't the intention of a transaction that it is atomic, i.e. either all
statements pass or none of them? (see section 5.4 in the standard).
Wim
From bouncefilter Wed Feb 23 07:55:28 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA40978
for <pgsql-hackers@postgreSQL.org>;
Wed, 23 Feb 2000 07:55:10 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Delfin.DoCS.UU.SE (e99re41@Delfin.DoCS.UU.SE [130.238.9.183])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id NAA01763;
Wed, 23 Feb 2000 13:54:46 +0100 (MET)
Received: from localhost (e99re41@localhost) by Delfin.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id NAA29539;
Wed, 23 Feb 2000 13:54:43 +0100
X-Authentication-Warning: Delfin.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Wed, 23 Feb 2000 13:54:42 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <1422.951286471@sss.pgh.pa.us>
Message-ID: <Pine.GSO.4.02A.10002231348220.29518-100000@Delfin.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 23 Feb 2000, Tom Lane wrote:
insert OID = 9999 ( bit varying PGUID 1 1 t b t \054 0 0 bitvaryingin ... )
The space in the type name is gonna confuse things.
AFAICS the solution would have to be similar to what we already do for
CHARACTER VARYING: parse the type declaration specially in gram.y,
and translate it to an internal type name.
Those are only workarounds on the backend level though. Every new hack
like this will require fixing every client applicatiion to translate that
type right. It's fine with CHARACTER VARYING, because VARCHAR is an
official alias (although it's not the real type name, mind you), but there
is no VARBIT or NVARCHAR. It seems that allowing something like
bit\ varying
in the bootstrap scanner will solve the problem where it's being caused.
Internal type names should go away, not accumulate. ;)
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Wed Feb 23 08:00:28 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA41568
for <pgsql-hackers@postgreSQL.org>;
Wed, 23 Feb 2000 08:00:25 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Delfin.DoCS.UU.SE (e99re41@Delfin.DoCS.UU.SE [130.238.9.183])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id OAA03120;
Wed, 23 Feb 2000 14:00:18 +0100 (MET)
Received: from localhost (e99re41@localhost) by Delfin.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id OAA29551;
Wed, 23 Feb 2000 14:00:16 +0100
X-Authentication-Warning: Delfin.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Wed, 23 Feb 2000 14:00:16 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Numeric with '-'
In-Reply-To: <965.951282751@sss.pgh.pa.us>
Message-ID: <Pine.GSO.4.02A.10002231355070.29518-100000@Delfin.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 23 Feb 2000, Tom Lane wrote:
Au contraire. The real issue here is how to decide which numeric type
to use for an undecorated but numeric-looking literal token. I don't
You lost me. How does that relate to the character types? You are not
suggesting that '123.456' should be considered a number? It seems pretty
clear to me that anything of the form [0-9]+ is an integer, something with
an 'e' in it is a float, and something with only digits and decimal points
is numeric. If passing around an 'numeric' object is too expensive, keep
it as a string for a while longer. As you did.
think that's a non-mainstream problem, and I definitely don't think
that telling the odd-datatype crowd to take a hike will help fix it.
It remains to be shown how big that "hike", if at all existent, would be
...
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Wed Feb 23 08:21:28 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA42779
for <pgsql-hackers@postgreSQL.org>;
Wed, 23 Feb 2000 08:20:54 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Delfin.DoCS.UU.SE (e99re41@Delfin.DoCS.UU.SE [130.238.9.183])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id OAA06004;
Wed, 23 Feb 2000 14:20:47 +0100 (MET)
Received: from localhost (e99re41@localhost) by Delfin.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id OAA29608;
Wed, 23 Feb 2000 14:20:45 +0100
X-Authentication-Warning: Delfin.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Wed, 23 Feb 2000 14:20:44 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: GNU make (Re: [HACKERS] Re: [PATCHES] Patch for more readable
parse error messages)
In-Reply-To: <1176.951284889@sss.pgh.pa.us>
Message-ID: <Pine.GSO.4.02A.10002231413220.29518-100000@Delfin.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 23 Feb 2000, Tom Lane wrote:
And in fact, VPATH exists in both System V's and 4.3 BSD's make.
You're still confusing two datapoints with the wide world...
I challenge everyone to show me a make without VPATH. In fact, show me two
makes without a feature that you can't live without, and I shall forever
hold my peace. It's certainly easier to say "let's support yacc, because
we actually don't use any non-yacc features" than saying it for make. But
it's not the idea to say "we need GNU make because it has all these
features" when 93% of these features in fact exist in all other reasonable
makes as well. It's not the end of the world but it's something that
shouldn't be ignored.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Wed Feb 23 08:27:28 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 IAA43275;
Wed, 23 Feb 2000 08:26:41 -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 OAA11913;
Wed, 23 Feb 2000 14:26:31 +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 12Nchr-0000ZK-00; Wed, 23 Feb 2000 14:23:59 +0000
Message-ID: <38B3DEFC.A9B2005D@sferacarta.com>
Date: Wed, 23 Feb 2000 14:22:04 +0100
From: Jose Soares <jose@sferacarta.com>
Organization: Sfera Carta
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Dmitry Samersoff <dms@wplus.net>
CC: general <pgsql-general@postgresql.org>,
hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] TRANSACTIONS
References: <XFMail.20000222151312.dms@wplus.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dmitry Samersoff wrote:
On 22-Feb-2000 Jose Soares wrote:
begin transaction;
create table tmp(a int);
insert into tmp values (1);
insert into tmp values (1000000000000000000000000000000000);
ERROR: pg_atoi: error reading "1000000000000000000000000000000000":
Numerical result out of range
commit;
select * from tmp;
ERROR: tmp: Table does not exist.
-------------------------------------------------------
Interbase, Oracle,Informix,Solid,Ms-Access,DB2:^^^^^^^^^
AFAIK, MS Access have no transactions inside it,
Informix (at least old versions I worked with) always
perform create,drop, alter object outside transaction
but IMHO it's not right behavior.
I don't know and I don't care about old software,
I'm talking about Ms_Access97 and Informix 8.
--
Jose' Soares
Bologna, Italy Jose@sferacarta.com
From bouncefilter Wed Feb 23 08:40:30 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 IAA44399;
Wed, 23 Feb 2000 08:39:33 -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 OAA20583;
Wed, 23 Feb 2000 14:38:06 +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 12Nd04-0000bm-00; Wed, 23 Feb 2000 14:42:48 +0000
Message-ID: <38B3E365.D2B61959@sferacarta.com>
Date: Wed, 23 Feb 2000 14:40:53 +0100
From: Jose Soares <jose@sferacarta.com>
Organization: Sfera Carta
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: hackers <pgsql-hackers@postgresql.org>,
general <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Re: [HACKERS] TRANSACTIONS
References: <38B27760.DB921B57@sferacarta.com> <23935.951237171@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sorry for my english, Tom, but the point is another, I'm talking about
transactions not about error messages.
This is only a stupid example how to abort a transaction, PostgreSQL aborts
automatically transactions if
an error occurs, even an warning or a syntax error.
I can believe that all other databases are wrong and only we (PostgreSQL) are
right, but please try to understand me. This is not easy to believe anyway.
I'm looking for another database with a behavior like PostgreSQL but I can't find
it, and I tried a lot of them until now.
Do you know some database with transactions like PostgreSQL?
Tom Lane wrote:
Jose Soares <jose@sferacarta.com> writes:
-------------------------------------------------------
Interbase, Oracle,Informix,Solid,Ms-Access,DB2:
-------------------------------------------------------
connect hygea.gdb;
create table temp(a int);
insert into temp values (1);
insert into temp values (1000000000000000000000000000000000);
commit;
select * from temp;arithmetic exception, numeric overflow, or string truncation
A
===========
1I would like to know what the Standard says and who is in the rigth path
PostgreSQL or the others, considering the two examples reported below.I think those other guys are unquestionably failing to conform to SQL92.
6.10 general rule 3.a saysa) If SD is exact numeric or approximate numeric, then
Case:
i) If there is a representation of SV in the data type TD
that does not lose any leading significant digits after
rounding or truncating if necessary, then TV is that rep-
resentation. The choice of whether to round or truncate is
implementation-defined.ii) Otherwise, an exception condition is raised: data exception-
numeric value out of range.and 3.3.4.1 says
The phrase "an exception condition is raised:", followed by the
name of a condition, is used in General Rules and elsewhere to
indicate that the execution of a statement is unsuccessful, ap-
plication of General Rules, other than those of Subclause 12.3,
"<procedure>", and Subclause 20.1, "<direct SQL statement>", may
be terminated, diagnostic information is to be made available,
and execution of the statement is to have no effect on SQL-data or
schemas. The effect on <target specification>s and SQL descriptor
areas of an SQL-statement that terminates with an exception condi-
tion, unless explicitly defined by this International Standard, is
implementation-dependent.I see no way that allowing the transaction to commit after an overflow
can be called consistent with the spec.regards, tom lane
************
--
Jose' Soares
Bologna, Italy Jose@sferacarta.com
From bouncefilter Wed Feb 23 08:45:34 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 IAA45201;
Wed, 23 Feb 2000 08:45:02 -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 OAA13085;
Wed, 23 Feb 2000 14:44:06 +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 12Nd5u-0000bq-00; Wed, 23 Feb 2000 14:48:50 +0000
Message-ID: <38B3E4CE.9D0DEFC@sferacarta.com>
Date: Wed, 23 Feb 2000 14:46:54 +0100
From: Jose Soares <jose@sferacarta.com>
Organization: Sfera Carta
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
CC: Tom Lane <tgl@sss.pgh.pa.us>, hackers <pgsql-hackers@postgresql.org>,
general <pgsql-general@postgresql.org>
Subject: Re: [HACKERS] TRANSACTIONS
References: <38B27760.DB921B57@sferacarta.com>
<38B27760.DB921B57@sferacarta.com>
<3.0.1.32.20000222104716.010bd050@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Don Baccus wrote:
At 11:32 AM 2/22/00 -0500, Tom Lane wrote:
I see no way that allowing the transaction to commit after an overflow
can be called consistent with the spec.You are absolutely right. The whole point is that either a) everything
commits or b) nothing commits.Having some kinds of exceptions allow a partial commit while other
exceptions rollback the transaction seems like a very error-prone
programming environment to me.
It is hard to believe all world is wrong and only we are right. Isn't it ?
;)
- 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.************
--
Jose' Soares
Bologna, Italy Jose@sferacarta.com