prob with aggregate and group by - returns multiples

George Dau <gedau@isa.mim.com.au> writes:

select count(site), site from hits group by site;

The output contains lines like the following. Note that these are all
consecutive in the output.

2|xlink.zdnet.com
2|xlink.zdnet.com
1|xlink.zdnet.com
2|xlink.zdnet.com
2|xlink.zdnet.com
2|xlink.zdnet.com
3|xlink.zdnet.com
2|xlink.zdnet.com
3|xlink.zdnet.com
2|xlink.zdnet.com
1|xlink.zdnet.com

Suspecting that there were differences in each xlink.zdnet.com, I counted
just them:

web=> select count (*) from hits where site='xlink.zdnet.com';
count
-----
22
(1 row)

So, all 22 xlink.zdnet.com are selected above, but they have not grouped in
the previous one. Any ideas why?

Wow, that is bizarre. My first thought was that you had varying numbers
of trailing blanks in the "site" values, but your second example seems
to disprove that theory.

What Postgres version are you running, and on what platform? Can you
generate a self-contained example (a script that demonstrates the error
from a standing start)? I suspect you may be hitting a platform-
specific porting problem, but it's just speculation unless we have a
self-contained test case to try on other machines.

On a lesser note: I tried "select * into temp from hits" as per the doco,
but it barfs.

Postgres thinks that TEMP is a keyword, so it won't take it as a table
name unless you put quotes around it. If we have doco examples that
use TEMP as a table name, they need to be changed --- do you recall
where you saw that, exactly?

regards, tom lane

From bouncefilter Mon Feb 28 03:08:59 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 DAA75118
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 03:08:03 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12PL2U-0003kGC; Mon, 28 Feb 100 08:56 MET
Message-Id: <m12PL2U-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
In-Reply-To: <000601bf818f$9a2e5f60$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Feb 28, 2000 11:00:35 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Mon, 28 Feb 2000 08:56:22 +0100 (CET)
CC: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>,
Peter Eisentraut <peter_e@gmx.net>
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

Hiroshi Inoue wrote:

Wow, that almost seems to easy to be true. I never thought that having
tuples of different structures in the table at the same time would be
possible. If so then I don't see a reason why this would be too hard to
do.

If the transaction is not committed, I don't think anything actually
reads the tuple columns, so you are safe.

Hmm,tuples of multiple version in a table ?
This is neither clean nor easy for me.
There's no such stuff which takes the case into account,AFAIK.

Seems no one but me object to it. I'm tired of this issue and it's
painful for me to continue discussion further in my poor English.
I may be able to provide another implementation on trial and it
may be easier than only objecting to your proposal.
Is it OK ?

Consider me on your side.

For some good reasons, I added a

ReferentialIntegritySnapshotOverride

mode, that causes any tuple to be visible when fetched by
CTID. Actually, there will be at least a read lock on them,
so locking will prevent damage. But I can think of other
situations where this kind of "read whatever I want you to"
could be needed and would fail then.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Mon Feb 28 03:02:59 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 DAA74430
for <hackers@postgresql.org>; Mon, 28 Feb 2000 03:02:57 -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 JAA115680;
Mon, 28 Feb 2000 09:01:59 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <1TSZGQ0S>; Mon, 28 Feb 2000 09:01:59 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C604AF7CFD@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'Hiroshi Inoue'" <Inoue@tpf.co.jp>
Cc: "'hackers@postgresql.org'" <hackers@postgresql.org>
Subject: AW: AW: AW: [HACKERS] TRANSACTIONS
Date: Mon, 28 Feb 2000 09:01:58 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

Yes, the only difference seems to be, that the changes need not
be sync'd to disk, and you only need one level of nesting as long
as the user is not presented the ability to use nested tx.

Hmm,what do you want now ?

I basically just wanted to say yes, but stated some differences that are
minor
and can be ignored.

Note that (f)sync is irrelevant at all.
Partial rollback is the problem of only the backend to be rollbacked
except locking.

Vadim has already planned savepoints functionality instead of nested
tx. I have never heard objections to the proposal.

I think this is the same as nested tx, at least that is my understanding.

I could see little difference between the implementation of rollback
to arbitrary savepoints and the implemention of rollback only to the
savepoint implicitly placed immediately before current statement.

Do you want another hack ?

No.

Andreas

From bouncefilter Mon Feb 28 03:02: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 DAA74386
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 03:02:32 -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 DAA21357;
Mon, 28 Feb 2000 03:02:22 -0500 (EST)
To: Jan Wieck <wieck@debis.com>
cc: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] update_pg_pwd trigger does not work very well
In-reply-to: <m12PKhX-0003kGC@orion.SAPserv.Hamburg.dsh.de>
References: <m12PKhX-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Comments: In-reply-to wieck@debis.com (Jan Wieck)
message dated "Mon, 28 Feb 2000 08:34:43 +0100"
Date: Mon, 28 Feb 2000 03:02:22 -0500
Message-ID: <21354.951724942@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

wieck@debis.com (Jan Wieck) writes:

itself do nothing except set a flag variable. The flag is examined
somewhere in xact.c after successful completion of a transaction,
and if it's set then we run a new transaction cycle in which we
read pg_shadow and write pg_pwd.

If you think that this is okay (and not just a hack), then go for it.

I consider it a hack, since this particular trigger needs a
global flag known explicitly by xact routines. I like general
solutions instead.

Well, really it's pg_pwd itself that is a hack --- we wouldn't need
to be worrying about all this if pg_pwd didn't exist outside the
database/transaction universe. But I don't think it'd be wise to
try to bring the postmaster into that universe, so we're stuck with
a hack for exporting user authorization info.

If we had examples of other problems that could be solved by such
a mechanism, then I'd agree with Jan that we ought to invent a general
after-commit-do mechanism. But I don't recall users clamoring for it,
so I question whether the extra effort is worthwhile.

regards, tom lane

From bouncefilter Mon Feb 28 03:25:59 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 DAA77000
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 03:25:18 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12PLJC-0003kGC; Mon, 28 Feb 100 09:13 MET
Message-Id: <m12PLJC-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] update_pg_pwd trigger does not work very well
In-Reply-To: <21354.951724942@sss.pgh.pa.us> from Tom Lane at "Feb 28,
2000 03:02:22 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 28 Feb 2000 09:13:38 +0100 (CET)
CC: Jan Wieck <wieck@debis.com>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <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

Tom Lane wrote:

wieck@debis.com (Jan Wieck) writes:

I consider it a hack, since this particular trigger needs a
global flag known explicitly by xact routines. I like general
solutions instead.

Well, really it's pg_pwd itself that is a hack --- we wouldn't need
to be worrying about all this if pg_pwd didn't exist outside the
database/transaction universe. But I don't think it'd be wise to
try to bring the postmaster into that universe, so we're stuck with
a hack for exporting user authorization info.

If we had examples of other problems that could be solved by such
a mechanism, then I'd agree with Jan that we ought to invent a general
after-commit-do mechanism. But I don't recall users clamoring for it,
so I question whether the extra effort is worthwhile.

Exactly these days there was someone having trouble to
dynamically load the tclLDAP package into PL/Tcl. He wanted
to UPDATE his LDAP from inside a trigger.

If he hasn't had this loading problem, I'd never known. So I
assume there are already constructs like this out there.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Mon Feb 28 03:28: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 DAA77341
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 03:28: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
DAA19846;
Mon, 28 Feb 2000 03:28:10 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002280828.DAA19846@candle.pha.pa.us>
Subject: Re: [HACKERS] A further thought on rule string size
In-Reply-To: <m12PKVK-0003kGC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Feb 28, 2000 08:22:06 am"
To: Jan Wieck <wieck@debis.com>
Date: Mon, 28 Feb 2000 03:28:10 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Removing the labels would actually save code in readfuncs.c, which
wouldn't have to skip over them. In outfuncs.c, we could either
have every node-writing subroutine know about two output modes, or
make a post-pass that strips anything that looks like a field label.
The latter would be less maintenance work in the long run.

Comments?

If you could keep the labels just for EXPLAIN, go for it.

Not right now, put it onto TODO for after 7.0.

But we just required initdb for lztext. If we need another initdb
later, maybe we should do 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 19026

From bouncefilter Mon Feb 28 03:41:00 2000
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id DAA78604
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 03:40:13 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12PLXZ-0003kGC; Mon, 28 Feb 100 09:28 MET
Message-Id: <m12PLXZ-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] A further thought on rule string size
In-Reply-To: <200002280828.DAA19846@candle.pha.pa.us> from Bruce Momjian at
"Feb 28, 2000 03:28:10 am"
To: Bruce Momjian <pgman@candle.pha.pa.us>
Date: Mon, 28 Feb 2000 09:28:29 +0100 (CET)
CC: Jan Wieck <wieck@debis.com>, Tom Lane <tgl@sss.pgh.pa.us>,
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

If you could keep the labels just for EXPLAIN, go for it.

Not right now, put it onto TODO for after 7.0.

But we just required initdb for lztext. If we need another initdb
later, maybe we should do it?

LZTEXT was a fairly limited change, tested out before and
just reapplied. This time you ask for mucking with the family
of node-print and -read functions. Even if it's a limited
area of code affected, I don't feel comfortable doing it now.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Mon Feb 28 04:44:01 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 EAA84466
for <pgsql-general@postgresql.org>;
Mon, 28 Feb 2000 04:43:54 -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 KAA05075;
Mon, 28 Feb 2000 10:43:39 +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 12PMji-0004js-00; Mon, 28 Feb 2000 09:45:06 +0000
Message-ID: <38BA3589.F665A695@sferacarta.com>
Date: Mon, 28 Feb 2000 09:44:57 +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: Peter Eisentraut <peter_e@gmx.net>
CC: Wim Ceulemans <wim.ceulemans@nice.be>,
"'general'" <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] AW: [HACKERS] TRANSACTIONS
References: <Pine.GSO.4.02A.10002241713480.17421-100000@Hummer.DoCS.UU.SE>
Content-Type: multipart/alternative;
boundary="------------A10975CF466040051F1AC573"

--------------A10975CF466040051F1AC573
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Eisentraut wrote:

On Thu, 24 Feb 2000, Jose Soares wrote:

NOTICE: (transaction aborted): all queries ignored until end of transaction block

*ABORT STATE*

Why PostgreSQL doesn't make an implicit ROLLBACK instead of waitting for a
COMMIT/ROLLBACK ?

The PostgreSQL transaction paradigm seems to be that if you explicitly
start a transaction, you get to explicitly end it. This is of course at
odds with SQL, but it seems internally consistent to me. I hope that one
of these days we can offer the other behaviour as well.

Why PostgreSQL allows a COMMIT in this case ?

Good question. I assume it doesn't actually commit though, does it? I
think a CHECK_IF_ABORTED (sp?) before calling the commit utility routine
would be appropriate. Anyone?

Seems that PostgreSQL has a basically difference from other databases, it has two
operation modes
"transaction mode" and "non-transaction mode".
If you want initialize a transaction in PostgreSQL you must declare it by using the
BEGIN WORK
statement and an END/ABORT/ROLLBACK/COMMIT statement to terminate the transaction and
switch from "transaction mode" to "non-transaction mode".
The SQL92 doesn't have such statement like BEGIN WORK because when you initialize a
connection to a database you are all the time in transaction mode.
Should it be the real problem with transactions ?

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

************

--
Jose' Soares
Bologna, Italy Jose@sferacarta.com

--------------A10975CF466040051F1AC573
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>Peter Eisentraut wrote:
<blockquote TYPE=CITE>On Thu, 24 Feb 2000, Jose Soares wrote:
<p>> NOTICE:&nbsp; (transaction aborted): all queries ignored until end
of transaction block
<br>>
<br>> *ABORT STATE*
<p>> Why PostgreSQL doesn't make an implicit ROLLBACK instead of waitting
for a
<br>> COMMIT/ROLLBACK ?
<p>The PostgreSQL transaction paradigm seems to be that if you explicitly
<br>start a transaction, you get to explicitly end it. This is of course
at
<br>odds with SQL, but it seems internally consistent to me. I hope that
one
<br>of these days we can offer the other behaviour as well.
<p>> Why PostgreSQL allows a COMMIT in this case ?
<p>Good question. I assume it doesn't actually commit though, does it?
I
<br>think a CHECK_IF_ABORTED (sp?) before calling the commit utility routine
<br>would be appropriate. Anyone?
<br>&nbsp;</blockquote>
Seems that PostgreSQL has a basically difference from other databases,
it has two operation modes
<br>"<b><u>transaction mode</u></b>" and "<b><u>non-transaction mod</u>e</b>".
<br>If you want initialize a transaction in PostgreSQL you must declare
it by using the BEGIN WORK
<br>statement and an END/ABORT/ROLLBACK/COMMIT statement to terminate the
transaction and switch from "<b><u>transaction mode</u></b>" to "<b><u>non-transaction
mode</u></b>".
<br>The SQL92 doesn't have such statement like BEGIN WORK because when
you initialize a connection to a database you are all the time in transaction
mode.
<br>Should it be the real problem with transactions ?
<blockquote TYPE=CITE>&nbsp;
<br>--
<br>Peter Eisentraut&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Sernanders vaeg 10:115
<br>peter_e@gmx.net&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
75262 Uppsala
<br><a href="http://yi.org/peter-e/&quot;&gt;http://yi.org/peter-e/&lt;/a&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;
Sweden
<p>************</blockquote>

<p>--
<br>Jose' Soares
<br>Bologna, Italy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Jose@sferacarta.com
<br>&nbsp;</html>

--------------A10975CF466040051F1AC573--

From bouncefilter Mon Feb 28 03:42:00 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 DAA78714
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 03:41: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 IAA08891;
Mon, 28 Feb 2000 08:51:50 GMT
Sender: lockhart@hub.org
Message-ID: <38BA3726.4AA47F7D@alumni.caltech.edu>
Date: Mon, 28 Feb 2000 08:51:50 +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: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <pgman@candle.pha.pa.us>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
References: <Pine.GSO.4.02A.10002231348220.29518-100000@Delfin.DoCS.UU.SE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

insert OID = 9999 ( bit varying PGUID 1 1 ...

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. ;)

I'm not sure that I agree that multi-word character types are required
internally. Somehow that seems to just push the problem of
SQL92-specific syntax to another part of the code. We could just as
easily (?) translate *every* "xxx VARYING" to "varxxx" on input, and
do the inverse on output or pg_dump.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Mon Feb 28 04:13:00 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA81143
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 04:12: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
EAA20843;
Mon, 28 Feb 2000 04:11:00 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002280911.EAA20843@candle.pha.pa.us>
Subject: Re: [HACKERS] A further thought on rule string size
In-Reply-To: <m12PLXZ-0003kGC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Feb 28, 2000 09:28:29 am"
To: Jan Wieck <wieck@debis.com>
Date: Mon, 28 Feb 2000 04:10:59 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

If you could keep the labels just for EXPLAIN, go for it.

Not right now, put it onto TODO for after 7.0.

But we just required initdb for lztext. If we need another initdb
later, maybe we should do it?

LZTEXT was a fairly limited change, tested out before and
just reapplied. This time you ask for mucking with the family
of node-print and -read functions. Even if it's a limited
area of code affected, I don't feel comfortable doing it now.

OK. Added to TODO.

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

From bouncefilter Mon Feb 28 04:14:00 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA81227
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 04:13: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
EAA20861;
Mon, 28 Feb 2000 04:11:52 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002280911.EAA20861@candle.pha.pa.us>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <38BA3726.4AA47F7D@alumni.caltech.edu> from Thomas Lockhart at
"Feb 28, 2000 08:51:50 am"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Mon, 28 Feb 2000 04:11:51 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

in the bootstrap scanner will solve the problem where it's being caused.
Internal type names should go away, not accumulate. ;)

I'm not sure that I agree that multi-word character types are required
internally. Somehow that seems to just push the problem of
SQL92-specific syntax to another part of the code. We could just as
easily (?) translate *every* "xxx VARYING" to "varxxx" on input, and
do the inverse on output or pg_dump.

Yes, seems we just don't want to do that during beta. I forgot about
this item I had promised. Sorry.

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

From bouncefilter Mon Feb 28 12:42:07 2000
Received: from hotmail.com (f89.law7.hotmail.com [216.33.237.89])
by hub.org (8.9.3/8.9.3) with SMTP id MAA45447
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 12:41:24 -0500 (EST)
(envelope-from jemonje@hotmail.com)
Received: (qmail 66502 invoked by uid 0); 28 Feb 2000 17:40:51 -0000
Message-ID: <20000228174051.66501.qmail@hotmail.com>
Received: from 216.72.5.205 by www.hotmail.com with HTTP;
Mon, 28 Feb 2000 09:40:51 PST
X-Originating-IP: [216.72.5.205]
From: "Joaquin Eduardo Monje" <jemonje@hotmail.com>
To: pgsql-hackers@postgreSQL.org
Subject: ask sybase - postgres
Date: Mon, 28 Feb 2000 09:40:51 PST
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

Hi,

How I can convert some tables since sybase to posgtres.

thank a lot
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From bouncefilter Mon Feb 28 12:42:06 2000
Received: from hotmail.com (f30.law7.hotmail.com [216.33.237.30])
by hub.org (8.9.3/8.9.3) with SMTP id MAA45477
for <pgsql-hackers@postgresql.org>;
Mon, 28 Feb 2000 12:41:41 -0500 (EST)
(envelope-from jemonje@hotmail.com)
Received: (qmail 24172 invoked by uid 0); 28 Feb 2000 17:41:08 -0000
Message-ID: <20000228174108.24171.qmail@hotmail.com>
Received: from 216.72.5.205 by www.hotmail.com with HTTP;
Mon, 28 Feb 2000 09:41:08 PST
X-Originating-IP: [216.72.5.205]
From: "Joaquin Eduardo Monje" <jemonje@hotmail.com>
To: pgsql-hackers@postgresql.org
Subject: ask sybase - postgres
Date: Mon, 28 Feb 2000 09:41:08 PST
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

Hi,

How I can convert some tables since sybase to posgtres.

thank a lot
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From bouncefilter Mon Feb 28 04:37:00 2000
Received: from hu.tm.ee (ppp866.tele2.ee [212.107.37.166])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA83536
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 04:36:48 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 3876B39AD; Mon, 28 Feb 2000 11:45:53 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38BA43D0.559054E4@tm.ee>
Date: Mon, 28 Feb 2000 11:45:52 +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: Hiroshi Inoue <Inoue@tpf.co.jp>, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
References: <20132.951705014@sss.pgh.pa.us>
<3.0.1.32.20000227212630.00fbfb20@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Don Baccus wrote:

At 12:21 PM 2/28/00 +0900, Hiroshi Inoue wrote:

My idea is essentially an invisible column implementation.
DROP COLUMN would change the target pg_attribute tuple
as follows..

I don't see such a solution as being mutually exclusive with
the other one on the table.

Very true, and we will need the hidden columns feature for a clean
implementation of inheritance anyway.

Remember ... Oracle provides both. I suspect that they did so
because they were under customer pressure to provide a "real"
column drop and a "fast" (and non-2x tablesize!) solution. So
they did both. Also keep in mind that being able to drop a
column in Oracle is a year 1999 feature ... and both are provided.
More evidence of pressure from two points of view.

Of course, PG suffers because the "real" column drop is a 2x
space solution, so the "invisibility" approach may more frequently
be desired.

"update t set id=id+1" is also a 2x space, likely even more if
referential inheritance is used (and checked at the end of transaction)

And my main use of DROP COLUMN will probably be during development,
usually meaning small table sizes.

------------
Hannu

From bouncefilter Mon Feb 28 05:04:01 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 FAA86759
for <pgsql-hackers@postgresql.org>;
Mon, 28 Feb 2000 05:03:20 -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 12PN1D-0006Fq-00; Mon, 28 Feb 2000 13:03:11 +0300
Date: Mon, 28 Feb 2000 10:03:10 +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: Locale support broken in latest snapshots
Message-ID: <Pine.LNX.4.21.0002280958080.24005-100000@fep132.fep.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hello!

A month ago I tested a snapshot (21 or 24 Jan), and locale/multibyte
support worked.
In the snapshot of 21 Feb locale support have been broken. "SELECT *
FROM table ORDER BY name" returns rows in wrong order; "SELECT * FROM table
WHERE name ~* re" performs case-sensitive match.

I remember Tatsuo once fixed case-sensitiveness by replacing char with
"unsigned char". Should I teach my gcc to always use unsigned chars?

Oleg.
----
Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net
Programmers don't die, they just GOSUB without RETURN.

From bouncefilter Mon Feb 28 05:59: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 FAA91960
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 05: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 FAA00790
for pgsql-hackers@postgreSQL.org; Mon, 28 Feb 2000 05:58:28 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002281058.FAA00790@candle.pha.pa.us>
Subject: 7.0 Changes list
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Mon, 28 Feb 2000 05:58:27 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM951735507-22819-0_
Content-Transfer-Encoding: 7bit

--ELM951735507-22819-0_
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Here is an updated version of the HISTORY file for 7.0.

I have added sections on Types and Performance to try and reduce the
number of items in each section.

Still, the list is so long as to be almost unreadable.

I can't figure out how to reduce it. I mention all user-visible changes
in the release, as I have done in the past. The problem is that the
list is almost twice the size compared to previous releases.

If I were MySQL or another commercial database, I would be worried by
the list of items I see here. There are a ton 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 19026

--ELM951735507-22819-0_
Content-Type: text/plain
Content-Disposition: inline; filename="/root/cvslog"
Content-Transfer-Encoding: 7bit

This release shows the continued growth of PostgreSQL. There are more
updated items in 7.0 than in any previous release. Don't be concerned
this is a dot-zero release. PostgreSQL does its best to put
out only solid releases, and this one is no exception.

Major changes in this release:

Foreign Keys: Foreign keys are now implemented, with the exception of
PARTIAL MATCH foreign keys. Many users have been asking for this
feature, and we are pleased to finally offer it.

Optimizer Overhaul: Continuing on work started a year ago, the
optimizer has been overhauled in many significant ways, allowing better
query execution processing with faster performance and less memory
usage.

Updated psql: psql, our interactive terminal monitor, has been updated,
with a variety of new features. See the psql manual page for the details.

Upcoming Features: In 7.1, we plan to have outer joins, storage for very long
rows, and a write-ahead logging system.

Bug Fixes
---------
Prevent function calls with more than maximum number of arguments (Tom)
Many fixes for CASE (Tom)
Fix SELECT coalesce(f1,0) FROM int4_tbl GROUP BY f1 (Tom)
Fix SELECT sentence.words[0] FROM sentence GROUP BY sentence.words[0] (Tom)
Allow utility statements in plpgsql (Tom)
Fix GROUP BY scan bug (Tom)
Improvements in SQL grammar processing (Tom)
Fix for views involved in INSERT ... SELECT ... (Tom)
Fix for SELECT a/2, a/2 FROM test_missing_target GROUP BY a/2 (Tom)
Fix for subselects in INSERT ... SELECT (Tom)
Prevent INSERT ... SELECT ... ORDER BY (Tom)
Fixes for relations greater than 2GB, including vacuum
Improve communication of system table changes to other running backends (Tom)
Improve communication of user table modifications to other running backends (Tom)
Fix handling of temp tables in complex situations (Bruce, Tom)
Disallow DROP TABLE/DROP INDEX inside a transaction block
Allow table locking when tables opened, improving concurrent reliability (Tom)
Properly quote sequence names in pg_dump (Ross J. Reedstrom)
Prevent DESTROY DATABASE while others accessing
Prevent any rows from being returned by GROUP BY if no rows processed (Tom)
Fix SELECT COUNT(1) FROM table WHERE ...' if no rows matching WHERE (Tom)
Fix pg_upgrade so it works for MVCC(Tom)
Fix for SELECT ... WHERE x IN (SELECT ... HAVING SUM(x) > 1) (Tom)
Make TABLE optional keyword in LOCK TABLE (Bruce)
Fix for "f1 datetime DEFAULT 'now'" (Tom)
Fix problems with CURRENT_DATE used in DEFAULT (Tom)
Allow comment-only lines, and ;;; lines too. (Tom)
Improve recovery after failed disk writes, disk full (Hiroshi)
Fix cases where table is mentioned in FROM but not joined (Tom)
Allow HAVING clause without aggregate functions (Tom)
Fix for "--" comment and no trailing newline, as seen in Perl
Improve pg_dump failure error reports (Bruce)
Allow sorts and hashes to exceed 2GB file sizes (Tom)
Fix for pg_dump dumping of inherited rules (Tom)
Fix for NULL handling comparisons (Tom)
Fix inconsistent state caused by failed CREATE/DROP commands (Hiroshi)
Fix for dbname with dash
Prevent DROP INDEX from interfering with other backends (Tom)
Fix file descriptor leak in verify_password()
Fix for "Unable to identify an operator =$" problem
Fix ODBC so no segfault if CommLog and Debug enabled (Dirk Niggemann)
Fix for recursive exit call (Massimo)
Fix for extra-long timezones (Jeroen van Vianen)
Make pg_dump preserve primary key information (Peter E)
Prevent databases with single quotes (Peter E)
Prevent DROP DATABASE inside transaction (Peter E)
ecpg memory leak fixes (Stephen Birch)
Fix for SELECT null::text, SELECT int4fac(null) and SELECT 2 + (null) (Tom)
Y2K timestamp fix (Massimo)
Fix for VACUUM 'HEAP_MOVED_IN was not expected' errors (Tom)
Fix for views with tables/columns containing spaces (Tom)
Prevent permissions on indexes (Peter E)
Fix for spinlock stuck problem when error is generated (Hiroshi)
Fix ipcclean on Linux
Fix handling of NULL constraint conditions (Tom)
Fix memory leak in odbc driver (Nick Gorham)

Enhancements
------------
New CLI interface include file sqlcli.h, based on SQL3/SQL98
Remove all limits on query length, row length limit still exists (Tom)
Update jdbc protocol to 2.0 (Jens Glaser jens@jens.de)
Add TRUNCATE command to quickly truncate relation (Mike Mascari)
Fix to give super user and createdb user proper update catalog rights (Peter E)
Allow ecpg bool variables to have NULL values (Christof)
Issue ecpg error if NULL value is returned to variable with no NULL
indicator (Christof)
Allow ^C to cancel COPY command (Massimo)
Add SET FSYNC and SHOW PG_OPTIONS commands(Massimo)
Improve CREATE FUNCTION to allow type conversion specification
(Bernie Frankpitt)
Add CmdTuples() to libpq++(Vince)
New CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands(Jan)
Allow CREATE FUNCTION WITH clause to be used for all language types
configure --enable-debug adds -g (Peter E)
configure --disable-debug removes -g (Peter E)
Allow more complex default expressions (Tom)
First real FOREIGN KEY constraint trigger functionality (Jan)
Add FOREIGN KEY ... MATCH FULL ... ON DELETE CASCADE (Jan)
Add FOREIGN KEY ... MATCH <unspecified> referential actions (Don Baccus)
Allow WHERE restriction on ctid (physical heap location) (Hiroshi)
Move pginterface from contrib to interface directory, rename to pgeasy (Bruce)
Add DEC and SESSION_USER as reserved words
Require SELECT DISTINCT target list to have all ORDER BY columns (Tom)
Add Oracle's COMMENT ON command (Mike Mascari <mascarim@yahoo.
libpq's PQsetNoticeProcessor function now returns previous hook(Peter E)
Prevent PQsetNoticeProcessor from being set to NULL (Peter E)
Make USING in COPY optional (Bruce)
Allow subselects in the target list (Tom)
Allow subselects on the left side of comparison operators (Tom)
New parallel regression test (Jan)
Change backend-side COPY to write files with permissions 644 not 666 (Tom)
Force permissions on PGDATA directory to be secure, even if it exists (Tom)
Added psql LastOid variable to return last inserted oid (Peter E)
Allow concurrent vacuum and remove pg_vlock vacuum lock file (Tom)
Add permissions check so only Postgres superuser or table owner can
vacuum (Peter E)
New libpq functions to allow asynchronous connections: PQconnectStart(),
PQconnectPoll(), PQresetStart(), PQresetPoll(), PQsetenvStart(),
PQsetenvPoll(), PQsetenvAbort (Ewan Mellor)
New libpq PQsetenv() function (Ewan Mellor)
create/alter user extension (Peter E)
New postmaster.pid and postmaster.opts under $PGDATA (Tatsuo)
New scripts for create/drop user/db (Peter E)
Major psql overhaul(Peter E)
Add const to libpq interface(Peter E)
New libpq function PQoidValue (Peter E)
Show specific non-aggregate causing problem with GROUP BY (Tom)
Make changes to pg_shadow recreate pg_pwd file (Peter E)
Add aggregate(DISTINCT ...) (Tom)
Allow flag to control COPY input/output of NULLs (Peter E)
Make postgres user have a password by default (Peter E)
Add CREATE/ALTER/DROP GROUP (Peter E)
All administration scripts now support --long options (Peter E, Karel)
Vacuumdb script now supports --alldb option (Peter E)
ecpg new portable FETCH syntax
Add ecpg EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF
and EXEC SQL ENDIF directives
Add pg_ctl script to control backend startup (Tatsuo)
Add postmaster.opts.default file to store startup flags (Tatsuo)
Allow --with-mb=SQL_ASCII
Increase maximum number of index keys to 16 (Bruce)
Increase maximum number of function arguments to 16 (Bruce)
Allow user configuration of maximum number of index keys and arguments
(Bruce)
Allow unprivileged users to change their passwords (Peter E)
With password authentication enabled, new users without passwords can't
connect (Peter E)
Disallow dropping a user who owns a database (Peter E)
Add initdb --enable-multibyte option (Peter E)
Add option for initdb to prompts for superuser password (Peter E)
Allow complex type casts like col::numeric(9,2) and col::int2::float8 (Tom)
Updated user interfaces on initdb, initlocation, pg_dump, ipcclean
(Peter E)
New pg_char_to_encoding() and pg_encoding_to_char() functions (Tatsuo
Libpq non-blocking mode (Alfred Perlstein)
Improve conversion of types in casts that don't specify a length
New plperl internal programming language (Mark Hollomon)
Allow COPY IN to read file that do not end with a newline (Tom)
Indicate when long identifiers are truncated (Tom)
Allow aggregates to use type equivalency (Peter E)
Add Oracle's to_char(), to_date(), to_datetime(), to_timestamp(), to_number()
conversion functions (Karel Zak <zakkr@zf.jcu.cz>)
Add SELECT DISTINCT ON (expr [, expr ...]) targetlist ... (Tom)
Check to be sure ORDER BY is compatible with the DISTINCT operation (Tom)
Add NUMERIC and int8 types to ODBC
Improve EXPLAIN results for Append, Group, Agg, Unique (Tom)
Add ALTER TABLE ... ADD FOREIGN KEY (Stephan Szabo)
Allow SELECT .. FOR UPDATE in PL/pgSQL (Hiroshi)
Enable backward sequential scan even after reaching EOF (Hiroshi)
Add btree indexing of boolean values, >= and <= (Don Baccus)
Print current line number when COPY FROM fails (Massimo)
Recognize special case of POSIX time zone: "GMT+8" and "GMT-8" (Thomas)
Add DEC as synonym for "DECIMAL (Thomas)
Add SESSION_USER as SQL92 keyword, same as CURRENT_USER (Thomas)
Implement column aliases (aka correlation names) and more join syntax
(Thomas)
Allow queries like SELECT a FROM t1 tx (a) (Thomas)
Allow queries like SELECT * FROM t1 NATURAL JOIN t2 (Thomas)
Make INTERVAL reserved word allowed as a column identifier (Thomas)
Implement REINDEX command (Hiroshi)
Accept ALL in aggregate function SUM(ALL col) (Tom)
Prevent GROUP BY from using column aliases (Tom)
New psql \encoding option (Tatsuo)
Allow PQrequestCancel() to terminate when in waiting-for-lock state (Hiroshi)
Allow negation of a negative number in all cases
Add ecpg descriptors
Allow CREATE VIEW v AS SELECT f1::char(8) FROM tbl
New libpq functions PQsetClientEncoding(), PQclientEncoding() (Tatsuo)
Add support for SJIS user defined characters (Tatsuo)
Larger views/rules supported

Types
-----
Many array fixes (Tom)
Allow bare column names to be subscripted as arrays (Tom)
Improve type casting of int and float constants (Tom)
Cleanups for int8 inputs, range checking, and type conversion (Tom)
Fix for SELECT timespan('21:11:26'::time) (Tom)
Fix for netmask('x.x.x.x/0') is 255.255.255.255 instead of 0.0.0.0
(Oleg Sharoiko)
Add btree index on NUMERIC(Jan)
Perl fix for large objects containing NUL characters (Douglas Thomson)
ODBC fix for for large objects (free)
Fix indexing of cidr data type
Fix for Ethernet MAC addresses (macaddr type) comparisons
Fix for date/time types when overflows happened in computations (Tom)
Allow array on int8 (Peter E)
Fix for rounding/overflow of NUMERIC type, like NUMERIC(4,4) (Tom)
Allow NUMERIC arrays
Fix bugs in NUMERIC ceil() and floor() functions (Tom)
Make char_length()/octet_length including trailing blanks (Tom)
Made abstime/reltime use int4 instead of time_t (Peter E)
New lztext data type for compressed text fields
Revise code to handle coercion of int and float constants (Tom)
New C-routines to implement a BIT and BIT VARYING type in /contrib
(Adriaan Joubert)
NUMERIC now accepts scientific notation (Tom)
NUMERIC to int4 rounds (Tom)
Convert float4/8 to NUMERIC properly (Tom)
Allow type conversion with NUMERIC (Thomas)
Make ISO date style (2000-02-16 09:33) the default (Thomas)

Performance
-----------
Prevent exponential space consumption with many AND's and OR's (Tom)
Collect attribute selectivity values for system columns (Tom)
Reduce memory usage of aggregates (Tom)
Fix for LIKE optimization to use indexes with multi-byte encodings (Tom)
Fix r-tree index optimizer selectivity (Thomas)
Improve optimizer selectivity computations and functions (Tom)
Optimize btree searching for cases where many equal keys exist (Tom)
Enable fast LIKE index processing only if index present (Tom)
Re-use free space on index pages with duplicates (Tom)
Improve hash join processing (Tom)
Prevent descending sort if result is already sorted(Hiroshi)
Allow commuting of index scan query qualifications (Tom)
Prefer index scans in cases where ORDER BY/GROUP BY is required (Tom)
Allocate large memory requests in fix-sized chunks for performance (Tom)
Fix vacuum's performance by reducing memory allocation requests (Tom)
Implement constant-expression simplification (Bernard Frankpitt, Tom)
Allow more than first column to be used to determine start of index scan
(Hiroshi)
Prevent quadruple use of disk space when doing internal sorting (Tom)
Faster sorting by calling fewer functions (Tom)
Create system indexes to match all system caches (Bruce, Hiroshi)
Make system caches use system indexes(Bruce)
Make all system indexes unique(Bruce)
Improve pg_statistics management for VACUUM speed improvement (Tom)
Flush backend cache less frequently (Tom, Hiroshi)
COPY now reuses previous memory allocation, improving performance (Tom)
Improve optimization cost estimation (Tom)
Improve optimizer estimate of range queries x > lowbound AND x < highbound (Tom)
Use DNF instead of CNF where appropriate (Tom, Taral)
Further cleanup for OR-of-AND WHERE-clauses (Tom)
Make use of index in OR clauses (x = 1 AND y = 2) OR (x = 2 AND y = 4) (Tom)
Smarter optimizer computations for random index page access (Tom)
New SET variable to control optimizer costs (Tom)
Optimizer queries based on LIMIT, OFFSET, and EXISTS qualifications (Tom)
Reduce optimizer internal housekeeping of join paths for speedup (Tom)

Source Tree Changes
-------------------
Fix for linux PPC compile
New generic expression-tree-walker subroutine (Tom)
Change form() to varargform() to prevent portability problems.
Improved range checking for large integers on Alpha's
Clean up #include in /include directory (Bruce)
Add scripts for checking includes (Bruce)
Remove un-needed #include's from *.c files (Bruce)
Change #include's to use <> and "" as appropriate (Bruce)
Enable WIN32 compilation of libpq
Alpha spinlock fix from Uncle George <gatgul@voicenet.com>
Overhaul of optimizer data structures (Tom)
Fix to cygipc library (Yutaka Tanida)
Allow pgsql to work on newer Cygwin snapshots(Dan)
New catalog version number (Tom)
Add Linux ARM.
Rename heap_replace to heap_update
Update for QNX (Kardos, Dr. Andrea)
New platform-specific regression handling (Tom)
Rename oid8 -> oidvector and int28 -> int2vector (Bruce)
Included all yacc and lex files into the distribution (Peter E.)
Remove lextest, no longer needed (Peter E)
Fix for libpq and psql on Win32 (Magnus)
Internally change datetime and timespan into timestamp and interval (Thomas)
Fix for plpgsql on BSDI
Add SQL_ASCII test case to the regression test (Tatsuo)
configure --with-mb now deprecated (Tatsuo)

--ELM951735507-22819-0_

--ELM951735507-22819-0_--

From bouncefilter Mon Feb 28 06:36:02 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 GAA93912
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 06:35:24 -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 MAA09478;
Mon, 28 Feb 2000 12:30:46 +0100
Date: Mon, 28 Feb 2000 12:30:45 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Peter Eisentraut <peter_e@gmx.net>
cc: Jan Wieck <wieck@debis.com>, Hiroshi Inoue <Inoue@tpf.co.jp>,
Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Cache query implemented
In-Reply-To: <Pine.LNX.4.21.0002251507370.3063-100000@localhost.localdomain>
Message-ID: <Pine.LNX.3.96.1000228110508.2717A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 26 Feb 2000, Peter Eisentraut wrote:

Karel Zak - Zakkr writes:

I still not sure with PREPARE/EXECUTE keywords, I vote for:

CREATE PLAN name AS query [ USING type, ... ]
EXECUTE PLAN name [ USING values, ... ]
DROP PLAN name

Comments? (Please. I really not SQL's standard guru...)

SQL seems to have something like the following. (Note: The section on
dynamic SQL is mostly incomprehensible to me.)

I'am studing SQL92 just now. And I not sure if my idea is same as SQL92's
PREPARE. My implementation is very simular with SPI's plan operations,
and is designed as simple way to very fast query execution.

PREPARE name AS query

In my PREPARE go query to parser and if in PG query is '$n', parser needs
(Oid) argstypes array, hence it needs

PREPARE name AS <query with parameters - $n> USING valuetype, ...

But in SQL92 is PREPARE without "USING valuetype, ...".

DESCRIBE INPUT name [ USING x, ... ]
DESCRIBE [OUTPUT] name [ USING x, ... ]

It is probably used instead 'USING' in PREPARE. It specific columns
for select (OUTPUT) and INPUT specific values for parser ($n paremetrs
in PG).

People which define SQL92 must be crazy. This PREPARE concept split one
query plan to three commands. Who join it to one plan?....

EXECUTE name [ INTO x, y, ... ] [ USING a, b, ... ]

This command "Associate input parametrs and output targets with a prepared
statement and execute the statement" (SQL92).

'INTO' - I really not sure if is possible in PG join more plans into
one plan. If I good understand, INTO is targetlist for cached
query, but in cached query is targetlist too. Is any way how join/replace
targetlist in cached query with targetlist from EXECUTE's INTO?
(QueryRewrite?). But, INTO for EXECUTE is nod bad idea.

DEALLOCATE PREPARE name

It is better than 'DROP'.

Meanwhile I'm wondering whether it would not be possible to provide the
plan caching functionality even if all you do is send the same SELECT
twice in a row. Might be tricky, of course.

Here, I'am not understand you.

Exist any other SQL which has implemented a PREPARE/EXECUTE?
(Oracle8 has not it, and other..?)

I still vote for simple PREPARE/EXECUTE (or non-standard CREATE PLAN),
because SQL92's PREPARE is not implementable :-)

Karel

From bouncefilter Mon Feb 28 07:50:03 2000
Received: from smtprtp.ntcom.nortel.net (smtprtp.ntcom.nortel.net
[137.118.22.15]) by hub.org (8.9.3/8.9.3) with ESMTP id HAA99610
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 07:49:07 -0500 (EST)
(envelope-from mhh@nortelnetworks.com)
Received: from zrtpd004.us.nortel.com (actually zrtpd004)
by smtprtp.ntcom.nortel.net; Mon, 28 Feb 2000 07:48:09 -0500
Received: from zrtpd003.us.nortel.com ([47.140.224.137])
by zrtpd004.us.nortel.com
with SMTP (Microsoft Exchange Internet Mail Service Version
5.5.2650.21) id F48T4XBA; Mon, 28 Feb 2000 07:48:08 -0500
Received: from americasm01.nt.com (hrtpp28d.us.nortel.com [47.190.110.250])
by zrtpd003.us.nortel.com
with SMTP (Microsoft Exchange Internet Mail Service Version
5.5.2650.21) id FXSM1T8C; Mon, 28 Feb 2000 07:48:07 -0500
Message-ID: <38BA6F1B.61E8643@americasm01.nt.com>
Date: Mon, 28 Feb 2000 07:50:35 -0500
From: "Mark Hollomon" <mhh@nortelnetworks.com>
Reply-To: "Mark Hollomon" <mhh@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.04 [en] (Win95; U)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Is anyone working on pg_dump?
References: <4779.951674423@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

One of the major must-fix items remaining on my to-do-for-7.0 list
is making pg_dump smarter about the order to dump stuff in, so as
to avoid problems like table constraints referring to not-yet-
defined functions.

We have talked about this before, and I thought some people had
expressed interest in fixing it, but I haven't seen any results.
Is anyone working on it?

I had expressed interest in working on this, but have run out of
spare time. Please feel free.

--

Mark Hollomon
mhh@nortelnetworks.com
ESN 451-9008 (302)454-9008

From bouncefilter Mon Feb 28 08:21:03 2000
Received: from thelab.hub.org (nat196.115.mpoweredpc.net [142.177.196.115])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA02221
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 08:20:09 -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 JAA28795;
Mon, 28 Feb 2000 09:17:59 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 28 Feb 2000 09:17:59 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Hiroshi Inoue <Inoue@tpf.co.jp>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Re: ALTER TABLE DROP COLUMN
In-Reply-To: <000f01bf81bb$c3b8d140$2801007e@tpf.co.jp>
Message-ID: <Pine.BSF.4.21.0002280912170.81087-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 28 Feb 2000, Hiroshi Inoue wrote:

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]

I would also change attname to '*already dropped %d' for
examle to avoid duplicate attname.

Okay, just curious here, but ... what you are proposing *sounds* to me
like half-way to what started this thread. (*Please* correct me if I'm
wrong) ...

Essentially, in your proposal, when you drop a column, all subsequent
tuples inserted/updated would have ... that one column missing? So,
instead of doing a massive sweep through the table and removing that
column, only do it when an insert/update happens?

Basically, eliminate the requirement to re-write every tuples,

only those

that have activity?

And I think the problem was that there was too much code to modify to
allow this.

Seems my trial would be useless.
I would give up the trial.

Hiroshi ...

Bruce's comment was just an observation ... if it can be done
cleanly, I would love to see a version that didn't involve 2x the disk
space ... I don't believe that a trial would be useless, I think that
Bruce's only concern/warning is that the amount of code modifications that
would have to be made in order to accomplish this *might* be larger then
the benefit resulting in doing it this way.

If you feel that this can be done more efficiently, *please*
proceed with the trial ...

I'm curious about one thing ... several ppl have mentioned that
Oracle does it "both ways" ... does anyone know the syntax they use so
that someone can do it one way or another?

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 28 09:04:05 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 JAA05549
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 09:03:35 -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 PAA31481;
Mon, 28 Feb 2000 15:03:18 +0100
Date: Mon, 28 Feb 2000 15:03:17 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Peter Eisentraut <peter_e@gmx.net>
cc: Jan Wieck <wieck@debis.com>, Hiroshi Inoue <Inoue@tpf.co.jp>,
Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Cache query implemented
In-Reply-To: <Pine.LNX.3.96.1000228110508.2717A-100000@ara.zf.jcu.cz>
Message-ID: <Pine.LNX.3.96.1000228144441.19731B-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

EXECUTE name [ INTO x, y, ... ] [ USING a, b, ... ]

This command "Associate input parametrs and output targets with a prepared
statement and execute the statement" (SQL92).

'INTO' - I really not sure if is possible in PG join more plans into
one plan. If I good understand, INTO is targetlist for cached
query, but in cached query is targetlist too. Is any way how join/replace
targetlist in cached query with targetlist from EXECUTE's INTO?
(QueryRewrite?). But, INTO for EXECUTE is nod bad idea.

Sorry, previous paragraph is stupid. The 'into' is simple item in
the query struct and not any targetlist. I spend more time with previous
stupidity than with implementation:

EXECUTE <name>
[ INTO [ TEMPORARY | TEMP ] [ TABLE ] new_table ]
[ USING val, ... ]

test=# prepare sel as select * from tab;
PREPARE
test=# execute sel into x;
SELECT
test=# select * from x;
id | data
----+------
1 | aaaa
2 | bbbb
3 | cccc
4 | dddd
5 | eeee
(5 rows)

The PostgreSQL source code is really very modular :-)

Karel

From bouncefilter Mon Feb 28 09:11:06 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 JAA06285
for <pgsql-hackers@postgresql.org>;
Mon, 28 Feb 2000 09:11:03 -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 PAA23311
for <pgsql-hackers@postgresql.org>;
Mon, 28 Feb 2000 15:10:59 +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 12PRs7-0000Ku-00; Mon, 28 Feb 2000 15:14:07 +0000
Message-ID: <38BA829F.C8BA2978@sferacarta.com>
Date: Mon, 28 Feb 2000 15:13:51 +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>
Subject: having and union in v7beta
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'm comparing v6.5.2 against v7.0 and I see now:
UPDATEs and INSERTs are faster in v7.0 than v5.6.2 but
SELECTs are slow, specially:
SELECT ... UNION (is 3 / 4 times slow)
and
SELECT...HAVING, this last for example doesn't work.

I'm waiting for hours to have the result of following query:

EXPLAIN select * from comuni where nome in
(select nome from comuni group by nome having 1 < count(nome));

Seq Scan on comuni (cost=0.00..3429753.65 rows=8342 width=84)
SubPlan
-> Aggregate (cost=0.00..822.22 rows=834 width=12)
-> Group (cost=0.00..801.37 rows=8342 width=12)
-> Index Scan using knome on comuni (cost=0.00..780.51
rows=8)

EXPLAIN

--
Jose' Soares
Bologna, Italy Jose@sferacarta.com

From bouncefilter Mon Feb 28 09:35: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 JAA13479
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 09:34: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 GAA21772;
Mon, 28 Feb 2000 06:33:33 -0800 (PST)
Message-Id: <3.0.1.32.20000228061620.00fc7ec0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 28 Feb 2000 06:16:20 -0800
To: Jan Wieck <wieck@debis.com>, Peter Eisentraut <peter_e@gmx.net>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] update_pg_pwd trigger does not work very well
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <m12PKhX-0003kGC@orion.SAPserv.Hamburg.dsh.de>
References: <Pine.LNX.4.21.0002280037230.2468-100000@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 08:34 AM 2/28/00 +0100, Jan Wieck wrote:

I consider it a hack, since this particular trigger needs a
global flag known explicitly by xact routines. I like general
solutions instead.

It's very much a hack. Something like the "on commit execute()"
solution would be much better. How crucial is a short-term fix
for this particular problem? Could it wait until a more generalized
facility is provided?

If not I suppose it could be hacked in with copious notes that it
should be redone later.

- 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 28 09:35:07 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 JAA13473
for <pgsql-hackers@postgresql.org>;
Mon, 28 Feb 2000 09:34: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 GAA21777;
Mon, 28 Feb 2000 06:33:34 -0800 (PST)
Message-Id: <3.0.1.32.20000228062141.00fc5080@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 28 Feb 2000 06:21:41 -0800
To: Jan Wieck <wieck@debis.com>, Bruce Momjian <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] A further thought on rule string size
Cc: Jan Wieck <wieck@debis.com>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgresql.org
In-Reply-To: <m12PLXZ-0003kGC@orion.SAPserv.Hamburg.dsh.de>
References: <200002280828.DAA19846@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 09:28 AM 2/28/00 +0100, Jan Wieck wrote:

If you could keep the labels just for EXPLAIN, go for it.

Not right now, put it onto TODO for after 7.0.

But we just required initdb for lztext. If we need another initdb
later, maybe we should do it?

LZTEXT was a fairly limited change, tested out before and
just reapplied. This time you ask for mucking with the family
of node-print and -read functions. Even if it's a limited
area of code affected, I don't feel comfortable doing it now.

And lztext compression of the rule strings is such a big win that
I suspect folks upgrading from 6.5 to 7.0 won't have to worry about
having their views blow up in their face. So the "mini-crisis" is
solved, folks will be able to upgrade smoothly, and in practice will
be able to build views on tables with many more columns.

Removing the additional verbosity from the rule strings is also a
good idea, but doesn't feel like a critical-path thing to me. So
I think Jan's right, it can wait.

- 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 28 09:34: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 JAA13438
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 09:34:00 -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 GAA21781;
Mon, 28 Feb 2000 06:33:35 -0800 (PST)
Message-Id: <3.0.1.32.20000228062929.00fbd4c0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 28 Feb 2000 06:29:29 -0800
To: Hannu Krosing <hannu@tm.ee>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
Cc: Hiroshi Inoue <Inoue@tpf.co.jp>, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <38BA43D0.559054E4@tm.ee>
References: <20132.951705014@sss.pgh.pa.us>
<3.0.1.32.20000227212630.00fbfb20@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 11:45 AM 2/28/00 +0200, Hannu Krosing wrote:

"update t set id=id+1" is also a 2x space,

And PG doesn't do it correctly anyway...

likely even more if
referential inheritance is used (and checked at the end of transaction)

The triggers are all queued so yes, take memory too. Even better,
if "MATCH <unspecified>" or especially "MATCH PARTIAL" is used with
multi-column foreign keys containing nulls, it will be impressively slow!
We can call these the built-in coffee break feature when used on large
tables.

(it's inherently slow, not just slow because of the PG implementation)

And my main use of DROP COLUMN will probably be during development,
usually meaning small table sizes.

Well, folks who use the web toolkit I've been porting for Oracle will
have a use for it, too, because the toolkit has been rapidly evolving
(ArsDigita has about 70 employees at the moment, most of them programmers
working on the Oracle-based version of the toolkit). ArsDigita provides
upgrade .sql files for each version that consist in part of ADD/DROP
column statements so users can upgrade in place, a very useful thing.

It doesn't need to be fast in this context, just work. You tell the world
your site will be down for an evening on such-and-such date, stop
listening on port 80, and upgrade.

- 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 28 09:41: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 JAA14073
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 09:40:10 -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 JAA25156;
Mon, 28 Feb 2000 09:40:01 -0500 (EST)
To: Jan Wieck <wieck@debis.com>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] A further thought on rule string size
In-reply-to: <m12PLXZ-0003kGC@orion.SAPserv.Hamburg.dsh.de>
References: <m12PLXZ-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Comments: In-reply-to wieck@debis.com (Jan Wieck)
message dated "Mon, 28 Feb 2000 09:28:29 +0100"
Date: Mon, 28 Feb 2000 09:40:01 -0500
Message-ID: <25153.951748801@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

wieck@debis.com (Jan Wieck) writes:

But we just required initdb for lztext. If we need another initdb
later, maybe we should do it?

That was what I was thinking, too. But...

LZTEXT was a fairly limited change, tested out before and
just reapplied. This time you ask for mucking with the family
of node-print and -read functions. Even if it's a limited
area of code affected, I don't feel comfortable doing it now.

Yeah, Jan is probably right --- too much risk of breaking something
and not noticing till after release. 7.0 will already allow longer
rules than 6.5 because of lztext, so it's not critical to do this now.
Let's wait.

regards, tom lane

From bouncefilter Mon Feb 28 09:47: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 JAA14811
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 09:46: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 JAA25207;
Mon, 28 Feb 2000 09:46:10 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-reply-to: <38BA3726.4AA47F7D@alumni.caltech.edu>
References: <Pine.GSO.4.02A.10002231348220.29518-100000@Delfin.DoCS.UU.SE>
<38BA3726.4AA47F7D@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Mon, 28 Feb 2000 08:51:50 +0000"
Date: Mon, 28 Feb 2000 09:46:10 -0500
Message-ID: <25204.951749170@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

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. ;)

I'm not sure that I agree that multi-word character types are required
internally. Somehow that seems to just push the problem of
SQL92-specific syntax to another part of the code.

It doesn't push it anywhere: you still have the problem that the parser
expects type names to be single tokens, not multiple tokens, and any
exceptions need to be special-cased in the grammar. We can handle that
for the few multi-word type names decreed by SQL92. But allowing
internal type names to be multi-word as well will create more headaches
in other places (even if it doesn't make the grammar ambiguous, which
it well might). I think the bootstrap scanner would just be the tip of
the iceberg...

regards, tom lane

From bouncefilter Mon Feb 28 09:49: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 JAA15227
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 09:48: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 JAA25235;
Mon, 28 Feb 2000 09:48:29 -0500 (EST)
To: phd2@earthling.net
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Locale support broken in latest snapshots
In-reply-to: <Pine.LNX.4.21.0002280958080.24005-100000@fep132.fep.ru>
References: <Pine.LNX.4.21.0002280958080.24005-100000@fep132.fep.ru>
Comments: In-reply-to Oleg Broytmann <phd@phd.russ.ru>
message dated "Mon, 28 Feb 2000 10:03:10 +0000"
Date: Mon, 28 Feb 2000 09:48:28 -0500
Message-ID: <25232.951749308@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Oleg Broytmann <phd@phd.russ.ru> writes:

In the snapshot of 21 Feb locale support have been broken. "SELECT *
FROM table ORDER BY name" returns rows in wrong order; "SELECT * FROM table
WHERE name ~* re" performs case-sensitive match.

Ugh.

I remember Tatsuo once fixed case-sensitiveness by replacing char with
"unsigned char". Should I teach my gcc to always use unsigned chars?

No, that's not a solution (since it's not available to non-gcc users).
We need to find the coding error and fix it.

However, if you can try that as a test to see if it fixes the behavior,
please do; knowing whether it does will help narrow down what the bug
could be.

regards, tom lane

From bouncefilter Mon Feb 28 10:15: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 KAA18050
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 10:14: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 KAA25408;
Mon, 28 Feb 2000 10:14:07 -0500 (EST)
To: Jose Soares <jose@sferacarta.com>
cc: hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] having and union in v7beta
In-reply-to: <38BA829F.C8BA2978@sferacarta.com>
References: <38BA829F.C8BA2978@sferacarta.com>
Comments: In-reply-to Jose Soares <jose@sferacarta.com>
message dated "Mon, 28 Feb 2000 15:13:51 +0100"
Date: Mon, 28 Feb 2000 10:14:07 -0500
Message-ID: <25405.951750847@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Jose Soares <jose@sferacarta.com> writes:

SELECT...HAVING, this last for example doesn't work.

That's a rather strong statement, and in fact a provably false one.
How about a detailed bug report rather than "it doesn't work"?

SELECT ... UNION (is 3 / 4 times slow)

Can't help you on that without more details, either. What is the
query exactly, what plan does EXPLAIN show, and what plan did you
get from 6.5?

regards, tom lane

From bouncefilter Mon Feb 28 10:25:05 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 KAA19104
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 10:24: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 HAA02067
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 07:24:09 -0800 (PST)
Message-Id: <3.0.1.32.20000228071601.00fc90a0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 28 Feb 2000 07:16:01 -0800
To: pgsql-hackers@postgreSQL.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: bug in 7.0
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

This is probably related to Lockhart's changes to allow
not null/not deferrable to work (foreign key stuff). I'm
sympathetic, I looked at gram.y for awhile myself trying to
figure a way out of the problem and didn't find a good
solution.

Anyway:

donb=# create table bar(i integer unique not null);
ERROR: parser: parse error at or near "not"
donb=# create table bar(i integer not null unique);
ERROR: parser: parse error at or near "unique"
donb=# create table bar(i integer unique);
NOTICE: CREATE TABLE/UNIQUE will create implicit index 'bar_i_key' for
table 'bar'
CREATE
donb=#

Ouch. Fails on "primary key not null", etc too (though the
not null is redundant in this case).

The data model I'm porting from Oracle fails several hundred
times now because of this little problem...I guess my last
snapshot was just before Thomas' committed those changes,
otherwise I would've caught them before beta.

- 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 28 10:21: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 KAA18687
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 10:20: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 KAA25464;
Mon, 28 Feb 2000 10:20:29 -0500 (EST)
To: Don Baccus <dhogaza@pacifier.com>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
In-reply-to: <3.0.1.32.20000228062929.00fbd4c0@mail.pacifier.com>
References: <20132.951705014@sss.pgh.pa.us>
<3.0.1.32.20000227212630.00fbfb20@mail.pacifier.com>
<3.0.1.32.20000228062929.00fbd4c0@mail.pacifier.com>
Comments: In-reply-to Don Baccus <dhogaza@pacifier.com>
message dated "Mon, 28 Feb 2000 06:29:29 -0800"
Date: Mon, 28 Feb 2000 10:20:29 -0500
Message-ID: <25461.951751229@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Don Baccus <dhogaza@pacifier.com> writes:

"update t set id=id+1" is also a 2x space,

And PG doesn't do it correctly anyway...

? News to me. What's your definition of "correctly"?

regards, tom lane

From bouncefilter Mon Feb 28 10:17:06 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 KAA18281
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 10:16:48 -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 PAA09366;
Mon, 28 Feb 2000 15:26:48 GMT
Sender: lockhart@hub.org
Message-ID: <38BA93B8.7F4C0001@alumni.caltech.edu>
Date: Mon, 28 Feb 2000 15:26: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: Tom Lane <tgl@sss.pgh.pa.us>, Oleg Bartunov <oleg@sai.msu.su>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] 'now' in 7.0
References: <Pine.GSO.3.96.SK.1000223000757.1714H-100000@ra>
<26070.951258505@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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...
although here also I think now() or CURRENT_TIMESTAMP would be safer
coding.

Right. We stayed away from recommending anything to do with
"timestamp" in the past because it was such a brain-damaged
implementation.

Sorry for the porting effort; I could imagine someone working on a
"datetime compatibility package" which would define some of these
older functions. It would not need any compiled code, just a set of
CREATE FUNCTION definitions to hook up the new code with the old
names, something possible with Tom Lane's decoupling of entry points
from names...

If you are interested in doing this Oleg I'm sure we could slip it
into the beta tarball...

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Mon Feb 28 10:26:05 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 KAA19187
for <pgsql-hackers@postgresql.org>;
Mon, 28 Feb 2000 10:25:10 -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 QAA22283
for <pgsql-hackers@postgresql.org>;
Mon, 28 Feb 2000 16:25:04 +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 12PT1o-0000Ll-00; Mon, 28 Feb 2000 16:28:12 +0000
Message-ID: <38BA93FC.10029435@sferacarta.com>
Date: Mon, 28 Feb 2000 16:27:56 +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>
Subject: NOT NULL doesn't work in v7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Seems there is a problem with parser on NOT NULL...

CREATE TABLE distributors4 (
did DECIMAL(3) CONSTRAINT no_nullo NOT NULL,
name VARCHAR(40) NOT NULL
);

$ psql hygea1 -f not_null.ref
psql:not_null.ref:6: ERROR: parser: parse error at or near "not"

CREATE TABLE actors (
did DECIMAL(03) PRIMARY KEY not null,
name VARCHAR(40)
);
verde:~/ref/tmp$ psql hygea1 -f primary_key.ref
psql:primary_key.ref:4: ERROR: parser: parse error at or near "not"

--
Jose' Soares
Bologna, Italy Jose@sferacarta.com

From bouncefilter Mon Feb 28 10:43:05 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 KAA21115
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 10:42: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 HAA06662;
Mon, 28 Feb 2000 07:41:32 -0800 (PST)
Message-Id: <3.0.1.32.20000228073848.00fc90a0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 28 Feb 2000 07:38:48 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
Cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <25461.951751229@sss.pgh.pa.us>
References: <3.0.1.32.20000228062929.00fbd4c0@mail.pacifier.com>
<20132.951705014@sss.pgh.pa.us>
<3.0.1.32.20000227212630.00fbfb20@mail.pacifier.com>
<3.0.1.32.20000228062929.00fbd4c0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:20 AM 2/28/00 -0500, Tom Lane wrote:

Don Baccus <dhogaza@pacifier.com> writes:

"update t set id=id+1" is also a 2x space,

And PG doesn't do it correctly anyway...

? News to me. What's your definition of "correctly"?

create table foo(i integer unique);

(insert values)

donb=# select * from foo;
i
---
1
2
3
(3 rows)

donb=# update foo set i=i+1;
ERROR: Cannot insert a duplicate key into unique index foo_pkey

Shouldn't fail ... the constraint should be applied after the
update, but the row-by-row update of the index causes it to fail.
At least I presume that this is an artifact of PG implementing the
unique constraint by creating a unique index.

Stephan Szabo pointed this out to me awhile ago when we were
discussing "alter table add constraint" (he was looking into
this when he worked on "alter table add foreign key").

Of course, sometimes PG gets it right. I deleted stuff in foo,
then did:

donb=# insert into foo values(3);
INSERT 26907 1
donb=# insert into foo values(2);
INSERT 26908 1
donb=# insert into foo values(1);
INSERT 26909 1
donb=# update foo set i=i+1;
UPDATE 3
donb=#

- 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 28 10:41:04 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 KAA21020
for <pgsql-hackers@postgresql.org>;
Mon, 28 Feb 2000 10:40:15 -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 12PSHJ-0006oH-00; Mon, 28 Feb 2000 18:40:09 +0300
Date: Mon, 28 Feb 2000 15:40:09 +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: Re: [HACKERS] Locale support broken in latest snapshots
In-Reply-To: <25232.951749308@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0002281536390.26153-100000@fep132.fep.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Oleg Bartunov gave me the advice to rerun initdb -E KOI8...

And - oops - this helped. Locale test for koi8 locale passed.

It is strange - I did fresh and clean install into empty directory, and
of course I did initdb -E. Locale tests failed. But stopping postmaster,
removing data directory, running initdb -E and restarting postmaster
helped...

On Mon, 28 Feb 2000, Tom Lane wrote:

Oleg Broytmann <phd@phd.russ.ru> writes:

In the snapshot of 21 Feb locale support have been broken. "SELECT *
FROM table ORDER BY name" returns rows in wrong order; "SELECT * FROM table
WHERE name ~* re" performs case-sensitive match.

Ugh.

I remember Tatsuo once fixed case-sensitiveness by replacing char with
"unsigned char". Should I teach my gcc to always use unsigned chars?

No, that's not a solution (since it's not available to non-gcc users).
We need to find the coding error and fix it.

However, if you can try that as a test to see if it fixes the behavior,
please do; knowing whether it does will help narrow down what the bug
could be.

Oleg.
----
Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net
Programmers don't die, they just GOSUB without RETURN.

From bouncefilter Mon Feb 28 10:51:07 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 KAA21967
for <pgsql-hackers@postgresql.org>;
Mon, 28 Feb 2000 10:50:08 -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 QAA03854;
Mon, 28 Feb 2000 16:48:45 +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 12PTOj-0000Ph-00; Mon, 28 Feb 2000 16:51:53 +0000
Message-ID: <38BA998A.258E068C@sferacarta.com>
Date: Mon, 28 Feb 2000 16:51:38 +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>
Subject: Re: [HACKERS] having and union in v7beta
References: <38BA829F.C8BA2978@sferacarta.com> <25405.951750847@sss.pgh.pa.us>
Content-Type: multipart/mixed; boundary="------------CDC327C2452EB6869EBA1F46"

This is a multi-part message in MIME format.
--------------CDC327C2452EB6869EBA1F46
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Jose Soares <jose@sferacarta.com> writes:

SELECT...HAVING, this last for example doesn't work.

That's a rather strong statement, and in fact a provably false one.
How about a detailed bug report rather than "it doesn't work"?

SELECT ... UNION (is 3 / 4 times slow)

Can't help you on that without more details, either. What is the
query exactly, what plan does EXPLAIN show, and what plan did you
get from 6.5?

regards, tom lane

--
Jose' Soares
Bologna, Italy Jose@sferacarta.com

--------------CDC327C2452EB6869EBA1F46
Content-Type: text/plain; charset=us-ascii;
name="7"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="7"

psql7=# select count(*) from comuni;
count
-------
8342
(1 row)

psql7=> EXPLAIN select distretto from comuni union select codice_fiscale from comuni;
NOTICE: QUERY PLAN:

Unique (cost=1767.19..1808.90 rows=1668 width=12)
-> Sort (cost=1767.19..1767.19 rows=16684 width=12)
-> Append (cost=0.00..464.84 rows=16684 width=12)
-> Seq Scan on comuni (cost=0.00..232.42 rows=8342 width=12)
-> Seq Scan on comuni (cost=0.00..232.42 rows=8342 width=12)

EXPLAIN

psql65=> select count(*) from comuni;
count
-------
8342
(1 row)

psql65=> EXPLAIN select distretto from comuni union select codice_fiscale from comuni;
NOTICE: QUERY PLAN:

Unique (cost=848.57 rows=0 width=0)
-> Sort (cost=848.57 rows=0 width=0)
-> Append (cost=848.57 rows=0 width=0)
-> Seq Scan on comuni (cost=424.29 rows=8342 width=12)
-> Seq Scan on comuni (cost=424.29 rows=8342 width=12)
EXPLAIN

--------------CDC327C2452EB6869EBA1F46--

From bouncefilter Mon Feb 28 10:45:04 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 KAA21353
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 10:44: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 PAA09407;
Mon, 28 Feb 2000 15:52:03 GMT
Sender: lockhart@hub.org
Message-ID: <38BA99A3.5AF903B3@alumni.caltech.edu>
Date: Mon, 28 Feb 2000 15:52:03 +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: Don Baccus <dhogaza@pacifier.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] interesting observatation regarding views and V7.0
References: <3.0.1.32.20000223081725.010c5c90@mail.pacifier.com>
<5883.951346476@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Yes, this is exactly the concern I raised last week. Thomas didn't
seem to be very worried about the issue, but when he gets back from
his vacation we can lean on him to fix it.

OK Tom I'll try to sound more concerned next time :))

I'm using the rte->ref Attr structure to carry internal info on table
names and column names. What I should be able to do is decouple the
internal ref structure from the table name/column list specified by a
user, so the "query recreation" code can ignore the internal structure
and just use the original list from the user.

Should be able to go into v7.0 with no problem (other than initdb, but
it *is* a beta!!).

Something else we might consider as a stopgap is to resurrect the
"compressed text" datatype that Jan wrote, and then removed in
anticipation of having TOAST. Jan was concerned about creating
future compatibility problems by having a datatype with only a
one-release-cycle expected lifetime ... but I think it might be
OK to use it just internally for rules.

Naw, the above should be easier all around.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Mon Feb 28 11:12: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 LAA32277
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 11:11: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 LAA25605;
Mon, 28 Feb 2000 11:11:37 -0500 (EST)
To: Don Baccus <dhogaza@pacifier.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] bug in 7.0
In-reply-to: <3.0.1.32.20000228071601.00fc90a0@mail.pacifier.com>
References: <3.0.1.32.20000228071601.00fc90a0@mail.pacifier.com>
Comments: In-reply-to Don Baccus <dhogaza@pacifier.com>
message dated "Mon, 28 Feb 2000 07:16:01 -0800"
Date: Mon, 28 Feb 2000 11:11:36 -0500
Message-ID: <25601.951754296@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Don Baccus <dhogaza@pacifier.com> writes:

This is probably related to Lockhart's changes to allow
not null/not deferrable to work (foreign key stuff).

Yeah, we need a better answer for NOT DEFERRABLE. Thomas just did a
quick & dirty kluge to allow testing of foreign keys, but as you see
it's broken a number of other things...

I still like the idea of turning NOT NULL into a single token before
it gets to the grammar, but Thomas was dissatisfied with that plan.

regards, tom lane

From bouncefilter Mon Feb 28 11:13: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 LAA32965
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 11:12: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 LAA25635;
Mon, 28 Feb 2000 11:12:43 -0500 (EST)
To: Jose Soares <jose@sferacarta.com>
cc: hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] NOT NULL doesn't work in v7
In-reply-to: <38BA93FC.10029435@sferacarta.com>
References: <38BA93FC.10029435@sferacarta.com>
Comments: In-reply-to Jose Soares <jose@sferacarta.com>
message dated "Mon, 28 Feb 2000 16:27:56 +0100"
Date: Mon, 28 Feb 2000 11:12:43 -0500
Message-ID: <25632.951754363@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Jose Soares <jose@sferacarta.com> writes:

Seems there is a problem with parser on NOT NULL...

Yeah, known problem, will be fixed (somehow ;-)).

regards, tom lane

From bouncefilter Mon Feb 28 11:27: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 LAA34934
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 11:26: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 LAA25676;
Mon, 28 Feb 2000 11:26:35 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: missing function datetime()
In-reply-to: <38BAA1C2.65971352@alumni.caltech.edu>
References: <Pine.LNX.4.21.0002241604480.17558-100000@net-srv-0001.bvrd.com>
<23337.951436670@sss.pgh.pa.us>
<006e01bf7f81$b9a91d40$760e01a3@oucs.ox.ac.uk>
<7619.951496583@sss.pgh.pa.us>
<38BAA1C2.65971352@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Mon, 28 Feb 2000 16:26:42 +0000"
Date: Mon, 28 Feb 2000 11:26:35 -0500
Message-ID: <25673.951755195@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

I can see two ways to do that: either add another function to pg_proc
(five of them actually :-(), or hack the parser to translate a function
name 'datetime' to 'timestamp'. Ugly as the second one sounds, it has
a couple of advantages.

xlateSqlFunc() is already in gram.y; enjoy...

Will do, just wanted to see if you approved or not.

When you finish catching up on the back email, I'd like to know what
you think about the question of comment lexing. Should we change scan.l
so that it will recognize /* or -- as comment starters even if they are
embedded in what would currently be considered a long operator token?
If so, is it OK to depend on yyless() to do it, or is that a flex-ism?

I'd also kind of like to put in a test to detect unterminated comments
and literals. The flex manual recommends <<EOF>> but that only works
in flex. I was speculating that a rule for <xq> followed by nothing
might work, if all the other <xq> rules match at least one character.
Thoughts?

regards, tom lane

From bouncefilter Mon Feb 28 11:17:07 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 LAA33405
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 11:16:25 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA09506;
Mon, 28 Feb 2000 16:26:42 GMT
Sender: lockhart@hub.org
Message-ID: <38BAA1C2.65971352@alumni.caltech.edu>
Date: Mon, 28 Feb 2000 16:26: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: Tom Lane <tgl@sss.pgh.pa.us>
CC: Moray McConnachie <moray.mcconnachie@computing-services.oxford.ac.uk>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: missing function datetime()
References: <Pine.LNX.4.21.0002241604480.17558-100000@net-srv-0001.bvrd.com>
<23337.951436670@sss.pgh.pa.us>
<006e01bf7f81$b9a91d40$760e01a3@oucs.ox.ac.uk>
<7619.951496583@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I can see two ways to do that: either add another function to pg_proc
(five of them actually :-(), or hack the parser to translate a function
name 'datetime' to 'timestamp'. Ugly as the second one sounds, it has
a couple of advantages. First, it would provide an automatic upgrade
path: future dumps of 7.0 databases would show the correct function
name, at least for uses in rules. So we could hope to get rid of the
compatibility hack someday. Second, the parser has special treatment
for functions that are named the same as datatypes --- it knows they
represent type coercions --- so a function named "datetime" won't really
work quite the way it should for type resolution.

xlateSqlFunc() is already in gram.y; enjoy...

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Mon Feb 28 11:37: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 LAA36772
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 11:36: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 LAA25727;
Mon, 28 Feb 2000 11:36:26 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] interesting observatation regarding views and V7.0
In-reply-to: <38BA99A3.5AF903B3@alumni.caltech.edu>
References: <3.0.1.32.20000223081725.010c5c90@mail.pacifier.com>
<5883.951346476@sss.pgh.pa.us>
<38BA99A3.5AF903B3@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Mon, 28 Feb 2000 15:52:03 +0000"
Date: Mon, 28 Feb 2000 11:36:26 -0500
Message-ID: <25724.951755786@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

Something else we might consider as a stopgap is to resurrect the
"compressed text" datatype that Jan wrote, and then removed in
anticipation of having TOAST.

Naw, the above should be easier all around.

When you finish catching up on your mail, you'll find lztext is already
back in ;-). At this point, whether you change the representation is
pretty much irrelevant for rule size, I think. However, I am still
concerned by the hack I had to put into ruleutils.c to get pg_dump
to produce valid output for cases like
create view foo as select * from int8_tbl;
See the note and code at about line 1000 of utils/adt/ruleutils.c.
Ideally we want to be able to tell from the parsetree whether the user
wrote any column aliases or not (and if possible, distinguish the ones
he wrote from any that got added by the system). So that may force
a representation change anyway.

regards, tom lane

From bouncefilter Mon Feb 28 11:32:05 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 LAA35654;
Mon, 28 Feb 2000 11:31:10 -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 QAA09530;
Mon, 28 Feb 2000 16:38:26 GMT
Sender: lockhart@hub.org
Message-ID: <38BAA482.C84D9B11@alumni.caltech.edu>
Date: Mon, 28 Feb 2000 16:38: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: Peter Eisentraut <peter_e@gmx.net>
CC: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
webmaster@postgreSQL.org
Subject: Re: [HACKERS] Web page on bug reports
References: <200002280218.VAA14094@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Wow, that is long. I once thought of writing up something along similar
lines. Since you are apparently interested, I could but an abbreviated
and fitted to PostgreSQL edition in the user's guide.

Great. And we can point to the html version in the User's Guide from
the web page, to keep everything self-consistant. Much better than
having a special web version vs printed/online docs.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Mon Feb 28 11:40:08 2000
Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA37140
for <pgsql-general@postgreSQL.org>;
Mon, 28 Feb 2000 11:39:16 -0500 (EST)
(envelope-from keithmur@mindspring.com)
Received: from mindspring.com (pool-209-138-139-239-atln.grid.net
[209.138.139.239])
by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id LAA21068
for <pgsql-general@postgreSQL.org>;
Mon, 28 Feb 2000 11:39:11 -0500 (EST)
Message-ID: <38BAA5ED.8C0B130F@mindspring.com>
Date: Mon, 28 Feb 2000 10:44:29 -0600
From: "Keith G. Murphy" <keithmur@mindspring.com>
Reply-To: keithmur@mindspring.com
Organization: A small shoebox in the middle of the road
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] Re: [HACKERS] TRANSACTIONS
References:
<Pine.LNX.4.10.10002251726100.20593-100000@picasso.realtyideas.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

kaiq@realtyideas.com wrote:

On Fri, 25 Feb 2000, Karl DeBisschop wrote:

From: <kaiq@realtyideas.com>
On Fri, 25 Feb 2000, Karl DeBisschop wrote:

To summarize, I stated that the following does not work with
postgresql:

$dbh->{AutoCommit} = 0;
$dbh->do("CREATE TABLE tmp (a int unique,b int)");
$rtv = $dbh->do("INSERT INTO tmp VALUES ($1,$2)");
if ($rtv) {$dbh->do("UPDATE tmp SET b=$2 where a=$1")};
$dbh->commit;
$dbh->disconnect;

The usefulness of the idion is that in a mutli-user environment, this
is a basic way to update data that may or may not already have a key
in the table. You can't do a "SELECT COUNT" because in the time
between when you SELECT and INSERT (assuming the key is not already
there) someone may have done a separate insert. The only other way I
know to do this is to lock the entire table against INSERTs which has
obvious performance effects.

sounds right, but ;-) why you use the transaction in the first place?

Rememeber that this is just an example to illustrate what sort of
behaviour one user would find useful in tranasctions, so it is a
little simplistic. Not overly simplistic, though, I think.

I'd want a transaction because I'm doing a bulk insert into this live
database - say syncing in a bunch of data from a slave server while
the master is still running. If one (or more) insert(s) fail, I want
to revert back to the starting pint so I can fix the cause of the
failed insert and try again with the database in a known state.
(there may, for instance, be relationships beteewn the b field such
that if only part of the bulk insert suceeds, the database is rendered
corrupt).

thanks. I'm on your side now ;-) -- it is a useful senario.
the question are: 1) can nested transaction be typically interpreted
to handle this situation? If is is, then, it should be handled by that
"advanced feature", not plain transaction ;

I guess like this (got rid of AutoCommit, because that looks funny
nested):

$dbh->RaiseError = 1;
$dbh->StartTransaction;
eval {
$dbh->do("CREATE TABLE tmp (a int unique,b int)");
while (blahblahblah) {
$dbh->StartTransaction;
eval {
$dbh->do("INSERT INTO tmp VALUES ($1,$2)");
};
if ($@) {
$dbh->Rollback;
{$dbh->do("UPDATE tmp SET b=$2 where a=$1")};
} else {
$dbh->Commit;
}
}
}
if ($@) {
$dbh->rollback;
} else {
$dbh->commit;
}
$dbh->disconnect;

I.e., try the INSERT within the inner transaction; if it fails, roll it
back and do the UPDATE; if that fails, blow out the whole outer
transaction.

You could do the whole thing checking a return value as in the original
example, but the eval and RaiseError are canonical, according the the
docs.

2) on the other hand, can sql92's (plain) transaction be interpreted
in the way that above behavior is legitimate?

Well, I'm not sure of the necessity of nested transactions in the case
of continuing a transaction after a single-row insert has failed, but
that's implementation details I'm not familiar with... i.e., I'm not
having to code the danged thing!

From bouncefilter Tue Feb 29 13:19:26 2000
Received: from fandango.cs.unitn.it (root@fandango.cs.unitn.it
[193.205.199.228]) by hub.org (8.9.3/8.9.3) with ESMTP id NAA95317
for <hackers@postgreSQL.org>; Tue, 29 Feb 2000 13:18:23 -0500 (EST)
(envelope-from dz@cs.unitn.it)
Received: from nikita.dz.net (root@full234.sara.unitn.it [193.205.210.234])
by fandango.cs.unitn.it (8.9.3/8.9.3/Debian/GNU) with ESMTP id TAA20748
for <hackers@postgreSQL.org>; Tue, 29 Feb 2000 19:18:06 +0100
Received: (from dz@localhost)
by nikita.dz.net (8.9.3/8.9.3/Debian/GNU) id TAA32410
for hackers@postgreSQL.org; Tue, 29 Feb 2000 19:07:46 +0100
From: Massimo Dal Zotto <dz@cs.unitn.it>
Message-Id: <200002291807.TAA32410@nikita.dz.net>
Subject: Re: [HACKERS] Syslog and pg_options (for RPMs)
In-Reply-To: <00022802075300.02185@lorc.wgcr.org> from Lamar Owen at "Feb 28,
2000 01:36:58 am"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Mon, 28 Feb 2000 19:45:41 +0100 (MET)
X-UIDL: b14681451f7ecb0e09c80a21ccacf7f4
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: dz@cs.unitn.it

Well, I got pg_options and syslog (and ELOG timestamping) figured out --
however, there is a quirk:

With syslog set to 2 (supposedly suppressing ANY stderr/stdout, I still get
some output (I know that the documentation mentions this) )-- the output I am
getting is "reset_client_encoding()..
reset_client_encoding() done" immediately after a InitPostgres
log line. Incidentally, the two reset_client_encoding lines are not
timestamped, while the InitPostgres line IS.

It seems that there is some code which doesn't use elog() or TPRINTF() but
outputs directly to stderr instead. For example in postgres.c:

#ifdef MULTIBYTE
/* set default client encoding */
if (Verbose)
puts("\treset_client_encoding()..");
reset_client_encoding();
if (Verbose)
puts("\treset_client_encoding() done.");
#endif

In my opinion this is wrong. It should be:

TPRINTF(TRACE_VERBOSE, "reset_client_encoding().."");

or better:

TPRINTF(TRACE_MULTYBYTE, "reset_client_encoding().."");

A quick grep shows that the following files contain puts()

src/backend/access/common/printtup.c:
src/backend/bootstrap/bootparse.c:
src/backend/bootstrap/bootstrap.c:
src/backend/executor/execAmi.c:
src/backend/libpq/be-dumpdata.c:
src/backend/nodes/copyfuncs.c:
src/backend/parser/parse_expr.c:
src/backend/tcop/postgres.c:
src/backend/utils/adt/dt.c:
src/backend/utils/adt/ruleutils.c:
src/backend/utils/init/postinit.c:
src/backend/utils/misc/database.c:
src/backend/utils/sort/lselect.c:
src/bin/psql/psql.c:
src/interfaces/libpgtcl/pgtclId.c:

and many other files contain printf().

To get syslog functionality working (at least under RedHat Linux 6.1/Intel), do
the following:

Either edit src/include/config.h.in before configure, or edit
src/include/config.h after configure but before make (for RPM-building, I patch
config.h.in before running configure) -- uncomment both ELOG_TIMESTAMPS and
USE_SYSLOG.

You can also add the following line into Makefile.custom:

CUSTOM_COPT += -DUSE_SYSLOG -DELOG_TIMESTAMPS

In $PGDATA/pg_options, make verbose=1 or 2, and syslog >0 -- read the
pg_options page in the admin docs for more stuff you can put in pg_options.

To get information into the syslog, in /etc/syslog.conf place a line:
local0.* /var/log/postgresql
and /var/log/postgresql will get ALL those messages. NICE. Log rotation under
RedHat is a simple config file in /etc/logrotate.d......

These changes (including the syslog.conf one) will be in the next RPM
set to be released.

Massimo, what syslog levels are you using (I've perused
src/backend/misc/trace.c, but, unfortunately, my knowledge of syslog code is
weak)?

LOG_DEBUG, unless you enable the "all" trace flag, in which case LOG_INFO
is used.

Man, those regression tests really issue the queries (normally, my system will
do the non-parallel regression in about 2:15, but with syslog and query=4, it
takes 3:14).

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

************

--
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto               email: dz@cs.unitn.it               |
|  Via Marconi, 141                phone: ++39-0461534251              |
|  38057 Pergine Valsugana (TN)      www: http://www.cs.unitn.it/~dz/  |
|  Italy                             pgp: finger dz@tango.cs.unitn.it  |
+----------------------------------------------------------------------+

From bouncefilter Mon Feb 28 17:31:09 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 RAA75897
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 17:30:37 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12PYUs-0003kGC; Mon, 28 Feb 100 23:18 MET
Message-Id: <m12PYUs-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
In-Reply-To: <25601.951754296@sss.pgh.pa.us> from Tom Lane at "Feb 28,
2000 11:11:36 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 28 Feb 2000 23:18:34 +0100 (CET)
CC: Don Baccus <dhogaza@pacifier.com>, 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

Tom Lane wrote:

Don Baccus <dhogaza@pacifier.com> writes:

This is probably related to Lockhart's changes to allow
not null/not deferrable to work (foreign key stuff).

Yeah, we need a better answer for NOT DEFERRABLE. Thomas just did a
quick & dirty kluge to allow testing of foreign keys, but as you see
it's broken a number of other things...

I still like the idea of turning NOT NULL into a single token before
it gets to the grammar, but Thomas was dissatisfied with that plan.

I would be able to undo Thomas' changes to the parser (plus
your fix for SEQUENCE) and put our idea of token lookahead
into instead. The changes are locally to gram.y, and anything
works as expected.

It's a kludge too, mucking around with a

#define yylex() pg_yylex()

at the beginning, then later #undef'ining it again and
creating a function pg_yylex() that calls the real yylex().
Since we insist on bison and ship a gram.c for the others,
There can't be any portability problems.

I'd like to discuss this with Thomas on the phone before
committing, but IIRC he's off right now. So what do others
think?

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Mon Feb 28 17:41:09 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 RAA76556
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 17:40:39 -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 OAA21081;
Mon, 28 Feb 2000 14:39:44 -0800 (PST)
Message-Id: <3.0.1.32.20000228143702.00fd5850@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 28 Feb 2000 14:37:02 -0800
To: Jan Wieck <wieck@debis.com>, Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <m12PYUs-0003kGC@orion.SAPserv.Hamburg.dsh.de>
References: <25601.951754296@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 11:18 PM 2/28/00 +0100, Jan Wieck wrote:

I would be able to undo Thomas' changes to the parser (plus
your fix for SEQUENCE) and put our idea of token lookahead
into instead. The changes are locally to gram.y, and anything
works as expected.

Look-ahead's a bit cleaner in principle than doing it in the lexer,
IMO. Still, it shouldn't be necessary.

I was going to take a look at the relevant part of gram.y starting
in about an hour, over coffee, to see if anything leaps out at me.

Also, I think Thomas ought to have a chance to chime in and he's
apparently back in touch with the world, because he's been e-mailing
today.

- 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 28 18:17:10 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 SAA78818;
Mon, 28 Feb 2000 18:16:51 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61415 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S346122AbQB1XQI>;
Tue, 29 Feb 2000 00:16:08 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12PZRR-0001EZ-00; Tue, 29 Feb 2000 00:19:05 +0100
Date: Tue, 29 Feb 2000 00:19:05 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: George Dau <gedau@isa.mim.com.au>,
"'pgsql-sql@postgresql.org'" <pgsql-sql@postgresql.org>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [SQL] prob with aggregate and group by - returns multiples
In-Reply-To: <21290.951724201@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0002282202540.3511-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>

Tom Lane writes:

On a lesser note: I tried "select * into temp from hits" as per the doco,
but it barfs.

Postgres thinks that TEMP is a keyword, so it won't take it as a table
name unless you put quotes around it.

This is really an unfortunate case where someone should have read the SQL
standard before putting in a feature. The SQL keyword is TEMPORARY, and
TEMP is really a popular name for a dummy table.

I tried making TEMP a ColId but it croaks on this syntactic contruct:

SELECT xxx INTO [TEMP] [TABLE] tablename

which is incidentally not SQL either. If someone is interested in allowing
'temp' as an identifier, there doesn't seem to be a good way without
requiring the TABLE keyword above. Would that be worth it for 7.0 maybe?

Of course the documentation should be changed to TEMPORARY as well in
various places.

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Feb 28 18:17:10 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 SAA78824
for <pgsql-hackers@postgresql.org>;
Mon, 28 Feb 2000 18:17:07 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62257 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S352273AbQB1XQV>;
Tue, 29 Feb 2000 00:16:21 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12PZRi-0001FA-00; Tue, 29 Feb 2000 00:19:22 +0100
Date: Tue, 29 Feb 2000 00:19:22 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <25204.951749170@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0002290000170.3511-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>

Tom Lane writes:

I'm not sure that I agree that multi-word character types are required
internally. Somehow that seems to just push the problem of
SQL92-specific syntax to another part of the code.

It doesn't push it anywhere: you still have the problem that the parser
expects type names to be single tokens, not multiple tokens, and any
exceptions need to be special-cased in the grammar. We can handle that
for the few multi-word type names decreed by SQL92. But allowing
internal type names to be multi-word as well will create more headaches
in other places (even if it doesn't make the grammar ambiguous, which
it well might). I think the bootstrap scanner would just be the tip of
the iceberg...

I don't get that. What's wrong with (conceptually) having a rule like
this:

Type: TIME { $$ = "time"; }
| REAL { $$ = "real"; }
| CHAR { $$ = "char"; }
| BIT VARYING { $$ = "bit varying"; }
| Id { $$ = $1; } /* potentially user-defined type */

This is pretty much what it does now, only that the right side of $$ =
"..." never contains a space, which is purely coincidental.

The list of multi-token SQL types is very finite. Any user-defined
types with spaces would have to use the usual double-quote mechanism. The
advantage of the above is that once I have "bit varying" in the catalog, I
don't have to worry mangling it when I want to get it out.

I don't understand where you get the notion of "multiworded internal
types" from. All that would be required is concatenating a set of specific
token combinations to one and you're done. Once that is done, no one
worries about the fact that there is in fact a space in the type name.

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Feb 28 18:18:16 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 SAA78899
for <pgsql-hackers@postgresql.org>;
Mon, 28 Feb 2000 18:17:38 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64680 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S352284AbQB1XQx>;
Tue, 29 Feb 2000 00:16:53 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12PZSH-0001FE-00; Tue, 29 Feb 2000 00:19:57 +0100
Date: Tue, 29 Feb 2000 00:19:57 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE
In-Reply-To: <Pine.LNX.3.96.1000228130332.11685A-101000@ara.zf.jcu.cz>
Message-ID: <Pine.LNX.4.21.0002282246340.3511-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>

Karel Zak - Zakkr writes:

This patch add to current code NOCREATETABLE and NOLOCKTABLE feature:

CREATE USER username
[ WITH
[ SYSID uid ]
[ PASSWORD 'password' ] ]
[ CREATEDB | NOCREATEDB ] [ CREATEUSER | NOCREATEUSER ]
-> [ CREATETABLE | NOCREATETABLE ] [ LOCKTABLE | NOLOCKTABLE ]
...etc.

IMHO, the syntax for create user is a hell and a half. Adding more
keywords in the current fashion is a dead end. (Note: you have to remember
the order in which the user "features" have to be entered.)

I might as well propose that now, I'd like to see a syntax like

CREATE USER name (
password = 'xxx',
sysid = 99,
superuser = true,
...
);

That's much more flexible and extensible. The old syntax could coexist
with this too.

Regarding your two new features:

If you disallow table locking you might as well tell users not to use the
database. People need locks to operate a relational database. You will end
up disabling the entire transaction mechanism if you want this to work
properly. There already is a sufficient amount of checks for users not
claiming exlusive locks on tables they shouldn't.

Disallowing table creation might seem like a decent idea, but if at all,
it should go into the grant/revoke realm. Incidentally, this is quite at
odds with the SQL idea of how things should work, and I had hoped we could
get there some day.

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Feb 28 18:18:10 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 SAA78911
for <pgsql-hackers@postgresql.org>;
Mon, 28 Feb 2000 18:17:56 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61756 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S352260AbQB1XRI>;
Tue, 29 Feb 2000 00:17:08 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12PZSQ-0001FG-00; Tue, 29 Feb 2000 00:20:06 +0100
Date: Tue, 29 Feb 2000 00:20:05 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <pgman@candle.pha.pa.us>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <38BA3726.4AA47F7D@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.21.0002282300410.3511-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>

Thomas Lockhart writes:

I'm not sure that I agree that multi-word character types are required
internally. Somehow that seems to just push the problem of
SQL92-specific syntax to another part of the code. We could just as
easily (?) translate *every* "xxx VARYING" to "varxxx" on input, and
do the inverse on output or pg_dump.

On the one hand I propose what seems like editing a handful of lines in
the bootstrap scanner (an internal interface) to solve this problem once
and for all. What you are proposing is that every client interface (libpq,
SPI, PL du jour, who knows) will have to know a list of the latest hacks
of type conversions in the backend. And it would be very confusing to
people defining user types like "varxxx".

You can define user types with spaces in them (note to self: better check
this), so I don't see why we should hack around it. What do you plan on
doing with DOUBLE PRECISION and TIME WITH TIMEZONE?

Confused ...

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Feb 28 18:26: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 SAA79885
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 18:25: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 SAA26789;
Mon, 28 Feb 2000 18:25:11 -0500 (EST)
To: Jan Wieck <wieck@debis.com>
cc: Don Baccus <dhogaza@pacifier.com>, pgsql-hackers@postgreSQL.org
Subject: Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
In-reply-to: <m12PYUs-0003kGC@orion.SAPserv.Hamburg.dsh.de>
References: <m12PYUs-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Comments: In-reply-to wieck@debis.com (Jan Wieck)
message dated "Mon, 28 Feb 2000 23:18:34 +0100"
Date: Mon, 28 Feb 2000 18:25:10 -0500
Message-ID: <26786.951780310@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

wieck@debis.com (Jan Wieck) writes:

I would be able to undo Thomas' changes to the parser (plus
your fix for SEQUENCE) and put our idea of token lookahead
into instead. The changes are locally to gram.y, and anything
works as expected.

It's a kludge too, mucking around with a

#define yylex() pg_yylex()

at the beginning, then later #undef'ining it again and
creating a function pg_yylex() that calls the real yylex().
Since we insist on bison and ship a gram.c for the others,
There can't be any portability problems.

Um. We do *not* insist on bison, and at least one platform that
I work with would like to keep the option. Please hold off on this.

The other alternative that was discussed was to put the onus on
analyze.c to fix things up. Basically, we could make NOT DEFERRABLE
and the other subclauses of foreign key clauses be independent
clauses from the grammar's point of view; that is,

FOREIGN KEY blah blah NOT DEFERRABLE INITIALLY IMMEDIATE

would be parsed as three separate constraint clauses producing three
separate nodes in the column's constraint list. Then analyze.c would
make a pre-pass over the list to mark the FOREIGN KEY clause with the
right values and remove the extraneous clauses. (And to complain if
any of them are not in the right place, of course.)

This should get rid of the shift-reduce conflict, because there's
no longer any need to consider shifting in the context of

FOREIGN KEY blah blah . NOT

As far as the grammar is concerned, it can always reduce the FOREIGN
KEY clause at this point; the NOT will introduce a separate clause in
any case, so it doesn't matter whether NULL or DEFERRABLE follows it.

This would be a little bit more work, but it would introduce no
portability risk at all, and in theory it would let us produce better
error messages than the generic "parse error near" message, for at least
some kinds of mistakes.

I don't recall whether Thomas liked that idea either ;-), but I'm coming
around to the opinion that it's the best solution.

regards, tom lane

From bouncefilter Mon Feb 28 18:32:10 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 SAA80860
for <pgsql-hackers@postgresql.org>;
Mon, 28 Feb 2000 18:31:11 -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
SAA24391;
Mon, 28 Feb 2000 18:30:26 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002282330.SAA24391@candle.pha.pa.us>
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-Reply-To: <Pine.LNX.4.21.0002282300410.3511-100000@localhost.localdomain>
from Peter Eisentraut at "Feb 29, 2000 00:20:05 am"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Mon, 28 Feb 2000 18:30:26 -0500 (EST)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset ISO-8859-1 unsupported, filtering to ASCII...]

Thomas Lockhart writes:

I'm not sure that I agree that multi-word character types are required
internally. Somehow that seems to just push the problem of
SQL92-specific syntax to another part of the code. We could just as
easily (?) translate *every* "xxx VARYING" to "varxxx" on input, and
do the inverse on output or pg_dump.

On the one hand I propose what seems like editing a handful of lines in
the bootstrap scanner (an internal interface) to solve this problem once
and for all. What you are proposing is that every client interface (libpq,
SPI, PL du jour, who knows) will have to know a list of the latest hacks

libpq doesn't know anything about syntax. It is mostly gram.y files. I
think ecpg is the only other one that needs the fix.

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

From bouncefilter Mon Feb 28 18:56:10 2000
Received: from hu.tm.ee (ppp120.tele2.ee [212.107.33.120])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA87286
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 18:56:03 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 258233AEF; Tue, 29 Feb 2000 02:04:57 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38BB0D28.79B06301@tm.ee>
Date: Tue, 29 Feb 2000 02:04: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: Don Baccus <dhogaza@pacifier.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
References: <3.0.1.32.20000228062929.00fbd4c0@mail.pacifier.com>
<20132.951705014@sss.pgh.pa.us>
<3.0.1.32.20000227212630.00fbfb20@mail.pacifier.com>
<3.0.1.32.20000228062929.00fbd4c0@mail.pacifier.com>
<3.0.1.32.20000228073848.00fc90a0@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Don Baccus wrote:

At 10:20 AM 2/28/00 -0500, Tom Lane wrote:

Don Baccus <dhogaza@pacifier.com> writes:

"update t set id=id+1" is also a 2x space,

And PG doesn't do it correctly anyway...

? News to me. What's your definition of "correctly"?

create table foo(i integer unique);

(insert values)

donb=# select * from foo;
i
---
1
2
3
(3 rows)

donb=# update foo set i=i+1;
ERROR: Cannot insert a duplicate key into unique index foo_pkey

I knew it used to misbehave that way, but at some point I got the
impression that it was fixed ;(

IIRC, the same behaviour plagued the old foreign key implementation
in contrib, which was why it was refused for a long time to be
integrated.

I hope that at least the foreig keys don't do it anymore.

---------
Hannu

From bouncefilter Mon Feb 28 19:17: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 TAA89199
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 19:16: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 TAA27058;
Mon, 28 Feb 2000 19:16:15 -0500 (EST)
To: Jose Soares <jose@sferacarta.com>
cc: hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] having and union in v7beta
In-reply-to: <38BA998A.258E068C@sferacarta.com>
References: <38BA829F.C8BA2978@sferacarta.com> <25405.951750847@sss.pgh.pa.us>
<38BA998A.258E068C@sferacarta.com>
Comments: In-reply-to Jose Soares <jose@sferacarta.com>
message dated "Mon, 28 Feb 2000 16:51:38 +0100"
Date: Mon, 28 Feb 2000 19:16:15 -0500
Message-ID: <27055.951783375@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Jose Soares <jose@sferacarta.com> writes:

SELECT ... UNION (is 3 / 4 times slow)

Can't help you on that without more details, either. What is the
query exactly, what plan does EXPLAIN show, and what plan did you
get from 6.5?

psql7=> EXPLAIN select distretto from comuni union select codice_fiscale from comuni;
NOTICE: QUERY PLAN:

Unique (cost=1767.19..1808.90 rows=1668 width=12)

-> Sort (cost=1767.19..1767.19 rows=16684 width=12)
-> Append (cost=0.00..464.84 rows=16684 width=12)
-> Seq Scan on comuni (cost=0.00..232.42 rows=8342 width=12)
-> Seq Scan on comuni (cost=0.00..232.42 rows=8342 width=12)

[ and exactly the same plan for 6.5 ]

OK, so much for my first thought that the 7.0 planner was choosing a
bad plan.

One relevant change is that Unique nodes now invoke the proper
type-specific equality function(s) to decide whether tuples are distinct
or not, instead of doing a bitwise comparison (memcmp()) like they did
before. But it's tough to believe that that accounts for a 3-to-4x
slowdown of this query; certainly I don't see much performance
difference on the datatypes I tried. What datatypes are your fields,
anyway?

The other possibility is that the Sort step is a lot slower in 7.0,
although I don't think it should be. Are you running both versions
with the same -S setting, and if so what is it? Could it be that
the query is right on the edge of needing to switch from memory-based
to disk-based sort? Perhaps 7.0 is deciding that it needs to go to
disk a little sooner than 6.5 did.

regards, tom lane

From bouncefilter Mon Feb 28 19:40:10 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 TAA90269
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 19:39:53 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12PaWJ-0003kGC; Tue, 29 Feb 100 01:28 MET
Message-Id: <m12PaWJ-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
In-Reply-To: <26786.951780310@sss.pgh.pa.us> from Tom Lane at "Feb 28,
2000 06:25:10 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 29 Feb 2000 01:28:11 +0100 (CET)
CC: Jan Wieck <wieck@debis.com>, Don Baccus <dhogaza@pacifier.com>,
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

Tom Lane wrote:

wieck@debis.com (Jan Wieck) writes:

It's a kludge too, mucking around with a

#define yylex() pg_yylex()

at the beginning, then later #undef'ining it again and

Um. We do *not* insist on bison, and at least one platform that
I work with would like to keep the option. Please hold off on this.

Oh - O.K. - wrong assumption. Interesting if such a construct
works with other yacc implementations anyway.

The other alternative that was discussed was to put the onus on
analyze.c to fix things up. Basically, we could make NOT DEFERRABLE
and the other subclauses of foreign key clauses be independent
clauses from the grammar's point of view; that is,
[...]

Yepp, that was the third possible solution we talked about.
No doubt that it is the best one, and something we both wanna
see at the end. Only that I fear we cannot build it in time
for 7.0 schedule. Thus I assume we have to live 'now' with
either Thomas' kludge (as you called it), restricting order
of constraint clauses and introducing unpleasant "Why doesn't
my query ..." questions, or my crude hack. From the latter
one, I expect far less rumour because that's restricted to
ppl NOT using bison BUT touching gram.y.

At least this one will give us the option to delay the final
solution until 7.1 or until we shuffle up the entire
parser->rewriter->planner/optimizer->executor path. And that
without crippling the syntax from the users PoV.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Mon Feb 28 20:01:11 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 UAA91866
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 20:00:55 -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 RAA19627;
Mon, 28 Feb 2000 17:00:19 -0800 (PST)
Message-Id: <3.0.1.32.20000228163141.00ecb4f0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 28 Feb 2000 16:31:41 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, Jan Wieck <wieck@debis.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <26786.951780310@sss.pgh.pa.us>
References: <m12PYUs-0003kGC@orion.SAPserv.Hamburg.dsh.de>
<m12PYUs-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 06:25 PM 2/28/00 -0500, Tom Lane wrote:

The other alternative that was discussed was to put the onus on
analyze.c to fix things up. Basically, we could make NOT DEFERRABLE
and the other subclauses of foreign key clauses be independent
clauses from the grammar's point of view;

Which, of course, they are in the SQL92 grammar...

that is,

FOREIGN KEY blah blah NOT DEFERRABLE INITIALLY IMMEDIATE

would be parsed as three separate constraint clauses producing three
separate nodes in the column's constraint list. Then analyze.c would
make a pre-pass over the list to mark the FOREIGN KEY clause with the
right values and remove the extraneous clauses. (And to complain if
any of them are not in the right place, of course.)

I just got back from my little coffee break spent reading the relevant bit
of gram.y, and after looking at the gyrations Thomas went through in his
patch I'm even more convinced that doing it "right" is not only right,
but in the long run simpler.

I think gram.y can be patched up to fix some of the more obvious
missing cases but it will make it even messier than it is now. And
it's already extremely messy.

Again, I'm sympathetic to Thomas because I tried to find a quick and
dirty work-around to Jan's original shift-reduce conflict several
weeks ago, without success. Thomas' change isn't quick and dirty,
but rather complicated and messy and incomplete, but short of doing
it "right" (i.e. as Tom explains above) there's no other way I can
see.

Other than stepping outside the parser, so to speak, to do token
lookahead or to do a lexer kludge. But these kludges only fix
Jan's original problem - and Jan's original grammar isn't SQL92
compliant...

I don't recall whether Thomas liked that idea either ;-), but I'm coming
around to the opinion that it's the best solution.

Well, the current effort tries to avoid the general case by listing
a bunch of possible combinations, which really doesn't feel 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 28 20:01:11 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 UAA91858
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 20:00:36 -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 RAA19640;
Mon, 28 Feb 2000 17:00:21 -0800 (PST)
Message-Id: <3.0.1.32.20000228163607.00ecb4f0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 28 Feb 2000 16:36:07 -0800
To: Hannu Krosing <hannu@tm.ee>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <38BB0D28.79B06301@tm.ee>
References: <3.0.1.32.20000228062929.00fbd4c0@mail.pacifier.com>
<20132.951705014@sss.pgh.pa.us>
<3.0.1.32.20000227212630.00fbfb20@mail.pacifier.com>
<3.0.1.32.20000228062929.00fbd4c0@mail.pacifier.com>
<3.0.1.32.20000228073848.00fc90a0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 02:04 AM 2/29/00 +0200, Hannu Krosing wrote:

IIRC, the same behaviour plagued the old foreign key implementation
in contrib, which was why it was refused for a long time to be
integrated.

I hope that at least the foreig keys don't do it anymore.

It shouldn't because they're implemented via triggers after all the
work is done. In other words, the implementation might have bugs
but the bugs should be different :)

- 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 28 19:55:11 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 TAA91411
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 19:54:59 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12Pakv-0003kGC; Tue, 29 Feb 100 01:43 MET
Message-Id: <m12Pakv-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
In-Reply-To: <38BB0D28.79B06301@tm.ee> from Hannu Krosing at "Feb 29,
2000 02:04:56 am"
To: Hannu Krosing <hannu@tm.ee>
Date: Tue, 29 Feb 2000 01:43:17 +0100 (CET)
CC: Don Baccus <dhogaza@pacifier.com>, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <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

Hannu Krosing wrote:

Don Baccus wrote:

donb=# update foo set i=i+1;
ERROR: Cannot insert a duplicate key into unique index foo_pkey

IIRC, the same behaviour plagued the old foreign key implementation
in contrib, which was why it was refused for a long time to be
integrated.

I hope that at least the foreig keys don't do it anymore.

ALL the FK triggers are delayed until after the entire
statement (what's wrong for ON DELETE RESTRICT - but that's
another story), or until the entire transaction (in deferred
mode).

But the UNIQUE constraint is still built upon unique nbtree
indices, thus failing on primary key where such a unique
index is automatically created for.

I'm far too less familiar with our implementation of nbtree
to tell whether it would be possible at all to delay unique
checking until statement end or XACT commit. At least I
assume it would require some similar technique of deferred
queue.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Mon Feb 28 19:46: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 TAA90528
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 19:45: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 TAA27284;
Mon, 28 Feb 2000 19:45:02 -0500 (EST)
To: Jan Wieck <wieck@debis.com>
cc: Don Baccus <dhogaza@pacifier.com>, pgsql-hackers@postgreSQL.org
Subject: Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
In-reply-to: <m12PaWJ-0003kGC@orion.SAPserv.Hamburg.dsh.de>
References: <m12PaWJ-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Comments: In-reply-to wieck@debis.com (Jan Wieck)
message dated "Tue, 29 Feb 2000 01:28:11 +0100"
Date: Mon, 28 Feb 2000 19:45:02 -0500
Message-ID: <27281.951785102@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

wieck@debis.com (Jan Wieck) writes:

Tom Lane wrote:

The other alternative that was discussed was to put the onus on
analyze.c to fix things up. Basically, we could make NOT DEFERRABLE
and the other subclauses of foreign key clauses be independent
clauses from the grammar's point of view; that is,

Yepp, that was the third possible solution we talked about.
No doubt that it is the best one, and something we both wanna
see at the end. Only that I fear we cannot build it in time
for 7.0 schedule.

Why not? It's not *that* much work --- looked like maybe an
evening's project to me. If no one else wants to do it, I will.

regards, tom lane

From bouncefilter Mon Feb 28 20:07:11 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 UAA92459
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 20:06:49 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12PawP-0003kGC; Tue, 29 Feb 100 01:55 MET
Message-Id: <m12PawP-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
In-Reply-To: <27281.951785102@sss.pgh.pa.us> from Tom Lane at "Feb 28,
2000 07:45:02 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 29 Feb 2000 01:55:09 +0100 (CET)
CC: Jan Wieck <wieck@debis.com>, Don Baccus <dhogaza@pacifier.com>,
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

Tom Lane wrote:

wieck@debis.com (Jan Wieck) writes:

Tom Lane wrote:

The other alternative that was discussed was to put the onus on
analyze.c to fix things up. Basically, we could make NOT DEFERRABLE
and the other subclauses of foreign key clauses be independent
clauses from the grammar's point of view; that is,

Yepp, that was the third possible solution we talked about.
No doubt that it is the best one, and something we both wanna
see at the end. Only that I fear we cannot build it in time
for 7.0 schedule.

Why not? It's not *that* much work --- looked like maybe an
evening's project to me. If no one else wants to do it, I will.

Your turn.

Thomas made his, IMHO already complained because crippling
the user interface in a not stdconforming way. My one is a
bad hack and therefore deprecated by definition.

Let's look at all three possible implementations for 7.0 and
judge after.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Mon Feb 28 20:45:12 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 UAA97040
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 20:44:38 -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 RAA06808;
Mon, 28 Feb 2000 17:44:21 -0800 (PST)
Message-Id: <3.0.1.32.20000228172050.00ece600@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 28 Feb 2000 17:20:50 -0800
To: Jan Wieck <wieck@debis.com>, Hannu Krosing <hannu@tm.ee>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <m12Pakv-0003kGC@orion.SAPserv.Hamburg.dsh.de>
References: <38BB0D28.79B06301@tm.ee>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 01:43 AM 2/29/00 +0100, Jan Wieck wrote:

ALL the FK triggers are delayed until after the entire
statement (what's wrong for ON DELETE RESTRICT - but that's
another story), or until the entire transaction (in deferred
mode).

Kind of wrong, just so folks understand the semantics are right in
the sense that the right answer is given (pass or fail) - you need
a stopwatch to know that we're not doing what the SQL3 suggests
should be done (catch the foreign key errors before changes are made
and without incurring the cost of a rollback).

The current way we're doing it - identically to "NO ACTION" is
fine for compatability purposes, though later we'd like to implement
a smart ON DELETE RESTRICT because the efficiency considerations
that led to its inclusion in SQL3 are reasonable ones.

I'm far too less familiar with our implementation of nbtree
to tell whether it would be possible at all to delay unique
checking until statement end or XACT commit. At least I
assume it would require some similar technique of deferred
queue.

Presumably you'd queue up per-row triggers just like for FK constraints
and insert into the unique index at that point.

I have no idea how many other things this would break, if any.

- 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 28 20:59: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 UAA97893
for <pgsql-hackers@postgresql.org>;
Mon, 28 Feb 2000 20:59:03 -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 UAA15242;
Mon, 28 Feb 2000 20:57:02 -0500
Message-Id: <200002290157.UAA15242@homeworld.bigpanda.org>
To: Jan Wieck <wieck@debis.com>
CC: pgsql-hackers@postgresql.org
From: sszabo@bigpanda.com
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
In-Reply-To: Your message of "Tue, 29 Feb 2000 01:43:17 +0100."
<m12Pakv-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Date: Mon, 28 Feb 2000 20:57:01 -0500
Sender: acroyear@bigpanda.com

ALL the FK triggers are delayed until after the entire
statement (what's wrong for ON DELETE RESTRICT - but that's
another story), or until the entire transaction (in deferred
mode).

But the UNIQUE constraint is still built upon unique nbtree
indices, thus failing on primary key where such a unique
index is automatically created for.

I'm far too less familiar with our implementation of nbtree
to tell whether it would be possible at all to delay unique
checking until statement end or XACT commit. At least I
assume it would require some similar technique of deferred
queue.

We might want to look at what we're doing for all of the constraints,
because at some point we'll probably want to let you defer the other
constraints as well (I'm pretty sure this technically legal in SQL92).
If we can think of a good way to handle all of the constraints together
that might be worth doing to prevent us from coding the same thing
multiple times.

From bouncefilter Mon Feb 28 21:01:12 2000
Received: from excelsior.rkirkpat.net
(14.houston-23-24rs.tx.dial-access.att.net [12.73.233.14])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA98047
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 21:00:31 -0500 (EST)
(envelope-from rkirkpat@rkirkpat.net)
Received: from localhost (rkirkpat@localhost)
by excelsior.rkirkpat.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id
UAA12211; Mon, 28 Feb 2000 20:00:20 -0600
Date: Mon, 28 Feb 2000 20:00:20 -0600 (CST)
From: Ryan Kirkpatrick <pgsql@rkirkpat.net>
X-Sender: rkirkpat@excelsior.rkirkpat.net
To: Lamar Owen <lamar.owen@wgcr.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] 7.0beta1-0.2 testing RPMS are now available.
In-Reply-To: <38B2B44F.A0078699@wgcr.org>
Message-ID: <Pine.LNX.4.10.10002281956000.28996-100000@excelsior.rkirkpat.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Sorry about the delayed response, been busy.... :(

On Tue, 22 Feb 2000, Lamar Owen wrote:

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?

Arrg... Guess that means me? :) I will try and find the time to
download the 7.0 beta tarball and give it a spin on my Alpha by the end of
the week.
I have no clue on what patches are going to be needed, given that
I have yet to even see what parts of the system they touched, let alone
how much those parts have changed since 6.5.x. This will probably prove
interesting. I will let you (and the list know) as soon as I have some
results. TTYL.

---------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
---------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---------------------------------------------------------------------------

From bouncefilter Mon Feb 28 21:37:12 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 VAA00454
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 21:36:21 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12PcL5-0003kGC; Tue, 29 Feb 100 03:24 MET
Message-Id: <m12PcL5-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
In-Reply-To: <3.0.1.32.20000228172050.00ece600@mail.pacifier.com> from Don
Baccus at "Feb 28, 2000 05:20:50 pm"
To: Don Baccus <dhogaza@pacifier.com>
Date: Tue, 29 Feb 2000 03:24:43 +0100 (CET)
CC: Jan Wieck <wieck@debis.com>, Hannu Krosing <hannu@tm.ee>,
Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <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

Don Baccus wrote:

At 01:43 AM 2/29/00 +0100, Jan Wieck wrote:

ALL the FK triggers are delayed until after the entire
statement (what's wrong for ON DELETE RESTRICT - but that's
another story), or until the entire transaction (in deferred
mode).

Kind of wrong, just so folks understand the semantics are right in
the sense that the right answer is given (pass or fail) - you need
a stopwatch to know ...

Explanative version of "that other story". But not exactly
correct IMHO. If following strictly SQL3 suggestions, an ON
DELETE RESTRICT action cannot be deferrable at all. Even if
the constraint itself is deferrable and is set explicitly to
DEFERRED, the check should be done immediately at ROW level.
That's the difference between "NO ACTION" and "RESTRICT".

Actually, a RESTRICT violation can potentially bypass
thousands of subsequent queries until COMMIT. Meaningless
from the transactional PoV, but from the application
programmers one (looking at the return code of a particular
statement) it isn't!

I'm far too less familiar with our implementation of nbtree
to tell whether it would be possible at all to delay unique
checking until statement end or XACT commit. At least I
assume it would require some similar technique of deferred
queue.

Presumably you'd queue up per-row triggers just like for FK constraints
and insert into the unique index at that point.

I have no idea how many other things this would break, if any.

At least if deferring the index insert until XACT commit, any
subsequent index scan wouldn't see inserted tuples, even if
they MUST be visible.

Maybe I'm less far away from knowledge than thought. Inside
of a nbtree-index, any number of duplicates is accepted.
It's the heap tuples visibility they point to, that triggers
the dup message.

So it's definitely some kind of "accept duplicates for now
but check for final dup's on this key later".

But that requires another index scan later. We can remember
the relations and indices Oid (to get back the relation and
index in question) plus the CTID of the added
(inserted/updated tuple) to get back the key values
(remembering the key itself could blow up memory). Then do an
index scan under current (statement end/XACT commit)
visibility to check if more than one HeapTupleSatisfies().

It'll be expensive, compared to current UNIQUE implementation
doing it on the fly during btree insert (doesn't it?). But
the only way I see.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Mon Feb 28 22:01: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 WAA01826
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 22:00:38 -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 SAA05648;
Mon, 28 Feb 2000 18:59:54 -0800 (PST)
Message-Id: <3.0.1.32.20000228185614.00ed25d0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 28 Feb 2000 18:56:14 -0800
To: Jan Wieck <wieck@debis.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
Cc: Jan Wieck <wieck@debis.com>, Hannu Krosing <hannu@tm.ee>,
Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <m12PcL5-0003kGC@orion.SAPserv.Hamburg.dsh.de>
References: <3.0.1.32.20000228172050.00ece600@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 03:24 AM 2/29/00 +0100, Jan Wieck wrote:

Explanative version of "that other story". But not exactly
correct IMHO. If following strictly SQL3 suggestions, an ON
DELETE RESTRICT action cannot be deferrable at all. Even if
the constraint itself is deferrable and is set explicitly to
DEFERRED, the check should be done immediately at ROW level.
That's the difference between "NO ACTION" and "RESTRICT".

Actually, a RESTRICT violation can potentially bypass
thousands of subsequent queries until COMMIT. Meaningless
from the transactional PoV, but from the application
programmers one (looking at the return code of a particular
statement) it isn't!

No, strictly speaking it isn't correct. But without a stopwatch,
it will be hard to tell.

Actually, though, since exceptions are only supposed to reject
the given SQL-statement and not trigger a PG-style auto-rollback of
the transaction, a subsequent "commit" should commit that subsequent
work (unless they in turn trigger constraint errors due to dependencies
on the first failed constraint).

So you don't really get to skip all those subsequent statements unless
you're looking for the exception, catch it, and do an explicit rollback.

None of that is in place in PG anyway at the moment...

I'm assuming that the exception raised for an FK violation is the
same as an exception raised for numeric overflow, etc - I think
you missed that earlier discussion.

The fact that PG's auto-rollback is wrong was news to me, though
obvious in hindsight, and I've not gone back to study RI semantics
in light of this new information.

So I may be wrong, here.

We could always take out "RESTRICT" and claim SQL92 rather than SQL3
referential integrity :) :)

Given that Oracle only implements "MATCH <unspecified>" (as of 8.1.5,
anyway), we're not doing too bad!

I'm far too less familiar with our implementation of nbtree
to tell whether it would be possible at all to delay unique
checking until statement end or XACT commit. At least I
assume it would require some similar technique of deferred
queue.

Presumably you'd queue up per-row triggers just like for FK constraints
and insert into the unique index at that point.

I have no idea how many other things this would break, if any.

At least if deferring the index insert until XACT commit, any
subsequent index scan wouldn't see inserted tuples, even if
they MUST be visible.

Ugh, of course :(

Maybe I'm less far away from knowledge than thought. Inside
of a nbtree-index, any number of duplicates is accepted.
It's the heap tuples visibility they point to, that triggers
the dup message.

So it's definitely some kind of "accept duplicates for now
but check for final dup's on this key later".

But that requires another index scan later. We can remember
the relations and indices Oid (to get back the relation and
index in question) plus the CTID of the added
(inserted/updated tuple) to get back the key values
(remembering the key itself could blow up memory). Then do an
index scan under current (statement end/XACT commit)
visibility to check if more than one HeapTupleSatisfies().

It'll be expensive, compared to current UNIQUE implementation
doing it on the fly during btree insert (doesn't it?). But
the only way I see.

The more I learn about SQL92 the more I understand why RDBMS systems
have the reputation for being piggy. But, the standard semantics
of UPDATE on a column with a UNIQUE constraint are certainly consistent
with the paradigm that queries operate on sets of tuples, not sequences
of tuples.

- 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 29 00:00:13 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 XAA09006
for <pgsql-hackers@postgreSQL.org>;
Mon, 28 Feb 2000 23:59:56 -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 NAA04247; Tue, 29 Feb 2000 13:58:41 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Karel Zak - Zakkr" <zakkr@zf.jcu.cz>,
"Peter Eisentraut" <peter_e@gmx.net>
Cc: "Jan Wieck" <wieck@debis.com>, "Tom Lane" <tgl@sss.pgh.pa.us>,
"pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Cache query implemented
Date: Tue, 29 Feb 2000 14:05:02 +0900
Message-ID: <000c01bf8272$89199120$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <Pine.LNX.3.96.1000228144441.19731B-100000@ara.zf.jcu.cz>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

-----Original Message-----
From: Karel Zak - Zakkr [mailto:zakkr@zf.jcu.cz]

EXECUTE name [ INTO x, y, ... ] [ USING a, b, ... ]

This command "Associate input parametrs and output targets

with a prepared

statement and execute the statement" (SQL92).

I don't know well about PREPARE statement.
But is above syntax for interative SQL command ?
Isn't it for embedded SQL or SQL module ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Tue Feb 29 00:09:15 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 AAA09894
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 00:08:36 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id OAA04252; Tue, 29 Feb 2000 14:07:29 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "The Hermit Hacker" <scrappy@hub.org>
Cc: "Bruce Momjian" <pgman@candle.pha.pa.us>, "Tom Lane" <tgl@sss.pgh.pa.us>,
"PostgreSQL Development" <pgsql-hackers@postgresql.org>
Subject: RE: [HACKERS] Re: ALTER TABLE DROP COLUMN
Date: Tue, 29 Feb 2000 14:13:50 +0900
Message-ID: <000d01bf8273$c3e86320$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <Pine.BSF.4.21.0002280912170.81087-100000@thelab.hub.org>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

-----Original Message-----
From: The Hermit Hacker [mailto:scrappy@hub.org]

[snip]

Hiroshi ...

Bruce's comment was just an observation ... if it can be done
cleanly, I would love to see a version that didn't involve 2x the disk
space ... I don't believe that a trial would be useless, I think that
Bruce's only concern/warning is that the amount of code modifications that
would have to be made in order to accomplish this *might* be larger then
the benefit resulting in doing it this way.

If you feel that this can be done more efficiently, *please*
proceed with the trial ...

OK,I may be able to provide a trial patch in a week or so if I'm lucky.
How to commit the patch ?
With #ifdef ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Tue Feb 29 00:41: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 AAA13742
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 00:40: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 AAA27881;
Tue, 29 Feb 2000 00:40:19 -0500 (EST)
To: Jan Wieck <wieck@debis.com>
cc: Don Baccus <dhogaza@pacifier.com>, Hannu Krosing <hannu@tm.ee>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
In-reply-to: <m12PcL5-0003kGC@orion.SAPserv.Hamburg.dsh.de>
References: <m12PcL5-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Comments: In-reply-to wieck@debis.com (Jan Wieck)
message dated "Tue, 29 Feb 2000 03:24:43 +0100"
Date: Tue, 29 Feb 2000 00:40:19 -0500
Message-ID: <27878.951802819@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

wieck@debis.com (Jan Wieck) writes:

So it's definitely some kind of "accept duplicates for now
but check for final dup's on this key later".

But that requires another index scan later. We can remember
the relations and indices Oid (to get back the relation and
index in question) plus the CTID of the added
(inserted/updated tuple) to get back the key values
(remembering the key itself could blow up memory). Then do an
index scan under current (statement end/XACT commit)
visibility to check if more than one HeapTupleSatisfies().

It'll be expensive, compared to current UNIQUE implementation
doing it on the fly during btree insert (doesn't it?). But
the only way I see.

How about:

1. During INSERT into unique index, notice whether any other index
entries have same key. If so, add that key value to a queue of
possibly-duplicate keys to check later.

2. At commit, or whenever consistency should be checked, scan the
queue. For each entry, use the index to look up all the matching
tuples, and check that only one will be valid if the transaction
commits.

This avoids a full index scan in the normal case, although it could
be pretty slow in the update-every-tuple scenario...

regards, tom lane

From bouncefilter Tue Feb 29 00:45: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 AAA14386;
Tue, 29 Feb 2000 00:44:32 -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 AAA27960;
Tue, 29 Feb 2000 00:44:22 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: "'pgsql-sql@postgresql.org'" <pgsql-sql@postgresql.org>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [SQL] prob with aggregate and group by - returns
multiples
In-reply-to: <38BB5D9C.ED50B126@alumni.caltech.edu>
References: <Pine.LNX.4.21.0002282202540.3511-100000@localhost.localdomain>
<38BB5D9C.ED50B126@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Tue, 29 Feb 2000 05:48:12 +0000"
Date: Tue, 29 Feb 2000 00:44:22 -0500
Message-ID: <27957.951803062@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

This is really an unfortunate case where someone should have read the SQL
standard before putting in a feature. The SQL keyword is TEMPORARY, and
TEMP is really a popular name for a dummy table.

So why not yank TEMP and require TEMPORARY?

Probably we ought to stop to ask why TEMP is in there to begin with;
perhaps for compatibility with some other RDBMS?

If not, I'd vote for pulling it out. That's a heck of a poor word to
reserve.

regards, tom lane

From bouncefilter Tue Feb 29 00:38:14 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 AAA13063;
Tue, 29 Feb 2000 00:38:10 -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 FAA10658;
Tue, 29 Feb 2000 05:48:12 GMT
Sender: lockhart@hub.org
Message-ID: <38BB5D9C.ED50B126@alumni.caltech.edu>
Date: Tue, 29 Feb 2000 05:48:12 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: Tom Lane <tgl@sss.pgh.pa.us>, George Dau <gedau@isa.mim.com.au>,
"'pgsql-sql@postgresql.org'" <pgsql-sql@postgresql.org>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [SQL] prob with aggregate and group by - returns
multiples
References: <Pine.LNX.4.21.0002282202540.3511-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Postgres thinks that TEMP is a keyword, so it won't take it as a table
name unless you put quotes around it.

This is really an unfortunate case where someone should have read the SQL
standard before putting in a feature. The SQL keyword is TEMPORARY, and
TEMP is really a popular name for a dummy table.

So why not yank TEMP and require TEMPORARY? Saving an extra 5
characters of typing is not a good enough reason to keep it imho, and
if the SQL92 standard requires a particular form why bother extending
it?

A major release is a good time to adjust syntax to promote
compliance...

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Tue Feb 29 00:45:14 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 AAA14366
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 00:44:17 -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 FAA10665;
Tue, 29 Feb 2000 05:54:56 GMT
Sender: lockhart@hub.org
Message-ID: <38BB5F30.F106C512@alumni.caltech.edu>
Date: Tue, 29 Feb 2000 05:54: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: Jan Wieck <wieck@debis.com>
CC: Tom Lane <tgl@sss.pgh.pa.us>, Don Baccus <dhogaza@pacifier.com>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
References: <m12PawP-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thomas made his, IMHO already complained because crippling
the user interface in a not stdconforming way. My one is a
bad hack and therefore deprecated by definition.

I did not claim to have the final form; I ran out of time before
heading out on vacation. istm that solving the general case by
unrolling clauses should not be exhaustively difficult. I will
continue to pursue this as time permits.

Let's look at all three possible implementations for 7.0 and
judge after.

Sounds good.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Tue Feb 29 01:00: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 AAA18775;
Tue, 29 Feb 2000 00:59: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
AAA10605;
Tue, 29 Feb 2000 00:59:12 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002290559.AAA10605@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [SQL] prob with aggregate and group by - returns
multiplesh
In-Reply-To: <27957.951803062@sss.pgh.pa.us> from Tom Lane at "Feb 29,
2000 00:44:22 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 29 Feb 2000 00:59:12 -0500 (EST)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
"'pgsql-sql@postgresql.org'" <pgsql-sql@postgreSQL.org>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

This is really an unfortunate case where someone should have read the SQL
standard before putting in a feature. The SQL keyword is TEMPORARY, and
TEMP is really a popular name for a dummy table.

So why not yank TEMP and require TEMPORARY?

Probably we ought to stop to ask why TEMP is in there to begin with;
perhaps for compatibility with some other RDBMS?

It was me. Informix uses it.

If not, I'd vote for pulling it out. That's a heck of a poor word to
reserve.

I am afraid of lots of user complaints, even if we had not already used
TEMP.

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

From bouncefilter Tue Feb 29 01:34:14 2000
Received: from thelab.hub.org (nat196.115.mpoweredpc.net [142.177.196.115])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA25560
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 01:33:54 -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 CAA67141;
Tue, 29 Feb 2000 02:32:15 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 29 Feb 2000 02:32:15 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Hiroshi Inoue <Inoue@tpf.co.jp>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Re: ALTER TABLE DROP COLUMN
In-Reply-To: <000d01bf8273$c3e86320$2801007e@tpf.co.jp>
Message-ID: <Pine.BSF.4.21.0002290231410.434-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 29 Feb 2000, Hiroshi Inoue wrote:

-----Original Message-----
From: The Hermit Hacker [mailto:scrappy@hub.org]

[snip]

Hiroshi ...

Bruce's comment was just an observation ... if it can be done
cleanly, I would love to see a version that didn't involve 2x the disk
space ... I don't believe that a trial would be useless, I think that
Bruce's only concern/warning is that the amount of code modifications that
would have to be made in order to accomplish this *might* be larger then
the benefit resulting in doing it this way.

If you feel that this can be done more efficiently, *please*
proceed with the trial ...

OK,I may be able to provide a trial patch in a week or so if I'm lucky.
How to commit the patch ?
With #ifdef ?

Nope, but it will have to wait until *after* 7.0 is released, so don't
push yourself on it ...

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 29 01:36:15 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 BAA25708
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 01:35:20 -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 GAA11074;
Tue, 29 Feb 2000 06:43:03 GMT
Sender: lockhart@hub.org
Message-ID: <38BB6A77.53DEDA9D@alumni.caltech.edu>
Date: Tue, 29 Feb 2000 06:43:03 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] interesting observatation regarding views and V7.0
References: <3.0.1.32.20000223081725.010c5c90@mail.pacifier.com>
<5883.951346476@sss.pgh.pa.us>
<38BA99A3.5AF903B3@alumni.caltech.edu>
<25724.951755786@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

When you finish catching up on your mail, you'll find lztext is already
back in ;-). At this point, whether you change the representation is
pretty much irrelevant for rule size, I think. However, I am still
concerned by the hack I had to put into ruleutils.c to get pg_dump
to produce valid output for cases like
create view foo as select * from int8_tbl;
See the note and code at about line 1000 of utils/adt/ruleutils.c.
Ideally we want to be able to tell from the parsetree whether the user
wrote any column aliases or not (and if possible, distinguish the ones
he wrote from any that got added by the system). So that may force
a representation change anyway.

Well, if I add another field/list to the RangeTblEntry structure to
hold my working aliases, and if I keep the ref structure as a pristine
copy of the parameters specified by the user, then everything will go
back to working as expected. There may be other places in the code
which really want one or the other of the fields, but as a first cut
I'll isolate the changes to just the parser directory, more or less.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Tue Feb 29 01:41:14 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 BAA26182;
Tue, 29 Feb 2000 01:40:29 -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 GAA11084;
Tue, 29 Feb 2000 06:48:06 GMT
Sender: lockhart@hub.org
Message-ID: <38BB6BA6.B5FACCAD@alumni.caltech.edu>
Date: Tue, 29 Feb 2000 06:48:06 +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>,
"'pgsql-sql@postgresql.org'" <pgsql-sql@postgreSQL.org>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [SQL] prob with aggregate and group by - returns
multiplesh
References: <200002290559.AAA10605@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

If not, I'd vote for pulling it out. That's a heck of a poor word to
reserve.

I am afraid of lots of user complaints, even if we had not already used
TEMP.

OK, but we've already got "user complaints" about TEMP being a
reserved word, so that part seems to balance out. There is apparently
no basis in published standards for TEMP being a reserved word. And
btw it is not currently documented as a reserved word in
syntax.sgml...

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Tue Feb 29 02:02:15 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 CAA31851
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 02:01:47 -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 QAA04321; Tue, 29 Feb 2000 16:00:07 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "The Hermit Hacker" <scrappy@hub.org>
Cc: "Bruce Momjian" <pgman@candle.pha.pa.us>, "Tom Lane" <tgl@sss.pgh.pa.us>,
"PostgreSQL Development" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Re: ALTER TABLE DROP COLUMN
Date: Tue, 29 Feb 2000 16:06:29 +0900
Message-ID: <001401bf8283$805bf4e0$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <Pine.BSF.4.21.0002290231410.434-100000@thelab.hub.org>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

-----Original Message-----
From: The Hermit Hacker [mailto:scrappy@hub.org]

On Tue, 29 Feb 2000, Hiroshi Inoue wrote:

-----Original Message-----
From: The Hermit Hacker [mailto:scrappy@hub.org]

[snip]

Hiroshi ...

Bruce's comment was just an observation ... if it can be done
cleanly, I would love to see a version that didn't involve 2x the disk
space ... I don't believe that a trial would be useless, I think that
Bruce's only concern/warning is that the amount of code

modifications that

would have to be made in order to accomplish this *might* be

larger then

the benefit resulting in doing it this way.

If you feel that this can be done more efficiently, *please*
proceed with the trial ...

OK,I may be able to provide a trial patch in a week or so if I'm lucky.
How to commit the patch ?
With #ifdef ?

Nope, but it will have to wait until *after* 7.0 is released, so don't
push yourself on it ...

Hmm,until 7.0 release ?
I don't want to keep my private branch so long.
Is #ifdef bad to separate it from 7.0 release stuff ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Tue Feb 29 04:27:17 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 EAA76454
for <pgsql-hackers@postgresql.org>;
Tue, 29 Feb 2000 04:27:05 -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 KAA23403;
Tue, 29 Feb 2000 10:25:39 +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 12Pici-0000w3-00; Tue, 29 Feb 2000 09:07:20 +0000
Message-ID: <38BB7E2F.C481BBC3@sferacarta.com>
Date: Tue, 29 Feb 2000 09:07:11 +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>
Subject: Re: [HACKERS] having and union in v7beta
References: <38BA829F.C8BA2978@sferacarta.com> <25405.951750847@sss.pgh.pa.us>
Content-Type: multipart/mixed; boundary="------------F8D1F284CB65922F6B9DE4DA"

This is a multi-part message in MIME format.
--------------F8D1F284CB65922F6B9DE4DA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Jose Soares <jose@sferacarta.com> writes:

SELECT...HAVING, this last for example doesn't work.

That's a rather strong statement, and in fact a provably false one.
How about a detailed bug report rather than "it doesn't work"?

SELECT ... UNION (is 3 / 4 times slow)

Can't help you on that without more details, either. What is the
query exactly, what plan does EXPLAIN show, and what plan did you
get from 6.5?

regards, tom lane

--
Jose' Soares
Bologna, Italy Jose@sferacarta.com

--------------F8D1F284CB65922F6B9DE4DA
Content-Type: text/plain; charset=us-ascii;
name="having1.err"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="having1.err"

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================

Your name : Jose' Soares
Your email address : Jose@SferaCarta.com

System Configuration
---------------------
Architecture (example: Intel Pentium) : Intel Pentium

Operating System (example: Linux 2.0.26 ELF) : Linux 2.0.37 Elf

PostgreSQL version (example: PostgreSQL-6.1) : PostgreSQL-v7.0

Compiler used (example: gcc 2.7.2) : gcc 2.7.2.3

Please enter a FULL description of your problem:
------------------------------------------------
Seems that I found a bug on HAVING clause

Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
----------------------------------------------------------------------
I created a table like this one below:

CREATE TABLE comuni (
istat CHAR(06) PRIMARY KEY NOT NULL,
nome CHAR(50) NOT NULL,
provincia CHAR(02),
codice_fiscale CHAR(04),
cap CHAR(05),
regione CHAR(03),
distretto CHAR(04)
);
CREATE INDEX nome_comune_idx ON comuni (nome);

I tried the following query :

select * from comuni where nome in (
select nome from comuni group by nome having 1 < count(nome)
);

on the above table populated with 8342 rows, PostgreSQL begins searching
and I wait for hours without any result.

If you know how this problem might be fixed, list the solution below:
---------------------------------------------------------------------
I don't know, but I can send you my table data if you want it.

--------------F8D1F284CB65922F6B9DE4DA--

From bouncefilter Tue Feb 29 04:27:16 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 EAA76458
for <pgsql-hackers@postgresql.org>;
Tue, 29 Feb 2000 04:27:06 -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 KAA08401;
Tue, 29 Feb 2000 10:25:42 +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 12Pj3c-0000wT-00; Tue, 29 Feb 2000 09:35:08 +0000
Message-ID: <38BB84B3.1209A0C7@sferacarta.com>
Date: Tue, 29 Feb 2000 09:34:59 +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>
Subject: Re: [HACKERS] having and union in v7beta
References: <38BA829F.C8BA2978@sferacarta.com> <25405.951750847@sss.pgh.pa.us>
<38BA998A.258E068C@sferacarta.com> <27055.951783375@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Jose Soares <jose@sferacarta.com> writes:

SELECT ... UNION (is 3 / 4 times slow)

Can't help you on that without more details, either. What is the
query exactly, what plan does EXPLAIN show, and what plan did you
get from 6.5?

psql7=> EXPLAIN select distretto from comuni union select codice_fiscale from comuni;
NOTICE: QUERY PLAN:

Unique (cost=1767.19..1808.90 rows=1668 width=12)

-> Sort (cost=1767.19..1767.19 rows=16684 width=12)
-> Append (cost=0.00..464.84 rows=16684 width=12)
-> Seq Scan on comuni (cost=0.00..232.42 rows=8342 width=12)
-> Seq Scan on comuni (cost=0.00..232.42 rows=8342 width=12)

[ and exactly the same plan for 6.5 ]

OK, so much for my first thought that the 7.0 planner was choosing a
bad plan.

One relevant change is that Unique nodes now invoke the proper
type-specific equality function(s) to decide whether tuples are distinct
or not, instead of doing a bitwise comparison (memcmp()) like they did
before. But it's tough to believe that that accounts for a 3-to-4x
slowdown of this query; certainly I don't see much performance
difference on the datatypes I tried. What datatypes are your fields,
anyway?

6.5 takes 0.463s
7.0 takes 1.640s
the field type is CHAR(4)

The other possibility is that the Sort step is a lot slower in 7.0,
although I don't think it should be. Are you running both versions
with the same -S setting, and if so what is it? Could it be that

I'm running both of them in this way:
postmaster -i -o -F -B 512 -S > server.log 2>&1

the query is right on the edge of needing to switch from memory-based
to disk-based sort? Perhaps 7.0 is deciding that it needs to go to
disk a little sooner than 6.5 did.

regards, tom lane

--
Jose' Soares
Bologna, Italy Jose@sferacarta.com

From bouncefilter Tue Feb 29 05:08:17 2000
Received: from hu.tm.ee (ppp41.tele2.ee [212.107.33.41])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA83385
for <pgsql-hackers@postgresql.org>;
Tue, 29 Feb 2000 05:07: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 644313AF2; Tue, 29 Feb 2000 12:17:05 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38BB9CA1.5FFA3F1F@tm.ee>
Date: Tue, 29 Feb 2000 12:17:05 +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: Jan Wieck <wieck@debis.com>
Cc: Don Baccus <dhogaza@pacifier.com>, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
References: <m12PcL5-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jan Wieck wrote:

Explanative version of "that other story". But not exactly
correct IMHO. If following strictly SQL3 suggestions, an ON
DELETE RESTRICT action cannot be deferrable at all. Even if
the constraint itself is deferrable and is set explicitly to
DEFERRED, the check should be done immediately at ROW level.
That's the difference between "NO ACTION" and "RESTRICT".

Actually, a RESTRICT violation can potentially bypass
thousands of subsequent queries until COMMIT. Meaningless
from the transactional PoV, but from the application
programmers one (looking at the return code of a particular
statement) it isn't!

...

It'll be expensive, compared to current UNIQUE implementation
doing it on the fly during btree insert (doesn't it?). But
the only way I see.

So currently we have ON UPDATE RESTRICT foreign keys :)

-------------
Hannu

From bouncefilter Tue Feb 29 05:34:17 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 FAA86905
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 05:34:08 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12PjnP-0003kGC; Tue, 29 Feb 100 11:22 MET
Message-Id: <m12PjnP-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
In-Reply-To: <3.0.1.32.20000228185614.00ed25d0@mail.pacifier.com> from Don
Baccus at "Feb 28, 2000 06:56:14 pm"
To: Don Baccus <dhogaza@pacifier.com>
Date: Tue, 29 Feb 2000 11:22:27 +0100 (CET)
CC: Jan Wieck <wieck@debis.com>, Hannu Krosing <hannu@tm.ee>,
Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <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

Don Baccus wrote:

At 03:24 AM 2/29/00 +0100, Jan Wieck wrote:

Actually, a RESTRICT violation can potentially bypass
thousands of subsequent queries until COMMIT. Meaningless
from the transactional PoV, but from the application
programmers one (looking at the return code of a particular
statement) it isn't!

No, strictly speaking it isn't correct. But without a stopwatch,
it will be hard to tell.

It is easy to tell:

CREATE TABLE t1 (a integer PRIMARY KEY);
CREATE TABLE t2 (a integer REFERENCES t1
ON DELETE RESTRICT
DEFERRABLE);

INSERT INTO t1 VALUES (1);
INSERT INTO t1 VALUES (2);
INSERT INTO t1 VALUES (3);

INSERT INTO t2 VALUES (1);
INSERT INTO t2 VALUES (2);

BEGIN TRANSACTION;
SET CONSTRAINTS ALL DEFERRED;
DELETE FROM t1 WHERE a = 2;
DELETE FROM t1 WHERE a = 3;
COMMIT TRANSACTION;

In this case, the first DELETE from t1 must already bomb the
exception, setting the transaction block into error state and
reject all further queries until COMMIT/ROLLBACK. The SET
DEFERRED should only affect a check for key existance on
INSERT to t2, not the RESTRICT action on DELETE to t1.

The end result will be the same, both DELETEs get rolled
back. But the application will see it at COMMIT, not at the
first DELETE. So the system behaves exactly like for NO
ACTION.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Tue Feb 29 05:43:17 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 FAA90144
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 05:43:02 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12Pjvt-0003kgC; Tue, 29 Feb 100 11:31 MET
Message-Id: <m12Pjvt-0003kgC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
In-Reply-To: <38BB9CA1.5FFA3F1F@tm.ee> from Hannu Krosing at "Feb 29,
2000 12:17:05 pm"
To: Hannu Krosing <hannu@tm.ee>
Date: Tue, 29 Feb 2000 11:31:13 +0100 (CET)
CC: Jan Wieck <wieck@debis.com>, Don Baccus <dhogaza@pacifier.com>,
Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <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

Hannu Krosing wrote:

Jan Wieck wrote:

Actually, a RESTRICT violation can potentially bypass
thousands of subsequent queries until COMMIT. Meaningless
from the transactional PoV, but from the application
programmers one (looking at the return code of a particular
statement) it isn't!

...

It'll be expensive, compared to current UNIQUE implementation
doing it on the fly during btree insert (doesn't it?). But
the only way I see.

So currently we have ON UPDATE RESTRICT foreign keys :)

For foreign keys we actually have ON UPDATE/DELETE NO ACTION
(plus SET NULL and SET DEFAULT). Only the RESTRICT isn't
fully SQL3. I just had an idea that might easily turn it to
do the right thing.

For the UNIQUE constraint, it's totally wrong (and not
related to FOREIGN KEY stuff at all). The UNIQUE constraint
isn't deferrable at all, and it looks for violations on a per
row level, not on a per set level as it should.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Tue Feb 29 05:39:17 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 FAA87542
for <pgsql-hackers@postgresql.org>;
Tue, 29 Feb 2000 05:38:56 -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 LAA14203;
Tue, 29 Feb 2000 11:38:52 +0100
Date: Tue, 29 Feb 2000 11:38:52 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Peter Eisentraut <peter_e@gmx.net>
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE
In-Reply-To: <Pine.LNX.4.21.0002282246340.3511-100000@localhost.localdomain>
Message-ID: <Pine.LNX.3.96.1000229103347.8101A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 29 Feb 2000, Peter Eisentraut wrote:

Karel Zak - Zakkr writes:

This patch add to current code NOCREATETABLE and NOLOCKTABLE feature:

CREATE USER username
[ WITH
[ SYSID uid ]
[ PASSWORD 'password' ] ]
[ CREATEDB | NOCREATEDB ] [ CREATEUSER | NOCREATEUSER ]
-> [ CREATETABLE | NOCREATETABLE ] [ LOCKTABLE | NOLOCKTABLE ]
...etc.

IMHO, the syntax for create user is a hell and a half. Adding more
keywords in the current fashion is a dead end. (Note: you have to remember
the order in which the user "features" have to be entered.)

I might as well propose that now, I'd like to see a syntax like

CREATE USER name (
password = 'xxx',
sysid = 99,
superuser = true,
...
);

That's much more flexible and extensible. The old syntax could coexist
with this too.

Agree (Why is it not in TODO?). Do you work on this?

Regarding your two new features:

If you disallow table locking you might as well tell users not to use the
database. People need locks to operate a relational database. You will end

Here I not agree. I need users account with read-only/non-lock access. Very
simple is say "..not to use the database..", but you not "remake" my users,
you not admin for these users .. :-)

My NOLOCK implementation disallow LOCK TABLE command only, it not change
a low-level locking management.

Disallowing table creation might seem like a decent idea, but if at all,
it should go into the grant/revoke realm. Incidentally, this is quite at
odds with the SQL idea of how things should work, and I had hoped we could
get there some day.

The grant/revoke is good, but it is not global setting.

The PostgreSQL needs more options/settings for administration, a current
features is very unsatisfactory for real using for large and multiuser
aplication.

My suggestion for PG's priv./accounts:

1/ global setting which overwrite local (acl) settings
- read-only account
- disable account (oracle: ACCOUNT LOCK)
- create table priv.
- user's quotas (but without tablespace?)

2/ spit current super-user privileges to
- (dis)allow create functions/opretors/trigers
- (dis)allow create user
? (dis)allow change system tables

3/ ? - remove current hda.conf to system catalogs

4/ user profiles
- CONNECT_TIME
- IDLE_TIME
- PASSWORD_LIFE_TIME
- PASSWORD_VERIFY_FUNCTION (trust/password/kerberos..)
- ..etc
(- CPU SPENTING ?)

5/ acl mask - default privilege for new table

Karel

From bouncefilter Tue Feb 29 05:32:17 2000
Received: from hu.tm.ee (ppp41.tele2.ee [212.107.33.41])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA86381
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 05:32:09 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 75C443B75; Tue, 29 Feb 2000 12:41:20 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38BBA250.2428E3EC@tm.ee>
Date: Tue, 29 Feb 2000 12:41: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: Jan Wieck <wieck@debis.com>, Don Baccus <dhogaza@pacifier.com>,
Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
References: <m12PcL5-0003kGC@orion.SAPserv.Hamburg.dsh.de>
<38BB9CA1.5FFA3F1F@tm.ee>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hannu Krosing wrote:

Jan Wieck wrote:

It'll be expensive, compared to current UNIQUE implementation
doing it on the fly during btree insert (doesn't it?). But
the only way I see.

So currently we have foreign keys :)

I meant of course ON UPDATE RESTRICT PRIMARY KEYS ..

----------
Hannu

From bouncefilter Tue Feb 29 05:55:17 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 FAA92438;
Tue, 29 Feb 2000 05:54:17 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Svan.DoCS.UU.SE (e99re41@Svan.DoCS.UU.SE [130.238.9.160])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id LAA14683;
Tue, 29 Feb 2000 11:54:07 +0100 (MET)
Received: from localhost (e99re41@localhost) by Svan.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id LAA14557;
Tue, 29 Feb 2000 11:54:06 +0100
X-Authentication-Warning: Svan.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 29 Feb 2000 11:54:06 +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>, George Dau <gedau@isa.mim.com.au>,
"'pgsql-sql@postgresql.org'" <pgsql-sql@postgresql.org>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [SQL] prob with aggregate and group by - returns
multiples
In-Reply-To: <38BB5D9C.ED50B126@alumni.caltech.edu>
Message-ID: <Pine.GSO.4.02A.10002291151270.14457-100000@Svan.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 29 Feb 2000, Thomas Lockhart wrote:

Postgres thinks that TEMP is a keyword, so it won't take it as a table
name unless you put quotes around it.

This is really an unfortunate case where someone should have read the SQL
standard before putting in a feature. The SQL keyword is TEMPORARY, and
TEMP is really a popular name for a dummy table.

So why not yank TEMP and require TEMPORARY? Saving an extra 5
characters of typing is not a good enough reason to keep it imho, and
if the SQL92 standard requires a particular form why bother extending
it?

A major release is a good time to adjust syntax to promote
compliance...

I've been (lightly) bashed in the past for proposing such things (see
END/ABORT) but I'm with you. I think that TEMP may be far too wide-spread
by now, though.

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Tue Feb 29 06:14:18 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 GAA97013
for <pgsql-hackers@postgresql.org>;
Tue, 29 Feb 2000 06:14:12 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Svan.DoCS.UU.SE (e99re41@Svan.DoCS.UU.SE [130.238.9.160])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id MAA16555;
Tue, 29 Feb 2000 12:14:07 +0100 (MET)
Received: from localhost (e99re41@localhost) by Svan.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id MAA14811;
Tue, 29 Feb 2000 12:14:07 +0100
X-Authentication-Warning: Svan.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 29 Feb 2000 12:14:06 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE
In-Reply-To: <Pine.LNX.3.96.1000229103347.8101A-100000@ara.zf.jcu.cz>
Message-ID: <Pine.GSO.4.02A.10002291154150.14457-100000@Svan.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 29 Feb 2000, Karel Zak - Zakkr wrote:

I might as well propose that now, I'd like to see a syntax like

CREATE USER name (
password = 'xxx',
sysid = 99,
superuser = true,
...
);

That's much more flexible and extensible. The old syntax could coexist
with this too.

Agree (Why is it not in TODO?). Do you work on this?

Not right now but I'm planning on reworking the privilege system to get in
compliance with SQL whenever we are through the beta phase. The creation
of users is implementation defined but I guess I'm proposing this to those
who care.

If you disallow table locking you might as well tell users not to use the
database. People need locks to operate a relational database. You will end

My NOLOCK implementation disallow LOCK TABLE command only, it not change
a low-level locking management.

Exactly. The only goal that this will reach is to prevent people from
fully using all the features available to them. It does not prevent them
from doing denial of service attacks (which is presumably what motivated
this). As a simple example:

BEGIN;
SELECT a FROM b FOR UPDATE; -- or some such
-- twiddle thumbs

will also claim locks on b. Or consider people wanting to use serializable
transactions (SQL requirement, mind you). Then you can't even really guess
what will be locked when. To summarize, just disallow using the LOCK
command is not a good way to prevent locks.

I recall that there already is some permission checking done in the lock
manager. For example, you can't claim an exclusive lock on someone else's
table. A logical extension to this (which might be done already) would be
to disallow write-related locks on a table you don't have write access to
in the first place. Preventing malicious locking should be well-integrated
with the other privileges.

Disallowing table creation might seem like a decent idea, but if at all,
it should go into the grant/revoke realm. Incidentally, this is quite at
odds with the SQL idea of how things should work, and I had hoped we could
get there some day.

The grant/revoke is good, but it is not global setting.

Exactly. But create user is a global thing. The only reason to have any
prileges at all in pg_shadow is because some cannot be database-specific
(such as the right to create a database). I wouldn't object to a GRANT
CREATE, if it applies to all creates, not just tables. People clearly want
that, and we're not going to have schemas soon. Incidentally, I believe
that the privileges necessary to create a table are left to the
implementation, so I withdraw part of my argument above.

My suggestion for PG's priv./accounts:

Great, as I said, I've been meaning to look into this. I'd be happy to
hear any "demands".

- read-only account

Just don't give anyone write permissions to anything. Unix doesn't have
read-only accounts. I'm not so excited about non-orthogonal privileges.

- disable account (oracle: ACCOUNT LOCK)

Hmm, that sounds reasonable.

- create table priv.

On its way. ;)

- user's quotas (but without tablespace?)

Probably very hard to do. The day you started using a relational database
you largely gave up on tightly controlling storage constraints. See the
never ending debate on 2x disk usage on drop column. Certainly useful,
though.

- (dis)allow create functions/opretors/trigers

Could/should be integrated in grant create.

- (dis)allow create user
? (dis)allow change system tables

Exist already.

3/ ? - remove current hda.conf to system catalogs

Won't work. The postmaster must authenticate the user before the database
starts up. Well, it doesn't absolutely have to but redesigning that would
be a pain.

- CONNECT_TIME
- IDLE_TIME

Interesting. That would probably require a lot of work, though.

- PASSWORD_LIFE_TIME

Got that.

- PASSWORD_VERIFY_FUNCTION (trust/password/kerberos..)
- ..etc
(- CPU SPENTING ?)

5/ acl mask - default privilege for new table

Definitely.

Seems like we have a full bag of plans. Let's argue it out! ;)

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Tue Feb 29 07:34:20 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 HAA74059
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 07:33:55 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12PlfQ-0003kkC; Tue, 29 Feb 100 13:22 MET
Message-Id: <m12PlfQ-0003kkC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
In-Reply-To: <m12Pjvt-0003kgC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Feb 29, 2000 11:31:13 am"
To: Jan Wieck <wieck@debis.com>
Date: Tue, 29 Feb 2000 13:22:19 +0100 (CET)
CC: Hannu Krosing <hannu@tm.ee>, Don Baccus <dhogaza@pacifier.com>,
Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <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

I wrote:

fully SQL3. I just had an idea that might easily turn it to
do the right thing.

ON <event> RESTRICT triggers are now executed after the
statement allways, ignoring any explicitly set deferred mode.

This is pretty close to Date's SQL3 interpretation, or IMHO
better. Date says that they are checked BEFORE each ROW, but
that would ignore the SET character of a statement. Now we
have correct semantics for all 4 possible referential
actions.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Tue Feb 29 07:25: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 HAA71816
for <pgsql-hackers@postgresql.org>;
Tue, 29 Feb 2000 07:24: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 NAA02775;
Tue, 29 Feb 2000 13:24:37 +0100
Date: Tue, 29 Feb 2000 13:24:37 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Peter Eisentraut <peter_e@gmx.net>
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE
In-Reply-To: <Pine.GSO.4.02A.10002291154150.14457-100000@Svan.DoCS.UU.SE>
Message-ID: <Pine.LNX.3.96.1000229124729.15390B-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 29 Feb 2000, Peter Eisentraut wrote:

My suggestion for PG's priv./accounts:

Great, as I said, I've been meaning to look into this. I'd be happy to
hear any "demands".

- read-only account

Just don't give anyone write permissions to anything. Unix doesn't have
read-only accounts. I'm not so excited about non-orthogonal privileges.

- disable account (oracle: ACCOUNT LOCK)

Hmm, that sounds reasonable.

- create table priv.

On its way. ;)

- user's quotas (but without tablespace?)

Probably very hard to do. The day you started using a relational database
you largely gave up on tightly controlling storage constraints. See the
never ending debate on 2x disk usage on drop column. Certainly useful,
though.

- (dis)allow create functions/opretors/trigers

Could/should be integrated in grant create.

- (dis)allow create user
? (dis)allow change system tables

Exist already.

3/ ? - remove current hda.conf to system catalogs

Won't work. The postmaster must authenticate the user before the database
starts up. Well, it doesn't absolutely have to but redesigning that would
be a pain.

- CONNECT_TIME
- IDLE_TIME

Interesting. That would probably require a lot of work, though.

- PASSWORD_LIFE_TIME

Got that.

I said about a PROFILE, it is more flexible than current simple CREATE USER.

- PASSWORD_VERIFY_FUNCTION (trust/password/kerberos..)
- ..etc
(- CPU SPENTING ?)

5/ acl mask - default privilege for new table

Definitely.

Seems like we have a full bag of plans. Let's argue it out! ;)

I not only want new features and send suggestion, I can help with "full
bag of plans". But it is really great work and I not sure if is possible
create it as one-man project, it needs consensus between developers. If you
plan make changes to acl/account code it must be non-isolate change (it
must include user-profiles ..etc). (IMO of course :-)

A question: who is not user account defined for db and is it global? The
global account is probably not a problem, a problem is account settings.
IMHO is better use global account in 'pg_shadow' (with passwords, basic
options ..) and non-global 'pg_accountoption' in specific DB (with
CONNECT_TIME, IDLE_TIME, acl_mask ...etc.). This concept is better
extendable...

(We have free hands for this, it is not in SQL92 :-))

Karel

From bouncefilter Tue Feb 29 07:54: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 HAA79590
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 07:53:29 -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 NAA08070;
Tue, 29 Feb 2000 13:51:35 +0100
Date: Tue, 29 Feb 2000 13:51:35 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Hiroshi Inoue <Inoue@tpf.co.jp>
cc: Peter Eisentraut <peter_e@gmx.net>, Jan Wieck <wieck@debis.com>,
Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Cache query implemented
In-Reply-To: <000c01bf8272$89199120$2801007e@tpf.co.jp>
Message-ID: <Pine.LNX.3.96.1000229133620.6155A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 29 Feb 2000, Hiroshi Inoue wrote:

-----Original Message-----
From: Karel Zak - Zakkr [mailto:zakkr@zf.jcu.cz]

EXECUTE name [ INTO x, y, ... ] [ USING a, b, ... ]

This command "Associate input parametrs and output targets

with a prepared

statement and execute the statement" (SQL92).

I don't know well about PREPARE statement.
But is above syntax for interative SQL command ?
Isn't it for embedded SQL or SQL module ?

- PREPARE save to cache any standard sql command (OptimizableStmt).
- EXECUTE run this cached plan (query) and send data to frontend or
INTO any relation.

Or what you mean?

Karel

From bouncefilter Tue Feb 29 08:20:21 2000
Received: from thelab.hub.org (nat196.115.mpoweredpc.net [142.177.196.115])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA85691
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 08:20:07 -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 JAA63374;
Tue, 29 Feb 2000 09:17:08 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 29 Feb 2000 09:17:08 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Hiroshi Inoue <Inoue@tpf.co.jp>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Re: ALTER TABLE DROP COLUMN
In-Reply-To: <001401bf8283$805bf4e0$2801007e@tpf.co.jp>
Message-ID: <Pine.BSF.4.21.0002290915500.434-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 29 Feb 2000, Hiroshi Inoue wrote:

Nope, but it will have to wait until *after* 7.0 is released, so don't
push yourself on it ...

Hmm,until 7.0 release ?
I don't want to keep my private branch so long.
Is #ifdef bad to separate it from 7.0 release stuff ?

Go for it and submit a patch ... if its totally innoculous, then we can
try and plug her in, but I won't guarantee it. Since there should be no
major changes between now and 7.0 release, we can store any patch until
the release also ...

From bouncefilter Tue Feb 29 09:15:20 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 JAA09619
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 09:14:40 -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 PAA122088
for <pgsql-hackers@postgreSQL.org>; Tue, 29 Feb 2000 15:14:36 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <1TSZG52L>; Tue, 29 Feb 2000 15:14:35 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C604AF7D04@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'PostgreSQL Development'" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [SQL] prob with aggregate and group by - return
s multiplesh
Date: Tue, 29 Feb 2000 15:14:34 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

If not, I'd vote for pulling it out. That's a heck of a

poor word to

reserve.

I am afraid of lots of user complaints, even if we had not

already used

TEMP.

OK, but we've already got "user complaints" about TEMP being a
reserved word, so that part seems to balance out. There is apparently
no basis in published standards for TEMP being a reserved word. And
btw it is not currently documented as a reserved word in
syntax.sgml...

TEMP is not a reserved word in informix, so there seems to be the
possibility to do a
grammar trick.

The portability syntax that would be needed is only:

select * from table where ..... INTO TEMP _mytemp;

Your example had the into temp after the select list, which does
not work in informix.

Andreas

From bouncefilter Tue Feb 29 09:09:20 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 JAA08252
for <pgsql-hackers@postgresql.org>;
Tue, 29 Feb 2000 09:09: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 OAA11716;
Tue, 29 Feb 2000 14:19:47 GMT
Sender: lockhart@hub.org
Message-ID: <38BBD583.642CB33B@alumni.caltech.edu>
Date: Tue, 29 Feb 2000 14:19:47 +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>, Peter Eisentraut <peter_e@gmx.net>
CC: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE
References: <Pine.LNX.3.96.1000229124729.15390B-100000@ara.zf.jcu.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

plan make changes to acl/account code it must be non-isolate change (it
must include user-profiles ..etc). (IMO of course :-)

While I'm thinking about it...

The current acl storage scheme flattens the acl info into a single
string, with a special character ("=" as I recall) to delimit the
user/group name from the permissions. But by quoting the user name, it
is possible to create a user name which contains an equals sign,
screwing up the acl handling.

If you are redoing the acls, a good first step is to fix this, perhaps
by recoding the acl field into a structure with at least two fields
for username and permissions.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Tue Feb 29 10:02:22 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 KAA38248
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 10:01:58 -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 HAA05650;
Tue, 29 Feb 2000 07:01:36 -0800 (PST)
Message-Id: <3.0.1.32.20000229063059.01d031c0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 29 Feb 2000 06:30:59 -0800
To: Thomas Lockhart <lockhart@alumni.caltech.edu>, Jan Wieck <wieck@debis.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
In-Reply-To: <38BB5F30.F106C512@alumni.caltech.edu>
References: <m12PawP-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 05:54 AM 2/29/00 +0000, Thomas Lockhart wrote:

I did not claim to have the final form; I ran out of time before
heading out on vacation.

In retrospect, it shouldn't've gone into the beta at that point,
then. Crippling "unique not null" isn't merely an inconvenience.
Dropping a bomb like this into beta the night before release
and leaving town for nine days perhaps wasn't the best thing to
do. Perhaps we should avoid doing things like this in the future.

Because of this, the web toolkit I'm porting is going out with
6.5 only, rather than 6.5 or 7.0 beta with 7.0 beta recommended.
It's a pity, bugs and some of our hacks around missing features
in 6.5 make portions of the toolkit differ in their output than
the Oracle version. This hurts the credibility of the port,
to some degree, and simply adds ammunition to those who argue
that trying to do this kind of project on top of Postgres is
foolishness incarnate.

It's REALLY a pity because the Feb 18th snapshot I took and
tested, like earlier ones, was really solid. The toolkit was
looking great with the snapshot.

istm that solving the general case by
unrolling clauses should not be exhaustively difficult.

I actually did the unrolling of the worst cases last night, took
me about an hour with "Star Trek Voyager" on in the background
as a distraction from how ugly this hack is. Because, with all
due respect, Thomas, it is an exceedingly ugly hack. And you
can't unroll enough to capture the grammar anyway, it's like
trying to enumerate all possible expressions in the grammar
rather than parse the general form.

I ran into another problem, though, and presumed it was because
of my hacking. So I decided to roll back gram.y to the Feb
18 snapshot, did a clean/make of the parser, rebuilt and reinstalled,
and the thing still segtrapped on me.

I don't have time to dig deeper at the moment. I'll look later
tonight. It would take me about 15 minutes to recreate my
additional unrolling clauses, as well, but I'm hoping Tom was
serious about taking the time to do it right as unrolling is
NOT a solution.

What's wrong with actually accepting the SQL92 grammar, anyway?

I will
continue to pursue this as time permits.

"as time permits"? This implies we live with an unusable beta
in the interim?

- 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 29 09:31:20 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 JAA23345;
Tue, 29 Feb 2000 09:30:49 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id OAA11757;
Tue, 29 Feb 2000 14:35:08 GMT
Sender: lockhart@hub.org
Message-ID: <38BBD91C.E11F7547@alumni.caltech.edu>
Date: Tue, 29 Feb 2000 14:35:08 +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: Tom Lane <tgl@sss.pgh.pa.us>, George Dau <gedau@isa.mim.com.au>,
"'pgsql-sql@postgresql.org'" <pgsql-sql@postgresql.org>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [SQL] prob with aggregate and group by -
returnsmultiples
References: <Pine.GSO.4.02A.10002291151270.14457-100000@Svan.DoCS.UU.SE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

A major release is a good time to adjust syntax to promote
compliance...

I've been (lightly) bashed in the past for proposing such things (see
END/ABORT) but I'm with you. I think that TEMP may be far too wide-spread
by now, though.

Well, imho the TEMP issue is not identical to END/ABORT. For TEMP, we
are unnecessarily restricting the space of possible identifiers,
eliminating a common and obvious name. The fix is trivial, and the
affected parties are *only* those who use temporary tables and who
chose to *not* use SQL92 syntax, which was always available.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Tue Feb 29 10:02: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 KAA38238;
Tue, 29 Feb 2000 10:01:52 -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 HAA05656;
Tue, 29 Feb 2000 07:01:38 -0800 (PST)
Message-Id: <3.0.1.32.20000229063525.01d06150@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 29 Feb 2000 06:35:25 -0800
To: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Bruce Momjian <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: [SQL] prob with aggregate and group by -
returns multiplesh
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
"'pgsql-sql@postgresql.org'" <pgsql-sql@postgreSQL.org>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <38BB6BA6.B5FACCAD@alumni.caltech.edu>
References: <200002290559.AAA10605@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 06:48 AM 2/29/00 +0000, Thomas Lockhart wrote:

If not, I'd vote for pulling it out. That's a heck of a poor word to
reserve.

I am afraid of lots of user complaints, even if we had not already used
TEMP.

OK, but we've already got "user complaints" about TEMP being a
reserved word, so that part seems to balance out. There is apparently
no basis in published standards for TEMP being a reserved word. And
btw it is not currently documented as a reserved word in
syntax.sgml...

I vote for the SQL92 TEMPORARY. Let's not add a keyword that is non-standard
just because one or another commercial database makes use of it, unless
there's some real functionality to be gained that's not covered by the
standard.

TEMP is covered in SQL92 by TEMPORARY.

As an example of when adopting a construct from another commercial database
makes sense to me, SEQUENCE and SERIAL are both convenient means of generating
unique keys that have no equivalent in the standard.

- 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 29 09:42:20 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 JAA27552
for <pgsql-hackers@postgresql.org>;
Tue, 29 Feb 2000 09:42:19 -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 PAA19572;
Tue, 29 Feb 2000 15:40:40 +0100
Date: Tue, 29 Feb 2000 15:40:40 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE
In-Reply-To: <38BBD583.642CB33B@alumni.caltech.edu>
Message-ID: <Pine.LNX.3.96.1000229151444.6155D-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 29 Feb 2000, Thomas Lockhart wrote:

plan make changes to acl/account code it must be non-isolate change (it
must include user-profiles ..etc). (IMO of course :-)

While I'm thinking about it...

The current acl storage scheme flattens the acl info into a single
string, with a special character ("=" as I recall) to delimit the
user/group name from the permissions. But by quoting the user name, it
is possible to create a user name which contains an equals sign,
screwing up the acl handling.

If you are redoing the acls, a good first step is to fix this, perhaps
by recoding the acl field into a structure with at least two fields
for username and permissions.

Yes. And..the current schema (acl in pg_class) is not relation schema, in
the pg_class is username not user's oid...ect. Is possible create it as
relation? (Example, in pg_group we haven't username, we use oid here.)

My acl idea:

Why not create specific pg_acl table and split a current monolitic
acl string to more columns? Example:

Columns in pg_acl table:

reloid (oid) - relation (table) oid
user_insert (text[]) - privilege for users for insert
- in text array is
{"username1","username2"... }
(or use user's oid instead username)

group_insert - simular as previous, but for group
user_delete - ....etc.
...

example:

SELECT * from pg_acl;

reloid | user_insert | group_insert | user_delete ..........etc
---------------------------------------------------------
12345 | {"karel", "peter"} | {"group1"} | {"karel"} ..........etc

Is it bad idea? (It never needs any specific acl string parser, take
informatios from this table is very simple and very standard
"tuple-operation".) Yes, it is a little "talkative", but if instead
user/group name we use oid, it will right and nice.

...as I said: is the current acl/account schema good?

Karel

From bouncefilter Tue Feb 29 10:02: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 KAA38239
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 10:01:52 -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 HAA05663;
Tue, 29 Feb 2000 07:01:39 -0800 (PST)
Message-Id: <3.0.1.32.20000229065110.01d02830@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 29 Feb 2000 06:51:10 -0800
To: Jan Wieck <wieck@debis.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
Cc: Jan Wieck <wieck@debis.com>, Hannu Krosing <hannu@tm.ee>,
Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <m12PjnP-0003kGC@orion.SAPserv.Hamburg.dsh.de>
References: <3.0.1.32.20000228185614.00ed25d0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 11:22 AM 2/29/00 +0100, Jan Wieck wrote:

Don Baccus wrote:

At 03:24 AM 2/29/00 +0100, Jan Wieck wrote:

Actually, a RESTRICT violation can potentially bypass
thousands of subsequent queries until COMMIT. Meaningless
from the transactional PoV, but from the application
programmers one (looking at the return code of a particular
statement) it isn't!

No, strictly speaking it isn't correct. But without a stopwatch,
it will be hard to tell.

It is easy to tell:

CREATE TABLE t1 (a integer PRIMARY KEY);
CREATE TABLE t2 (a integer REFERENCES t1
ON DELETE RESTRICT
DEFERRABLE);

INSERT INTO t1 VALUES (1);
INSERT INTO t1 VALUES (2);
INSERT INTO t1 VALUES (3);

INSERT INTO t2 VALUES (1);
INSERT INTO t2 VALUES (2);

BEGIN TRANSACTION;
SET CONSTRAINTS ALL DEFERRED;
DELETE FROM t1 WHERE a = 2;
DELETE FROM t1 WHERE a = 3;
COMMIT TRANSACTION;

In this case, the first DELETE from t1 must already bomb the
exception, setting the transaction block into error state and
reject all further queries until COMMIT/ROLLBACK.

Ahhh...but the point you're missing, which was brought up a few
days ago, is that this PG-ism of rejecting all further queries
until COMMIT/ROLLBACK is in itself NONSTANDARD.

As far as the effect of DEFERRED on RESTRICT with STANDARD, not
PG, transaction semantics I've not investigated it. Neither one
of us has a particularly great record at correctly interpreting
the SQL3 standard regarding the subtleties of foreign key semantics,
since we both had differing interpretations of RESTRICT/NO ACTION
and (harumph) we were BOTH wrong :) Date implies that there's
no difference other than RESTRICT's returning an error more quickly,
but he doesn't talk about the DEFERRED case.

Anyway, it's moot at the moment since neither RESTRICT nor standard
SQL92 transaction semantics are implemented.

The end result will be the same,

Which is what I mean when I say you pretty much need a stopwatch
to tell the difference - OK, in PG you can look at the non-standard
error messages due to the non-standard rejection of subsequent
queries, but I was thinking in terms of standard transaction
semantics.

both DELETEs get rolled
back. But the application will see it at COMMIT, not at the
first DELETE. So the system behaves exactly like for NO
ACTION.

Yes.

- 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 29 10:02:20 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 KAA38348
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 10:02:12 -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 HAA05670;
Tue, 29 Feb 2000 07:01:40 -0800 (PST)
Message-Id: <3.0.1.32.20000229065604.01d07510@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 29 Feb 2000 06:56:04 -0800
To: Jan Wieck <wieck@debis.com>, Jan Wieck <wieck@debis.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
Cc: Hannu Krosing <hannu@tm.ee>, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <m12PlfQ-0003kkC@orion.SAPserv.Hamburg.dsh.de>
References: <m12Pjvt-0003kgC@orion.SAPserv.Hamburg.dsh.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 01:22 PM 2/29/00 +0100, Jan Wieck wrote:

I wrote:

fully SQL3. I just had an idea that might easily turn it to
do the right thing.

ON <event> RESTRICT triggers are now executed after the
statement allways, ignoring any explicitly set deferred mode.
This is pretty close to Date's SQL3 interpretation, or IMHO
better. Date says that they are checked BEFORE each ROW, but
that would ignore the SET character of a statement.

Perhaps that's actually the point of RESTRICT? Sacrifice the
set character of a statement in this special case in order to
return an error quickly?

Since RESTRICT wasn't in SQL92, and since it's very close to
NO ACTION, it reeks of being an efficiency hack.

I dread digging into that part of the standard again...this is
a case where the various proposals and justifications that were
before the committee at the time would be useful since the
actual words that made it to the standard are opaque.

- 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 29 10:57: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 KAA60644;
Tue, 29 Feb 2000 10:57:05 -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 JAA28930;
Tue, 29 Feb 2000 09:57:56 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
"'pgsql-sql@postgresql.org'" <pgsql-sql@postgreSQL.org>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [SQL] prob with aggregate and group by - returns
multiplesh
In-reply-to: <38BB6BA6.B5FACCAD@alumni.caltech.edu>
References: <200002290559.AAA10605@candle.pha.pa.us>
<38BB6BA6.B5FACCAD@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Tue, 29 Feb 2000 06:48:06 +0000"
Date: Tue, 29 Feb 2000 09:57:56 -0500
Message-ID: <28927.951836276@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

If not, I'd vote for pulling it out. That's a heck of a poor word to
reserve.

I am afraid of lots of user complaints, even if we had not already used
TEMP.

OK, but we've already got "user complaints" about TEMP being a
reserved word, so that part seems to balance out. There is apparently
no basis in published standards for TEMP being a reserved word. And
btw it is not currently documented as a reserved word in
syntax.sgml...

The real problem is not that we accept TEMP as a synonym for TEMPORARY;
it is that we treat TEMP as a reserved word. What are the chances that
we could make it a member of the ColId list? I am thinking that
"... INTO TEMP temp" is *not* ambiguous given one token lookahead...

regards, tom lane

From bouncefilter Tue Feb 29 10:56: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 KAA60188
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 10:55: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 JAA28947;
Tue, 29 Feb 2000 09:59:17 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] interesting observatation regarding views and V7.0
In-reply-to: <38BB6A77.53DEDA9D@alumni.caltech.edu>
References: <3.0.1.32.20000223081725.010c5c90@mail.pacifier.com>
<5883.951346476@sss.pgh.pa.us>
<38BA99A3.5AF903B3@alumni.caltech.edu>
<25724.951755786@sss.pgh.pa.us>
<38BB6A77.53DEDA9D@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Tue, 29 Feb 2000 06:43:03 +0000"
Date: Tue, 29 Feb 2000 09:59:17 -0500
Message-ID: <28944.951836357@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

Well, if I add another field/list to the RangeTblEntry structure to
hold my working aliases, and if I keep the ref structure as a pristine
copy of the parameters specified by the user, then everything will go
back to working as expected. There may be other places in the code
which really want one or the other of the fields, but as a first cut
I'll isolate the changes to just the parser directory, more or less.

Sounds like a good plan.

regards, tom lane

From bouncefilter Tue Feb 29 10:55: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 KAA60037
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 10:55: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 KAA29000
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 10:28:37 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: Re: Is anyone working on pg_dump?
In-reply-to: <4779.951674423@sss.pgh.pa.us>
References: <4779.951674423@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
message dated "Sun, 27 Feb 2000 13:00:23 -0500"
Date: Tue, 29 Feb 2000 10:28:37 -0500
Message-ID: <28997.951838117@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I wrote:

One of the major must-fix items remaining on my to-do-for-7.0 list
is making pg_dump smarter about the order to dump stuff in, so as
to avoid problems like table constraints referring to not-yet-
defined functions.

I spent a couple evenings working on this, and have made good progress;
but looking at how much I've changed and how much remains, I'm forced
to realize that this is "too big a change for beta". It requires a
major restructuring of pg_dump. Since we don't have regression tests
for pg_dump, I think the risk of breaking something is too high for
this phase of the release cycle.

I plan to set the unfinished code aside for now, and come back to it
early in the 7.1 cycle. We'll have to live with the ordering issue
for another release.

regards, tom lane

From bouncefilter Tue Feb 29 11:11: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 LAA68070;
Tue, 29 Feb 2000 11:11:05 -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 LAA29207;
Tue, 29 Feb 2000 11:09:37 -0500 (EST)
To: Don Baccus <dhogaza@pacifier.com>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Bruce Momjian <pgman@candle.pha.pa.us>,
"'pgsql-sql@postgresql.org'" <pgsql-sql@postgreSQL.org>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [SQL] prob with aggregate and group by - returns
multiplesh
In-reply-to: <3.0.1.32.20000229063525.01d06150@mail.pacifier.com>
References: <200002290559.AAA10605@candle.pha.pa.us>
<3.0.1.32.20000229063525.01d06150@mail.pacifier.com>
Comments: In-reply-to Don Baccus <dhogaza@pacifier.com>
message dated "Tue, 29 Feb 2000 06:35:25 -0800"
Date: Tue, 29 Feb 2000 11:09:37 -0500
Message-ID: <29204.951840577@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Don Baccus <dhogaza@pacifier.com> writes:

I vote for the SQL92 TEMPORARY. Let's not add a keyword that is non-standard
just because one or another commercial database makes use of it,

You're missing the point: we are not talking about *adding* a keyword,
we're talking about *removing* one that we've already supported for
a year or so. That changes matters considerably, IMHO.

I have in fact been able to make a conflict-free grammar in which TEMP
is accepted but not reserved. It requires a certain amount of
redundancy in the productions (see below), but I think this is a
worthwhile tradeoff for not breaking existing user code.

Shall I commit this?

regards, tom lane

/*
* Redundancy here is needed to avoid shift/reduce conflicts,
* since TEMP is not a reserved word. See also OptTemp.
*
* The result is a cons cell (not a true list!) containing
* a boolean and a table name.
*/
OptTempTableName: TEMPORARY opt_table relation_name
{ $$ = lcons(makeInteger(TRUE), (List *) $3); }
| TEMP opt_table relation_name
{ $$ = lcons(makeInteger(TRUE), (List *) $3); }
| LOCAL TEMPORARY opt_table relation_name
{ $$ = lcons(makeInteger(TRUE), (List *) $4); }
| LOCAL TEMP opt_table relation_name
{ $$ = lcons(makeInteger(TRUE), (List *) $4); }
| GLOBAL TEMPORARY opt_table relation_name
{
elog(ERROR, "GLOBAL TEMPORARY TABLE is not currently supported");
$$ = lcons(makeInteger(TRUE), (List *) $4);
}
| GLOBAL TEMP opt_table relation_name
{
elog(ERROR, "GLOBAL TEMPORARY TABLE is not currently supported");
$$ = lcons(makeInteger(TRUE), (List *) $4);
}
| TABLE relation_name
{ $$ = lcons(makeInteger(FALSE), (List *) $2); }
| relation_name
{ $$ = lcons(makeInteger(FALSE), (List *) $1); }
;

From bouncefilter Tue Feb 29 11:37: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 LAA75491
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 11:37:20 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Rama.DoCS.UU.SE (e99re41@Rama.DoCS.UU.SE [130.238.9.98])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id RAA18802;
Tue, 29 Feb 2000 17:37:10 +0100 (MET)
Received: from localhost (e99re41@localhost) by Rama.DoCS.UU.SE
(8.6.12/8.6.12) with ESMTP id RAA25503;
Tue, 29 Feb 2000 17:37:08 +0100
X-Authentication-Warning: Rama.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 29 Feb 2000 17:37:08 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Don Baccus <dhogaza@pacifier.com>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Jan Wieck <wieck@debis.com>,
Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
In-Reply-To: <3.0.1.32.20000229063059.01d031c0@mail.pacifier.com>
Message-ID: <Pine.GSO.4.02A.10002291728340.18993-100000@Rama.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.org id LAA75502

On Tue, 29 Feb 2000, Don Baccus wrote:

Because of this, the web toolkit I'm porting is going out with
6.5 only, rather than 6.5 or 7.0 beta with 7.0 beta recommended.
It's a pity, bugs and some of our hacks around missing features
in 6.5 make portions of the toolkit differ in their output than
the Oracle version. This hurts the credibility of the port,
to some degree, and simply adds ammunition to those who argue
that trying to do this kind of project on top of Postgres is
foolishness incarnate.

It's BETA. You're not supposed to use it in production work. Beta is a
feature freeze, then we try to sort out the bugs.

As far as I'm concerned it would hurt credibility of the port much more to
"recommend" a beta version of a database server as its backend. If you
need 7.0 for your port then you should have waited a month. While I agree
that the parser "fixes" were less than ideal, we're not primarily
developing PostgreSQL to work with your toolkit.

I actually did the unrolling of the worst cases last night, took
me about an hour with "Star Trek Voyager" on in the background
as a distraction from how ugly this hack is. Because, with all
due respect, Thomas, it is an exceedingly ugly hack. And you
can't unroll enough to capture the grammar anyway, it's like
trying to enumerate all possible expressions in the grammar
rather than parse the general form.

The difference is that the expression space is infinite, whereas unrolling
all column constraints should be on the order of a dozen or two. Better
ideas are welcome of course.

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Tue Feb 29 11:39: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 LAA75719;
Tue, 29 Feb 2000 11:38:32 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Rama.DoCS.UU.SE (e99re41@Rama.DoCS.UU.SE [130.238.9.98])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id RAA18920;
Tue, 29 Feb 2000 17:38:27 +0100 (MET)
Received: from localhost (e99re41@localhost) by Rama.DoCS.UU.SE
(8.6.12/8.6.12) with ESMTP id RAA25632;
Tue, 29 Feb 2000 17:38:26 +0100
X-Authentication-Warning: Rama.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 29 Feb 2000 17:38:26 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Don Baccus <dhogaza@pacifier.com>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Bruce Momjian <pgman@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>,
"'pgsql-sql@postgresql.org'" <pgsql-sql@postgreSQL.org>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [SQL] prob with aggregate and group by -
returns multiplesh
In-Reply-To: <3.0.1.32.20000229063525.01d06150@mail.pacifier.com>
Message-ID: <Pine.GSO.4.02A.10002291737320.18993-100000@Rama.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.org id LAA75803

On Tue, 29 Feb 2000, Don Baccus wrote:

I vote for the SQL92 TEMPORARY. Let's not add a keyword that is non-standard
just because one or another commercial database makes use of it, unless
there's some real functionality to be gained that's not covered by the
standard.

The difference is that TEMP is already a keyword since 6.5 and we're
considering removing it.

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Tue Feb 29 11:30:22 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 LAA72810
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 11:29:19 -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 QAA11976;
Tue, 29 Feb 2000 16:39:52 GMT
Sender: lockhart@hub.org
Message-ID: <38BBF657.DC40E0FA@alumni.caltech.edu>
Date: Tue, 29 Feb 2000 16:39: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: Don Baccus <dhogaza@pacifier.com>
CC: Jan Wieck <wieck@debis.com>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
References: <m12PawP-0003kGC@orion.SAPserv.Hamburg.dsh.de>
<3.0.1.32.20000229063059.01d031c0@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I did not claim to have the final form; I ran out of time before
heading out on vacation.

In retrospect, it shouldn't've gone into the beta at that point,
then. Crippling "unique not null" isn't merely an inconvenience.
Dropping a bomb like this into beta the night before release
and leaving town for nine days perhaps wasn't the best thing to
do. Perhaps we should avoid doing things like this in the future.

Lighten up Don! I put this in so Jan et al can get cracking on the
referential integrity stuff in the column specification, and imho the
feature and space of possible solutions is isolated and finite. Not a
big risk for the first part of beta.

<snip>

What's wrong with actually accepting the SQL92 grammar, anyway?

?? That is what we are trying to do.

I'm not sure what your point is about "having to ship 6.5 instead of
7.0" for your porting project. If you aren't willing to cope with
small changes/features/breakage in a beta cycle you should stay away
from betas.

There is *no* reason you should think that the restriction on syntax
in this area is a permanent feature or something that will persist
through beta. If you are on such a tight schedule that you can't cope
with a 2 week slip in a feature, or a 2 week breakage from your PoV,
then beta isn't for you!!

otoh, if you are planning on shipping after the 7.0 release, then
there isn't a problem. And if you need a system which has *exactly*
the behaviors of a couple of weeks ago, then use a snapshot from a
couple of weeks ago. I'll prep and send you one if you would like.

Regards.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Tue Feb 29 11:49:23 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 LAA77650
for <pgsql-hackers@postgresql.org>;
Tue, 29 Feb 2000 11:48:38 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Rama.DoCS.UU.SE (e99re41@Rama.DoCS.UU.SE [130.238.9.98])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id RAA19753;
Tue, 29 Feb 2000 17:48:34 +0100 (MET)
Received: from localhost (e99re41@localhost) by Rama.DoCS.UU.SE
(8.6.12/8.6.12) with ESMTP id RAA26609;
Tue, 29 Feb 2000 17:48:34 +0100
X-Authentication-Warning: Rama.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 29 Feb 2000 17:48:33 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE
In-Reply-To: <Pine.LNX.3.96.1000229151444.6155D-100000@ara.zf.jcu.cz>
Message-ID: <Pine.GSO.4.02A.10002291738410.18993-100000@Rama.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.org id LAA78022

On Tue, 29 Feb 2000, Karel Zak - Zakkr wrote:

On Tue, 29 Feb 2000, Thomas Lockhart wrote:

(I didn't get this email, but anyway ...)

The current acl storage scheme flattens the acl info into a single
string, with a special character ("=" as I recall) to delimit the
user/group name from the permissions. But by quoting the user name, it
is possible to create a user name which contains an equals sign,
screwing up the acl handling.

Try creating a user "group xxx" ...

If you are redoing the acls, a good first step is to fix this, perhaps
by recoding the acl field into a structure with at least two fields
for username and permissions.

This was precisely the idea. Everything else should fall in place more
easily after that.

My acl idea:

reloid | user_insert | group_insert | user_delete ..........etc
---------------------------------------------------------
12345 | {"karel", "peter"} | {"group1"} | {"karel"} ..........etc

This still has arrays. (shudder) Try getting the information 'Does Peter
have access to x?' out of that. I was thinking along the lines of

create table pg_privilege/pg_acl/? (
objoid oid, -- not only reloid, but types, functions, etc.
userid int,
privilege char, -- maybe 'U' update, 'I' insert, etc.
grant_option bool
)

To be extended to cover column access as well. (Might have to be yet
another table.) Mathematically, this will be slower (especially since you
can't use SysCache on composite keys(???)) but similar schemas are
employed throughout by triggers etc.

...as I said: is the current acl/account schema good?

The SCHEME is good. The SCHEMA isn't.

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Tue Feb 29 12:56:23 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 MAA90996;
Tue, 29 Feb 2000 12:55: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
MAA26261;
Tue, 29 Feb 2000 12:19:02 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002291719.MAA26261@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [SQL] prob with aggregate and group by - returns
multiplesh
In-Reply-To: <38BB6BA6.B5FACCAD@alumni.caltech.edu> from Thomas Lockhart at
"Feb 29, 2000 06:48:06 am"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Tue, 29 Feb 2000 12:19:02 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>,
"'pgsql-sql@postgresql.org'" <pgsql-sql@postgreSQL.org>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

If not, I'd vote for pulling it out. That's a heck of a poor word to
reserve.

I am afraid of lots of user complaints, even if we had not already used
TEMP.

OK, but we've already got "user complaints" about TEMP being a
reserved word, so that part seems to balance out. There is apparently
no basis in published standards for TEMP being a reserved word. And
btw it is not currently documented as a reserved word in
syntax.sgml...

OK, I certainly didn't look at the standard to when I implemented TEMP
tables. In fact, I was surprised it worked considering it is just a
hack on the cache code.

Let's forget I made a mistake, and consider how many people are going to
think they should use TEMP and how many TEMPORARY. I personally would
guess TEMP and never TEMPORARY. I wonder if others would too.

So are we willing to field questions from people trying to use TEMP
tables and trying TEMP and not TEMPORARY. I realize the restriction on
a field called TEMP, but we don't get those very often. How many people
are going to guess TEMP and not TEMPORARY?

Of course, as a Unix guy, I may have guessed TMP 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 19026

From bouncefilter Tue Feb 29 12:56:24 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 MAA91028;
Tue, 29 Feb 2000 12:56: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
MAA26276;
Tue, 29 Feb 2000 12:21:26 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002291721.MAA26276@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [SQL] prob with aggregate and group by - returns
multiplesh
In-Reply-To: <29204.951840577@sss.pgh.pa.us> from Tom Lane at "Feb 29,
2000 11:09:37 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 29 Feb 2000 12:21:26 -0500 (EST)
CC: Don Baccus <dhogaza@pacifier.com>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
"'pgsql-sql@postgresql.org'" <pgsql-sql@postgreSQL.org>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Looks good to me.

Don Baccus <dhogaza@pacifier.com> writes:

I vote for the SQL92 TEMPORARY. Let's not add a keyword that is non-standard
just because one or another commercial database makes use of it,

You're missing the point: we are not talking about *adding* a keyword,
we're talking about *removing* one that we've already supported for
a year or so. That changes matters considerably, IMHO.

I have in fact been able to make a conflict-free grammar in which TEMP
is accepted but not reserved. It requires a certain amount of
redundancy in the productions (see below), but I think this is a
worthwhile tradeoff for not breaking existing user code.

Shall I commit this?

regards, tom lane

/*
* Redundancy here is needed to avoid shift/reduce conflicts,
* since TEMP is not a reserved word. See also OptTemp.
*
* The result is a cons cell (not a true list!) containing
* a boolean and a table name.
*/
OptTempTableName: TEMPORARY opt_table relation_name
{ $$ = lcons(makeInteger(TRUE), (List *) $3); }
| TEMP opt_table relation_name
{ $$ = lcons(makeInteger(TRUE), (List *) $3); }
| LOCAL TEMPORARY opt_table relation_name
{ $$ = lcons(makeInteger(TRUE), (List *) $4); }
| LOCAL TEMP opt_table relation_name
{ $$ = lcons(makeInteger(TRUE), (List *) $4); }
| GLOBAL TEMPORARY opt_table relation_name
{
elog(ERROR, "GLOBAL TEMPORARY TABLE is not currently supported");
$$ = lcons(makeInteger(TRUE), (List *) $4);
}
| GLOBAL TEMP opt_table relation_name
{
elog(ERROR, "GLOBAL TEMPORARY TABLE is not currently supported");
$$ = lcons(makeInteger(TRUE), (List *) $4);
}
| TABLE relation_name
{ $$ = lcons(makeInteger(FALSE), (List *) $2); }
| relation_name
{ $$ = lcons(makeInteger(FALSE), (List *) $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 19026

From bouncefilter Tue Feb 29 12:55:23 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 MAA90741
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 12:54: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 JAA05842;
Tue, 29 Feb 2000 09:54:05 -0800 (PST)
Message-Id: <3.0.1.32.20000229093333.01d0e720@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 29 Feb 2000 09:33:33 -0800
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
Cc: Jan Wieck <wieck@debis.com>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org
In-Reply-To: <38BBF657.DC40E0FA@alumni.caltech.edu>
References: <m12PawP-0003kGC@orion.SAPserv.Hamburg.dsh.de>
<3.0.1.32.20000229063059.01d031c0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 04:39 PM 2/29/00 +0000, Thomas Lockhart wrote:

I did not claim to have the final form; I ran out of time before
heading out on vacation.

In retrospect, it shouldn't've gone into the beta at that point,
then. Crippling "unique not null" isn't merely an inconvenience.
Dropping a bomb like this into beta the night before release
and leaving town for nine days perhaps wasn't the best thing to
do. Perhaps we should avoid doing things like this in the future.

Lighten up Don! I put this in so Jan et al can get cracking on the
referential integrity stuff in the column specification, and imho the
feature and space of possible solutions is isolated and finite. Not a
big risk for the first part of beta.

No, I won't lighten up. I said "in retrospect", and I used those
words intentionally to suggest that IN THE FUTURE we might take
more care. What's the harm in learning from experience?

An alternative might be to remove the following sentence from the
release notes:

"Don't be concerned this is a dot-zero release. PostgreSQL does its
best to put out only solid releases, and this one is no exception."

<snip>

What's wrong with actually accepting the SQL92 grammar, anyway?

?? That is what we are trying to do.

Your unrolling technique doesn't and can't accept the SQL92 grammar.
That should be obvious. You don't seriously intend to enumerate
all possible combinations of constraints and constraint attributes,
do you? It's the wrong way to go about it.

I'm not sure what your point is about "having to ship 6.5 instead of
7.0" for your porting project. If you aren't willing to cope with
small changes/features/breakage in a beta cycle you should stay away
from betas.

This is NOT a small change/breakage. I'm astonished that that the
removal of "unique not null" and "not null unique" would be considered
"small". Of course, other perfectly legal and previously accepted
constraints are rejected, too.

There is *no* reason you should think that the restriction on syntax
in this area is a permanent feature or something that will persist
through beta. If you are on such a tight schedule that you can't cope
with a 2 week slip in a feature, or a 2 week breakage from your PoV,
then beta isn't for you!!

In MHO delaying beta would've been better if a better solution couldn't
be lashed in, because this is a serious breakage.

Or, make more modest claims about the stability of betas. If release
notes and publicity made it clear that PG betas aren't expected to be
production, or near-production, quality then people like me wouldn't
hold this expectation.

otoh, if you are planning on shipping after the 7.0 release, then
there isn't a problem. And if you need a system which has *exactly*
the behaviors of a couple of weeks ago, then use a snapshot from a
couple of weeks ago. I'll prep and send you one if you would like.

I've got my own from three days before beta, thank you.

- 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 29 12:54:23 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 MAA90708
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 12:54:22 -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 JAA05847;
Tue, 29 Feb 2000 09:54:06 -0800 (PST)
Message-Id: <3.0.1.32.20000229095109.01d09950@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 29 Feb 2000 09:51:09 -0800
To: Peter Eisentraut <peter_e@gmx.net>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
Cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Jan Wieck <wieck@debis.com>,
Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
In-Reply-To: <Pine.GSO.4.02A.10002291728340.18993-100000@Rama.DoCS.UU.SE

References: <3.0.1.32.20000229063059.01d031c0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 05:37 PM 2/29/00 +0100, Peter Eisentraut wrote:

On Tue, 29 Feb 2000, Don Baccus wrote:

Because of this, the web toolkit I'm porting is going out with
6.5 only, rather than 6.5 or 7.0 beta with 7.0 beta recommended.
It's a pity, bugs and some of our hacks around missing features
in 6.5 make portions of the toolkit differ in their output than
the Oracle version. This hurts the credibility of the port,
to some degree, and simply adds ammunition to those who argue
that trying to do this kind of project on top of Postgres is
foolishness incarnate.

It's BETA. You're not supposed to use it in production work. Beta is a
feature freeze, then we try to sort out the bugs.

So is our web toolkit release. So is the AOLserver Version 3 that
we're using. We're putting out a beta suite, so to speak. I didn't
make that clear. Obviously we're not going to put out a production
version with all-beta componets.

"Don't be concerned this is a dot-zero release. PostgreSQL does its
best to put out only solid releases, and this one is no exception."

I'm now concerned. I wasn't Feb 18th.

Mind you, I made my recommendation that we use 7.0 beta after having
used it in my porting work for about a month, without problems. Just
as I've been using AOLserver version 3, also without problem.

So it's not like I blindly made a decision out of ignorance, I worked
with the upcoming beta in order to make an intellegent decision. As
of Feb 18th, the upcoming beta worked much better with our stuff
than 6.5, and that's the truth.

As far as I'm concerned it would hurt credibility of the port much more to
"recommend" a beta version of a database server as its backend.

Again, I didn't make it clear that our port is also a beta, and that
we're only encouraging that people experiment with it, not put up
production web sites, for the next couple of months at least. Sorry
for that confusion.

In that context, I feel comfortable with using tested components even
if they're beta.

Postgres benefits from that aggressiveness as the beta will get some
serious testing in this environment. AOLserver V3 beta won't benefit
to the same degree because it's so (ahem) solid that it's being used
on production web sites using the Oracle version of this toolkit.

...

we're not primarily
developing PostgreSQL to work with your toolkit.

I've never suggested that. Jose Soares (sp?) found the same bug
almost simultaneously. We're talking vanilla SQL92. I can use my
Feb 18th snapshot, and will if this doesn't get fixed quickly. My
concern's a lot more general.

I'm not being small-minded or selfish.

I actually did the unrolling of the worst cases last night, took
me about an hour with "Star Trek Voyager" on in the background
as a distraction from how ugly this hack is. Because, with all
due respect, Thomas, it is an exceedingly ugly hack. And you
can't unroll enough to capture the grammar anyway, it's like
trying to enumerate all possible expressions in the grammar
rather than parse the general form.

The difference is that the expression space is infinite, whereas unrolling
all column constraints should be on the order of a dozen or two.

Actually, the column constraint stuff is infinite, too - in the given
SQL92 grammar. Restrictions that exist are due to semantics. The
traditional means of dealing with this - pardon me for being a professional
compiler writer, I was born this way and can't help myself - is to
implement semantic restrictions via semantic analysis, not syntactic
kludges.

It sounds like Tom intends to take a whack at this approach. I'd
offer, but my time's tight at the moment.

- 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 29 13: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 NAA94616
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 13:14: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 NAA00149;
Tue, 29 Feb 2000 13:14:34 -0500 (EST)
To: Don Baccus <dhogaza@pacifier.com>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Jan Wieck <wieck@debis.com>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
In-reply-to: <3.0.1.32.20000229093333.01d0e720@mail.pacifier.com>
References: <m12PawP-0003kGC@orion.SAPserv.Hamburg.dsh.de>
<3.0.1.32.20000229063059.01d031c0@mail.pacifier.com>
<3.0.1.32.20000229093333.01d0e720@mail.pacifier.com>
Comments: In-reply-to Don Baccus <dhogaza@pacifier.com>
message dated "Tue, 29 Feb 2000 09:33:33 -0800"
Date: Tue, 29 Feb 2000 13:14:34 -0500
Message-ID: <146.951848074@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Don Baccus <dhogaza@pacifier.com> writes:

An alternative might be to remove the following sentence from the
release notes:
"Don't be concerned this is a dot-zero release. PostgreSQL does its
best to put out only solid releases, and this one is no exception."

Uh, Don, that's wording that we expect will apply to the 7.0 *release*.
We did not claim that the beta version has no known bugs.

[ much ranting snipped ]

Thomas made an engineering judgment that supporting beta-testing of all
the new foreign key features was more important than having a first beta
release with no regression in the parser. You can argue that he made
the wrong choice (I'm not sure if he did or not), but I don't think
jumping on him like this is appropriate.

regards, tom lane

From bouncefilter Tue Feb 29 13:28: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 NAA00370
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 13:27: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 NAA00242;
Tue, 29 Feb 2000 13:27:41 -0500 (EST)
To: Jose Soares <jose@sferacarta.com>
cc: hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] having and union in v7beta
In-reply-to: <38BB84B3.1209A0C7@sferacarta.com>
References: <38BA829F.C8BA2978@sferacarta.com> <25405.951750847@sss.pgh.pa.us>
<38BA998A.258E068C@sferacarta.com> <27055.951783375@sss.pgh.pa.us>
<38BB84B3.1209A0C7@sferacarta.com>
Comments: In-reply-to Jose Soares <jose@sferacarta.com>
message dated "Tue, 29 Feb 2000 09:34:59 +0100"
Date: Tue, 29 Feb 2000 13:27:41 -0500
Message-ID: <239.951848861@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Jose Soares <jose@sferacarta.com> writes:

But it's tough to believe that that accounts for a 3-to-4x
slowdown of this query; certainly I don't see much performance
difference on the datatypes I tried. What datatypes are your fields,
anyway?

6.5 takes 0.463s
7.0 takes 1.640s
the field type is CHAR(4)

Hmm. I see no more than a few percent difference between 6.5 and
current. There's something peculiar going on on your system.

Current code would ultimately invoke strncmp() on the two char fields,
whereas 6.5 used memcmp(). Is it possible that strncmp() is a huge
performance dog on your platform? I assume you are running in a
non-ASCII locale, which might reduce strncmp's performance, but still...

A quick-and-dirty way for you to check this would be to change the
strncmp call to call memcmp (just the one-word change should work)
in bpchareq() in src/backend/utils/adt/varchar.c, and see if that
changes the performance of this query materially.

regards, tom lane

From bouncefilter Tue Feb 29 13:35:24 2000
Received: from thelab.hub.org (nat196.115.mpoweredpc.net [142.177.196.115])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA01582
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 13:35:22 -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 OAA66120;
Tue, 29 Feb 2000 14:34:07 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 29 Feb 2000 14:34:07 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Don Baccus <dhogaza@pacifier.com>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Jan Wieck <wieck@debis.com>,
Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
In-Reply-To: <3.0.1.32.20000229093333.01d0e720@mail.pacifier.com>
Message-ID: <Pine.BSF.4.21.0002291430120.434-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Don, I'm tired of listening to you constantly berating ppl who are doing
*alot* of work to get PostgreSQL to a release state ... we are currently
in a *BETA* period, which means that we are trying *fix bugs* ... some of
those fixes will let other bugs creep in, and it is expected by those
playing with *non release level* software ...

IMHO, you should be on pgsql-general, not pgsql-hackers, as its obvious
that you need *release level* software ...

I've warned once before, as has Bruce ... this is the last one. If you
can't report bugs without being antagonistic about it, I will have to ask
you to leave -hackers and wait for the release to happen ...

As all our others once said: "if you can't say something nice, don't say
anything at all" ... and, quite frankly, silence from your end of the
world until the release is made would be appreciated by all ...

If, when we release, you are *still* having problems,please feel free to
let us know in a *NON* antagonistic way ...

On Tue, 29 Feb 2000, Don Baccus wrote:

At 04:39 PM 2/29/00 +0000, Thomas Lockhart wrote:

I did not claim to have the final form; I ran out of time before
heading out on vacation.

In retrospect, it shouldn't've gone into the beta at that point,
then. Crippling "unique not null" isn't merely an inconvenience.
Dropping a bomb like this into beta the night before release
and leaving town for nine days perhaps wasn't the best thing to
do. Perhaps we should avoid doing things like this in the future.

Lighten up Don! I put this in so Jan et al can get cracking on the
referential integrity stuff in the column specification, and imho the
feature and space of possible solutions is isolated and finite. Not a
big risk for the first part of beta.

No, I won't lighten up. I said "in retrospect", and I used those
words intentionally to suggest that IN THE FUTURE we might take
more care. What's the harm in learning from experience?

An alternative might be to remove the following sentence from the
release notes:

"Don't be concerned this is a dot-zero release. PostgreSQL does its
best to put out only solid releases, and this one is no exception."

<snip>

What's wrong with actually accepting the SQL92 grammar, anyway?

?? That is what we are trying to do.

Your unrolling technique doesn't and can't accept the SQL92 grammar.
That should be obvious. You don't seriously intend to enumerate
all possible combinations of constraints and constraint attributes,
do you? It's the wrong way to go about it.

I'm not sure what your point is about "having to ship 6.5 instead of
7.0" for your porting project. If you aren't willing to cope with
small changes/features/breakage in a beta cycle you should stay away
from betas.

This is NOT a small change/breakage. I'm astonished that that the
removal of "unique not null" and "not null unique" would be considered
"small". Of course, other perfectly legal and previously accepted
constraints are rejected, too.

There is *no* reason you should think that the restriction on syntax
in this area is a permanent feature or something that will persist
through beta. If you are on such a tight schedule that you can't cope
with a 2 week slip in a feature, or a 2 week breakage from your PoV,
then beta isn't for you!!

In MHO delaying beta would've been better if a better solution couldn't
be lashed in, because this is a serious breakage.

Or, make more modest claims about the stability of betas. If release
notes and publicity made it clear that PG betas aren't expected to be
production, or near-production, quality then people like me wouldn't
hold this expectation.

otoh, if you are planning on shipping after the 7.0 release, then
there isn't a problem. And if you need a system which has *exactly*
the behaviors of a couple of weeks ago, then use a snapshot from a
couple of weeks ago. I'll prep and send you one if you would like.

I've got my own from three days before beta, thank you.

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

************

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 29 13:55:23 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 NAA03963
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 13:55:12 -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 KAA01306;
Tue, 29 Feb 2000 10:55:02 -0800 (PST)
Message-Id: <3.0.1.32.20000229105106.01d0f4c0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 29 Feb 2000 10:51:06 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
Cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Jan Wieck <wieck@debis.com>,
pgsql-hackers@postgreSQL.org
In-Reply-To: <146.951848074@sss.pgh.pa.us>
References: <3.0.1.32.20000229093333.01d0e720@mail.pacifier.com>
<m12PawP-0003kGC@orion.SAPserv.Hamburg.dsh.de>
<3.0.1.32.20000229063059.01d031c0@mail.pacifier.com>
<3.0.1.32.20000229093333.01d0e720@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 01:14 PM 2/29/00 -0500, Tom Lane wrote:

Don Baccus <dhogaza@pacifier.com> writes:

An alternative might be to remove the following sentence from the
release notes:
"Don't be concerned this is a dot-zero release. PostgreSQL does its
best to put out only solid releases, and this one is no exception."

Uh, Don, that's wording that we expect will apply to the 7.0 *release*.
We did not claim that the beta version has no known bugs.

Hmmm...OK, I can see this. It's not clear, though, because you get
there from the main web page which is discussing the beta.

[ much ranting snipped ]

Thomas made an engineering judgment that supporting beta-testing of all
the new foreign key features was more important than having a first beta
release with no regression in the parser. You can argue that he made
the wrong choice (I'm not sure if he did or not), but I don't think
jumping on him like this is appropriate.

I said "in retrospect" and "in the future" ... I'm merely suggesting
that perhaps in the future we might be more conservative.

- 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 29 14:10:24 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 OAA05535
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 14:09: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 LAA06616;
Tue, 29 Feb 2000 11:09:04 -0800 (PST)
Message-Id: <3.0.1.32.20000229110622.00fbca00@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 29 Feb 2000 11:06:22 -0800
To: The Hermit Hacker <scrappy@hub.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
Cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Jan Wieck <wieck@debis.com>,
Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
In-Reply-To: <Pine.BSF.4.21.0002291430120.434-100000@thelab.hub.org>
References: <3.0.1.32.20000229093333.01d0e720@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 02:34 PM 2/29/00 -0400, The Hermit Hacker wrote:

IMHO, you should be on pgsql-general, not pgsql-hackers, as its obvious
that you need *release level* software ...

No problem, I'll unsubscribe.

If, when we release, you are *still* having problems,please feel free to
let us know in a *NON* antagonistic way ...

Save bug reports until release? OK, if that's what you want.

- 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 29 14:19:24 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 OAA06308
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 14:18:47 -0500 (EST) (envelope-from vev@michvhf.com)
Received: (qmail 9482 invoked by uid 1001); 29 Feb 2000 19:18:41 -0000
Message-ID: <XFMail.000229141841.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: <3.0.1.32.20000229105106.01d0f4c0@mail.pacifier.com>
Date: Tue, 29 Feb 2000 14:18:41 -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: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
Cc: pgsql-hackers@postgreSQL.org, Jan Wieck <wieck@debis.com>,
Thomas Lockhart <lockhart@alumni.caltech.edu>, Tom Lane <tgl@sss.pgh.pa.us>

On 29-Feb-00 Don Baccus wrote:

At 01:14 PM 2/29/00 -0500, Tom Lane wrote:

Don Baccus <dhogaza@pacifier.com> writes:

An alternative might be to remove the following sentence from the
release notes:
"Don't be concerned this is a dot-zero release. PostgreSQL does its
best to put out only solid releases, and this one is no exception."

Uh, Don, that's wording that we expect will apply to the 7.0 *release*.
We did not claim that the beta version has no known bugs.

Hmmm...OK, I can see this. It's not clear, though, because you get
there from the main web page which is discussing the beta.

With the key word here being "beta".

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 29 14:50: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 OAA14672
for <pgsql-hackers@postgresql.org>;
Tue, 29 Feb 2000 14:50:12 -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 OAA00517;
Tue, 29 Feb 2000 14:49:53 -0500 (EST)
To: Jose Soares <jose@sferacarta.com>
cc: hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] having and union in v7beta
In-reply-to: <38BB7E2F.C481BBC3@sferacarta.com>
References: <38BA829F.C8BA2978@sferacarta.com> <25405.951750847@sss.pgh.pa.us>
<38BB7E2F.C481BBC3@sferacarta.com>
Comments: In-reply-to Jose Soares <jose@sferacarta.com>
message dated "Tue, 29 Feb 2000 09:07:11 +0100"
Date: Tue, 29 Feb 2000 14:49:53 -0500
Message-ID: <514.951853793@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Jose Soares <jose@sferacarta.com> writes:

I tried the following query :

select * from comuni where nome in (
select nome from comuni group by nome having 1 < count(nome)
);

on the above table populated with 8342 rows, PostgreSQL begins searching
and I wait for hours without any result.

I'd expect that to be pretty slow, since it's going to execute the inner
select for every tuple examined by the outer select. Shouldn't be any
worse than 6.5 though. IN (sub-SELECT) has always been slow.

The real solution is to figure out how to do this kind of thing via
joins, but that will have to wait for the fabled querytree redesign.

I have been toying with the notion of sticking a MATERIALIZE node
into the plan tree when we have an IN sub-select and the sub-plan is
complicated, but has no parameters passed from the upper plan.
(Not sure yet how complicated is complicated enough, but a plan that
requires sorting or indexscanning should qualify.) The MATERIALIZE
node would run the sub-plan just once and stash the output tuples in
a temp table; then we'd only need a simple scan of the temp table for
each outer tuple. I think that would improve the speed of IN
sub-SELECTs by a useful amount in many cases, and it'd be a lot easier
than the "real" solution.

However, I'm not sure it's a good idea to do this when we've already
started beta. Should I try it, or leave it alone until 7.1? By 7.1
it might be moot...

regards, tom lane

From bouncefilter Tue Feb 29 15:06:24 2000
Received: from thelab.hub.org (nat196.115.mpoweredpc.net [142.177.196.115])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA16307
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 15:05: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 QAA66897;
Tue, 29 Feb 2000 16:05:24 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 29 Feb 2000 16:05:23 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Don Baccus <dhogaza@pacifier.com>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Jan Wieck <wieck@debis.com>,
Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
In-Reply-To: <3.0.1.32.20000229110622.00fbca00@mail.pacifier.com>
Message-ID: <Pine.BSF.4.21.0002291604380.434-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 29 Feb 2000, Don Baccus wrote:

At 02:34 PM 2/29/00 -0400, The Hermit Hacker wrote:

IMHO, you should be on pgsql-general, not pgsql-hackers, as its obvious
that you need *release level* software ...

No problem, I'll unsubscribe.

If, when we release, you are *still* having problems,please feel free to
let us know in a *NON* antagonistic way ...

Save bug reports until release? OK, if that's what you want.

No, bug reports are most welcome, antagonistic comments aren't ... big
difference ...

From bouncefilter Tue Feb 29 19:05:27 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 TAA54088
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 19:04:57 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m12PwRm-0003kgC; Wed, 1 Mar 100 00:52 MET
Message-Id: <m12PwRm-0003kgC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)
In-Reply-To: <3.0.1.32.20000229110622.00fbca00@mail.pacifier.com> from Don
Baccus at "Feb 29, 2000 11:06:22 am"
To: Don Baccus <dhogaza@pacifier.com>
Date: Wed, 1 Mar 2000 00:52:58 +0100 (CET)
CC: The Hermit Hacker <scrappy@hub.org>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
Jan Wieck <wieck@debis.com>, Tom Lane <tgl@sss.pgh.pa.us>,
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

At 02:34 PM 2/29/00 -0400, The Hermit Hacker wrote:

IMHO, you should be on pgsql-general, not pgsql-hackers, as its obvious
that you need *release level* software ...

No problem, I'll unsubscribe.

NO!

Your input and code-contribution to the FK project was far
too important. In fact, without you FK would have been
implemented fundamentally wrong. So I would miss you on
-hackers.

If, when we release, you are *still* having problems,please feel free to
let us know in a *NON* antagonistic way ...

Save bug reports until release? OK, if that's what you want.

It's not wat I want at least.

Back to the roots. Thomas, from my personal PoV, is a little
too much after "do it in the grammar if possible at all". But
he's the core member to take care about compliance and the
like. Hackers (like me) tend to let go with something that
works, but it's him to assure the parsers future is great,
wide open. Finally it's the mixture in the core team that
makes Postgres successful, so I'm happy with Thomas having a
sharp eye on it.

In the actual case, we need to see what can be done until 7.0
release. If we cannot produce a clean solution during the
next weeks, I'm sure that "backward compatibility" has the
higher weight than avoiding my crude hack into the parser
(it'll stay for one release only anyway).

What I suggest is, take it as it is. We use to have a
friendly and nice ground noise in our mailing lists. So this
kind of discussion, tending to become flame wars, should be
taken off list at least (IMHO avoided at all, but I'm farest
the last person to judge).

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Tue Feb 29 20:12:28 2000
Received: from thelab.hub.org (nat196.115.mpoweredpc.net [142.177.196.115])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA59039
for <pgsql-hackers@postgresql.org>;
Tue, 29 Feb 2000 20:11:47 -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 VAA01104
for <pgsql-hackers@postgresql.org>;
Tue, 29 Feb 2000 21:11:45 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 29 Feb 2000 21:11:45 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: Bug report for 7.0beta1 in 'CREATE FUNCTION...'
Message-ID: <Pine.BSF.4.21.0002292110250.434-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Can someone look into this, and followup with Don? :)

====================
From: Don Baccus <dhogaza@pacifier.com>

Slightly less minor bug. Forward this to the right place, too.

acs=# create function foo() returns integer as '
acs'# begin
acs'# create table bar(i integer);
acs'# return 1;
acs'# end;' language 'plpgsql';
CREATE
acs=# select foo();
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!#

DML statements apparently aren't meant to be supported in plpgsql,
since any I try crash. This, again, is PG7.0 beta.
=====================

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 29 20:14:28 2000
Received: from thelab.hub.org (nat196.115.mpoweredpc.net [142.177.196.115])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA59210
for <pgsql-hackers@postgresql.org>;
Tue, 29 Feb 2000 20:14:02 -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 VAA01152
for <pgsql-hackers@postgresql.org>;
Tue, 29 Feb 2000 21:14:01 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 29 Feb 2000 21:14:01 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: minor bug in 7.0: casting
Message-ID: <Pine.BSF.4.21.0002292112200.434-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Another one here ...

=============
From: Don Baccus <dhogaza@pacifier.com>

At 04:05 PM 2/29/00 -0400, you wrote:

No, bug reports are most welcome, antagonistic comments aren't ... big
difference ...

donb=# create table foo(c char(2), v varchar(2));
CREATE
donb=# select * from foo where c::varchar = v::varchar;
ERROR: Unable to identify an operator '=' for types 'bpchar' and 'varchar'
You will have to retype this query using an explicit cast
donb=# select * from foo where cast(c as varchar) = cast(v as varchar);
ERROR: Unable to identify an operator '=' for types 'bpchar' and 'varchar'
You will have to retype this query using an explicit cast
donb=# select * from foo where cast(c as text) = cast(v as text);
ERROR: Unable to identify an operator '=' for types 'bpchar' and 'varchar'
You will have to retype this query using an explicit cast

If conversion isn't going to be supported, the error message should
be improved (feel free to forward this to the appropriate person).

In this case, the working application actually fills both variables
(in practice, from different tables) with two-character state codes,
so the cast would work. Should casts presume the user doesn't know
what they're doing? I don't know. I can fix this, of course, by
changing the data model I've inherited from Oracle to consistently
use either char(2) or varchar(2).

- 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 29 20:30:28 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 UAA60814
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 20:29:46 -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 KAA04750; Wed, 01 Mar 2000 10:28:42 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Karel Zak - Zakkr" <zakkr@zf.jcu.cz>
Cc: "Peter Eisentraut" <peter_e@gmx.net>, "Jan Wieck" <wieck@debis.com>,
"Tom Lane" <tgl@sss.pgh.pa.us>,
"pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Cache query implemented
Date: Wed, 1 Mar 2000 10:35:04 +0900
Message-ID: <000501bf831e$5ea9b120$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <Pine.LNX.3.96.1000229133620.6155A-100000@ara.zf.jcu.cz>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal

-----Original Message-----
From: Karel Zak - Zakkr [mailto:zakkr@zf.jcu.cz]

On Tue, 29 Feb 2000, Hiroshi Inoue wrote:

-----Original Message-----
From: Karel Zak - Zakkr [mailto:zakkr@zf.jcu.cz]

EXECUTE name [ INTO x, y, ... ] [ USING a, b, ... ]

This command "Associate input parametrs and output targets

with a prepared

statement and execute the statement" (SQL92).

I don't know well about PREPARE statement.
But is above syntax for interative SQL command ?
Isn't it for embedded SQL or SQL module ?

- PREPARE save to cache any standard sql command (OptimizableStmt).
- EXECUTE run this cached plan (query) and send data to frontend or
INTO any relation.

Or what you mean?

In old Oracle(I don't know recent Oracle,sorry),PREPARE couldn't be called
as an interactive SQL command. It was used only in embedded SQL.

Seems x, y after INTO are output variables. In embedded SQL they are
host variables. But I don't know what they are in interactive SQL.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Tue Feb 29 21:32:34 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 VAA63271
for <pgsql-hackers@postgresql.org>;
Tue, 29 Feb 2000 21:30:48 -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 KAA04764; Wed, 01 Mar 2000 10:59:33 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "The Hermit Hacker" <scrappy@hub.org>
Cc: <pgsql-hackers@postgresql.org>
Subject: RE: [HACKERS] Bug report for 7.0beta1 in 'CREATE FUNCTION...'
Date: Wed, 1 Mar 2000 11:05:56 +0900
Message-ID: <000601bf8322$adff9c40$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <Pine.BSF.4.21.0002292110250.434-100000@thelab.hub.org>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal

-----Original Message-----
From: owner-pgsql-hackers@postgresql.org
[mailto:owner-pgsql-hackers@postgresql.org]On Behalf Of The Hermit
Hacker

Can someone look into this, and followup with Don? :)

Currently utility commands aren't executable in PL/pgSQL.
In short,it's due the lack of implementation of copyObject()
for UtilityStatements.
However,there's another essential problem.

PL/pgSQL caches prepared plans for fucntions at their
first execution time. Though many oids/numbers ... exist
in the cached plans,they are changed by DML statements
and cached plans would become invalid. Currently once
a plan is cached,it stays in TopMemoryContext forever
and would never be removed/changed.

Jan could give more precise comments on this topic.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

====================
From: Don Baccus <dhogaza@pacifier.com>

Slightly less minor bug. Forward this to the right place, too.

acs=# create function foo() returns integer as '
acs'# begin
acs'# create table bar(i integer);
acs'# return 1;
acs'# end;' language 'plpgsql';
CREATE
acs=# select foo();
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!#

DML statements apparently aren't meant to be supported in plpgsql,
since any I try crash. This, again, is PG7.0 beta.
=====================

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 29 22:14:29 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 WAA64920
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 22:13:32 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA10300;
Tue, 29 Feb 2000 21:42:00 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200003010242.VAA10300@candle.pha.pa.us>
Subject: Re: [HACKERS] Bug report for 7.0beta1 in 'CREATE FUNCTION...'
In-Reply-To: <000601bf8322$adff9c40$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Mar 1, 2000 11:05:56 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Tue, 29 Feb 2000 21:42:00 -0500 (EST)
CC: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset iso-8859-1 unsupported, filtering to ASCII...]

-----Original Message-----
From: owner-pgsql-hackers@postgresql.org
[mailto:owner-pgsql-hackers@postgresql.org]On Behalf Of The Hermit
Hacker

Can someone look into this, and followup with Don? :)

Currently utility commands aren't executable in PL/pgSQL.
In short,it's due the lack of implementation of copyObject()
for UtilityStatements.
However,there's another essential problem.

Removed from HISTORY file:

-Allow utility statements in plpgsql (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 19026

From bouncefilter Tue Feb 29 22:18:29 2000
Received: from thelab.hub.org (nat196.115.mpoweredpc.net [142.177.196.115])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA65127
for <pgsql-hackers@postgresql.org>;
Tue, 29 Feb 2000 22:17:37 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id XAA01867
for <pgsql-hackers@postgresql.org>;
Tue, 29 Feb 2000 23:17:37 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 29 Feb 2000 23:17:37 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: select exists (select oid from users)
Message-ID: <Pine.BSF.4.21.0002292316110.434-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

==============================
From: Don Baccus <dhogaza@pacifier.com>

The query "select exists (select oid from users)" is very
non-standard and I'm surprised it works. I can accept that
some very weird queries might mess up PL/pgSQL, but it would
be nice if the backend wouldn't crash.

Again, PG7.0 beta (actually, a snapshot taken four days earlier,
I've given up on the official beta for the time being)

acs=# select exists (select oid from users);
?column?
----------
t
(1 row)

acs=# create function foo(integer) returns boolean as '
acs'# begin
acs'# return exists (select oid from users);
acs'# end;' language 'plpgsql';
CREATE
acs=# select foo(3);
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!# \q
[acs@gyrfalcon acs]$ psql
Welcome to psql, the PostgreSQL interactive terminal.
...
acs=# create function bar(integer) returns boolean as '
acs'# begin
acs'# return ''t'' where exists (select oid from users);
acs'# end;' language 'plpgsql';
CREATE
acs=# select bar(3);
bar
-----
t
(1 row)

- 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 29 23:17:30 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 XAA70460;
Tue, 29 Feb 2000 23:17:02 -0500 (EST)
(envelope-from csawtell@xtra.co.nz)
Received: from berty.localnet ([210.55.86.67]) by mta1-rme.xtra.co.nz
(InterMail v4.01.01.00 201-229-111) with ESMTP
id <20000301041626.PPMW13182477.mta1-rme@berty.localnet>;
Wed, 1 Mar 2000 17:16:26 +1300
Received: from berty (berty.localnet [192.168.1.1])
by berty.localnet (Postfix) with SMTP
id 28AB55E68; Wed, 1 Mar 2000 16:29:59 +1300 (NZDT)
From: Christopher Sawtell <csawtell@xtra.co.nz>
Organization: iOpen Technologies Ltd.
To: Tom Lane <tgl@sss.pgh.pa.us>, Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: [SQL] prob with aggregate and group by - returns
multiplesh
Date: Wed, 1 Mar 2000 16:26:24 +1300
X-Mailer: KMail [version 1.0.17]
Content-Type: text/plain
Cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Bruce Momjian <pgman@candle.pha.pa.us>,
"'pgsql-sql@postgresql.org'" <pgsql-sql@postgreSQL.org>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
References: <29204.951840577@sss.pgh.pa.us>
MIME-Version: 1.0
Message-Id: <00030116295801.01591@berty>
Content-Transfer-Encoding: 8bit
X-KMail-Mark:

On Wed, 01 Mar 2000, Tom Lane wrote:

Don Baccus <dhogaza@pacifier.com> writes:

I vote for the SQL92 TEMPORARY. Let's not add a keyword that is non-standard
just because one or another commercial database makes use of it,

You're missing the point: we are not talking about *adding* a keyword,
we're talking about *removing* one that we've already supported for
a year or so. That changes matters considerably, IMHO.

I have in fact been able to make a conflict-free grammar in which TEMP
is accepted but not reserved. It requires a certain amount of
redundancy in the productions (see below), but I think this is a
worthwhile tradeoff for not breaking existing user code.

Shall I commit this?

Is there not also the possibility of making this a configure-time option?

./configure --temporary-table=TEMPORARY # or TEMP as you wish

Default to TEMPORARY in accord with SQL 92.

--
Sincerely etc.,

NAME Christopher Sawtell - Support Engineer - iOpen Technologies Ltd.
CELL PHONE 021 257 4451
ICQ UIN 45863470
EMAIL chris @ iopen . co . nz, csawtell @ xtra . co . nz
CNOTES ftp://ftp.funet.fi/pub/languages/C/tutorials/sawtell_C.tar.gz

---->>> Please refrain from using HTML attachments in e-mails to me. <<<----

From bouncefilter Tue Feb 29 23:03:30 2000
Received: from thelab.hub.org (nat196.115.mpoweredpc.net [142.177.196.115])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA68315;
Tue, 29 Feb 2000 23:02:44 -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 AAA02342;
Wed, 1 Mar 2000 00:02:44 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 1 Mar 2000 00:02:44 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
cc: pgsql-announce@postgresql.org, pgsql-general@postgresql.org
Subject: Poll: Databases for Linux
Message-ID: <Pine.BSF.4.21.0003010000390.434-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

As Jeff mentioned earlier today, there is a poll going on at
http://www.linux.com that asks:

Several high-quality databases are available for Linux. Which database,
if any, does your company primarily use with its Linux servers?

Right now, PostgreSQL is lagging MySQL 21% to 48% ...

Who hasn't voted? :) Get out there and make yourself heard, eh?

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 29 23:21:33 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA71150
for <pgsql-hackers@postgreSQL.org>;
Tue, 29 Feb 2000 23:20:41 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
XAA14238;
Tue, 29 Feb 2000 23:20:17 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200003010420.XAA14238@candle.pha.pa.us>
Subject: Re: [HACKERS] Poll: Databases for Linux
In-Reply-To: <Pine.BSF.4.21.0003010000390.434-100000@thelab.hub.org> from The
Hermit Hacker at "Mar 1, 2000 00:02:44 am"
To: The Hermit Hacker <scrappy@hub.org>
Date: Tue, 29 Feb 2000 23:20:17 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

As Jeff mentioned earlier today, there is a poll going on at
http://www.linux.com that asks:

Several high-quality databases are available for Linux. Which database,
if any, does your company primarily use with its Linux servers?

Right now, PostgreSQL is lagging MySQL 21% to 48% ...

Who hasn't voted? :) Get out there and make yourself heard, eh?

Reading the web page recent comments, MySQL is getting blasted for lack
of features. Glad to see it. I think we have them on the run. They
are not advancing at the same speed as PostgreSQL, so it is only a
matter of time.

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

From bouncefilter Wed Mar 1 00:42:31 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA78214
for <pgsql-hackers@postgresql.org>; Wed, 1 Mar 2000 00:42: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 AAA29799;
Wed, 1 Mar 2000 00:42:14 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgresql.org, Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] minor bug in 7.0: casting
In-reply-to: <Pine.BSF.4.21.0002292112200.434-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0002292112200.434-100000@thelab.hub.org>
Comments: In-reply-to The Hermit Hacker <scrappy@hub.org>
message dated "Tue, 29 Feb 2000 21:14:01 -0400"
Date: Wed, 01 Mar 2000 00:42:14 -0500
Message-ID: <29796.951889334@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

The Hermit Hacker <scrappy@hub.org> writes:

Another one here ...

From: Don Baccus <dhogaza@pacifier.com>
donb=# create table foo(c char(2), v varchar(2));
CREATE
donb=# select * from foo where c::varchar = v::varchar;
ERROR: Unable to identify an operator '=' for types 'bpchar' and 'varchar'
You will have to retype this query using an explicit cast

As of current sources:

regression=# create table foo(c char(2), v varchar(2));
CREATE
regression=# select * from foo where c::varchar = v::varchar;
c | v
---+---
(0 rows)

I thought I fixed that before 7.0beta1, but am not feeling eager to
rummage through cvs logs to prove it.

regards, tom lane

From bouncefilter Wed Mar 1 00:50:31 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 AAA78677
for <pgsql-hackers@postgreSQL.org>; Wed, 1 Mar 2000 00:50:26 -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 OAA04861; Wed, 01 Mar 2000 14:50:20 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "The Hermit Hacker" <scrappy@hub.org>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Bug report for 7.0beta1 in 'CREATE FUNCTION...'
Date: Wed, 1 Mar 2000 14:56:43 +0900
Message-ID: <000701bf8342$ebc500e0$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: <000601bf8322$adff9c40$2801007e@tpf.co.jp>
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 Hiroshi Inoue
Sent: Wednesday, March 01, 2000 11:06 AM
To: The Hermit Hacker
Cc: pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] Bug report for 7.0beta1 in 'CREATE FUNCTION...'

-----Original Message-----
From: owner-pgsql-hackers@postgresql.org
[mailto:owner-pgsql-hackers@postgresql.org]On Behalf Of The Hermit
Hacker

Can someone look into this, and followup with Don? :)

Currently utility commands aren't executable in PL/pgSQL.
In short,it's due the lack of implementation of copyObject()
for UtilityStatements.
However,there's another essential problem.

PL/pgSQL caches prepared plans for fucntions at their
first execution time. Though many oids/numbers ... exist
in the cached plans,they are changed by DML statements

^^^^^^^^^^^^^
Oops sorry,DDL not DML statement.

and cached plans would become invalid. Currently once
a plan is cached,it stays in TopMemoryContext forever
and would never be removed/changed.

From bouncefilter Wed Mar 1 01:04:31 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 BAA79391;
Wed, 1 Mar 2000 01:04:17 -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 GAA13247;
Wed, 1 Mar 2000 06:14:51 GMT
Sender: lockhart@hub.org
Message-ID: <38BCB55B.AC175BB9@alumni.caltech.edu>
Date: Wed, 01 Mar 2000 06:14:51 +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>,
"'pgsql-sql@postgresql.org'" <pgsql-sql@postgreSQL.org>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [SQL] prob with aggregate and group by - returns
multiplesh
References: <200002291719.MAA26261@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

So are we willing to field questions from people trying to use TEMP
tables and trying TEMP and not TEMPORARY. I realize the restriction on
a field called TEMP, but we don't get those very often. How many people
are going to guess TEMP and not TEMPORARY?

Well, that's one reason to stick to a published standard. No guessing
required since one could look it up ;)

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Wed Mar 1 01:30:35 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA80871;
Wed, 1 Mar 2000 01:30:25 -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
BAA18585;
Wed, 1 Mar 2000 01:18:41 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200003010618.BAA18585@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [SQL] prob with aggregate and group by - returns
multiplesh
In-Reply-To: <38BCB55B.AC175BB9@alumni.caltech.edu> from Thomas Lockhart at
"Mar 1, 2000 06:14:51 am"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Wed, 1 Mar 2000 01:18:41 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>,
"'pgsql-sql@postgresql.org'" <pgsql-sql@postgreSQL.org>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

So are we willing to field questions from people trying to use TEMP
tables and trying TEMP and not TEMPORARY. I realize the restriction on
a field called TEMP, but we don't get those very often. How many people
are going to guess TEMP and not TEMPORARY?

Well, that's one reason to stick to a published standard. No guessing
required since one could look it up ;)

If you survive reading the standard. :-)

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

From bouncefilter Wed Mar 1 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 BAA80869;
Wed, 1 Mar 2000 01:30:22 -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 BAA00152;
Wed, 1 Mar 2000 01:29:25 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
"'pgsql-sql@postgresql.org'" <pgsql-sql@postgreSQL.org>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [SQL] prob with aggregate and group by - returns
multiplesh
In-reply-to: <38BCB55B.AC175BB9@alumni.caltech.edu>
References: <200002291719.MAA26261@candle.pha.pa.us>
<38BCB55B.AC175BB9@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Wed, 01 Mar 2000 06:14:51 +0000"
Date: Wed, 01 Mar 2000 01:29:25 -0500
Message-ID: <149.951892165@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

So are we willing to field questions from people trying to use TEMP
tables and trying TEMP and not TEMPORARY. I realize the restriction on
a field called TEMP, but we don't get those very often. How many people
are going to guess TEMP and not TEMPORARY?

Well, that's one reason to stick to a published standard. No guessing
required since one could look it up ;)

As of an hour ago, neither one is a reserved word ;-)

regards, tom lane

From bouncefilter Wed Mar 1 01:36:35 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA81415;
Wed, 1 Mar 2000 01:35:49 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id GAA13295;
Wed, 1 Mar 2000 06:46:28 GMT
Sender: lockhart@hub.org
Message-ID: <38BCBCC4.341E1BB8@alumni.caltech.edu>
Date: Wed, 01 Mar 2000 06:46:28 +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>,
"'pgsql-sql@postgresql.org'" <pgsql-sql@postgreSQL.org>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [SQL] prob with aggregate and group by - returns
multiplesh
References: <200002291719.MAA26261@candle.pha.pa.us>
<38BCB55B.AC175BB9@alumni.caltech.edu>
<149.951892165@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

As of an hour ago, neither one is a reserved word ;-)

Darn, I was just warming up to a good argument :))

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Wed Mar 1 01:41:35 2000
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA81885
for <pgsql-hackers@postgreSQL.org>; Wed, 1 Mar 2000 01:40: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 GAA13307;
Wed, 1 Mar 2000 06:50:45 GMT
Sender: lockhart@hub.org
Message-ID: <38BCBDC5.AE7EA486@alumni.caltech.edu>
Date: Wed, 01 Mar 2000 06:50: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: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <pgman@candle.pha.pa.us>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
References: <Pine.LNX.4.21.0002282300410.3511-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

(sorry for the delay in responding...)

You can define user types with spaces in them (note to self: better check
this), so I don't see why we should hack around it. What do you plan on
doing with DOUBLE PRECISION and TIME WITH TIMEZONE?

DOUBLE PRECISION is already supported, and becomes float8. TIME WITH
TIMEZONE is currently transparently swallowed to become equivalent to
TIME, for reasons spelled out in the docs. I've toyed with the idea of
implementing the SQL92 version of it, but it is *so* useless and brain
damaged (cf Date et al) that I (at least so far) cannot bring myself
to do so. But if and when, it might be ztime internally.

It is unlikely that we can transparently parse two-word types in
gram.y without explicit support for it. Just adding IDENT IDENT to
simple types leads to a shift/reduce conflict.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Wed Mar 1 01: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 BAA83972
for <pgsql-hackers@postgreSQL.org>; Wed, 1 Mar 2000 01:54: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 BAA00263;
Wed, 1 Mar 2000 01:53:37 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Peter Eisentraut <peter_e@gmx.net>,
Bruce Momjian <pgman@candle.pha.pa.us>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
In-reply-to: <38BCBDC5.AE7EA486@alumni.caltech.edu>
References: <Pine.LNX.4.21.0002282300410.3511-100000@localhost.localdomain>
<38BCBDC5.AE7EA486@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Wed, 01 Mar 2000 06:50:45 +0000"
Date: Wed, 01 Mar 2000 01:53:37 -0500
Message-ID: <260.951893617@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

It is unlikely that we can transparently parse two-word types in
gram.y without explicit support for it. Just adding IDENT IDENT to
simple types leads to a shift/reduce conflict.

Right. I think what Peter is actually suggesting is that BIT VARYING
(which must be special-cased in gram.y) could be equivalent to
"bit varying" (as a quoted identifier, that works already in most
places, and arguably should work everywhere). There's a certain amount
of intellectual cleanliness in that. OTOH, it's not apparent that it's
really any *better* than `varbit' or your choice of other space-free
internal names.

If SQL92 were a moving target then I'd be concerned about having to
track the special cases in a lot of bits of code ... but it's not
a moving target.

regards, tom lane

From bouncefilter Wed Mar 1 02:33:37 2000
Received: from feivel.fam-meskes.de (h-62.96.141.196.host.de.colt.net
[62.96.141.196]) by hub.org (8.9.3/8.9.3) with ESMTP id CAA86209
for <pgsql-hackers@postgreSQL.org>; Wed, 1 Mar 2000 02:32:39 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id 823C02BB62; Wed, 1 Mar 2000 08:27:21 +0100 (CET)
Date: Wed, 1 Mar 2000 08:27:21 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Compile woes
Message-ID: <20000301082721.A8135@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
References: <20000225090353.A9494@fam-meskes.de>
<15842.951634672@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <15842.951634672@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Sun, Feb 27, 2000 at 01:57:52AM -0500
Sender: michael@fam-meskes.de

On Sun, Feb 27, 2000 at 01:57:52AM -0500, Tom Lane wrote:

Michael, did you solve this yet? My guess is you need a new 'make depend'.

make depend does not run through since ecpg/preproc/Makefile does not know
depend. But it works on the backend directories. Then again it does not
change anything.

What did work, however, is manually removing all files named 'depend'.
Shouldn't this be done by a 'make distclean'?

Interestingly enough running 'make depend' now that the old depend files are
removed creates the correct ones.

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 Mar 1 04:21:43 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 EAA94946;
Wed, 1 Mar 2000 04:20:52 -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 12Q5J5-0002Rt-00; Wed, 1 Mar 2000 12:20:35 +0300
Date: Wed, 1 Mar 2000 09:20:35 +0000 (GMT)
From: Oleg Broytmann <phd@phd.russ.ru>
X-Sender: phd@fep132.fep.ru
Reply-To: phd2@earthling.net
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgresql.org, pgsql-announce@postgresql.org,
pgsql-general@postgresql.org
Subject: Re: [HACKERS] Poll: Databases for Linux
In-Reply-To: <Pine.BSF.4.21.0003010000390.434-100000@thelab.hub.org>
Message-ID: <Pine.LNX.4.21.0003010918220.9371-100000@fep132.fep.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 1 Mar 2000, The Hermit Hacker wrote:

As Jeff mentioned earlier today, there is a poll going on at
http://www.linux.com that asks:

Several high-quality databases are available for Linux. Which database,
if any, does your company primarily use with its Linux servers?

Right now, PostgreSQL is lagging MySQL 21% to 48% ...

Who hasn't voted? :) Get out there and make yourself heard, eh?

Yesterday I spent a few minutes trying to choose the DB to vote for. I
am using both Postgres and MySQL - different tasks require different
aproaches and solutions - and I am satisfied with both DBs. There are
niches for both of them.
Finally I voted for Postgres - just because MySQL already has its votes :)

Oleg.
----
Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net
Programmers don't die, they just GOSUB without RETURN.

From bouncefilter Wed Mar 1 04:35:38 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 EAA96151
for <pgsql-hackers@postgreSQL.org>; Wed, 1 Mar 2000 04:35:21 -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 KAA31355;
Wed, 1 Mar 2000 10:33:18 +0100
Date: Wed, 1 Mar 2000 10:33:18 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Hiroshi Inoue <Inoue@tpf.co.jp>
cc: Peter Eisentraut <peter_e@gmx.net>, Jan Wieck <wieck@debis.com>,
Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Cache query implemented
In-Reply-To: <000501bf831e$5ea9b120$2801007e@tpf.co.jp>
Message-ID: <Pine.LNX.3.96.1000301102408.29986A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 1 Mar 2000, Hiroshi Inoue wrote:

-----Original Message-----
From: Karel Zak - Zakkr [mailto:zakkr@zf.jcu.cz]

On Tue, 29 Feb 2000, Hiroshi Inoue wrote:

-----Original Message-----
From: Karel Zak - Zakkr [mailto:zakkr@zf.jcu.cz]

EXECUTE name [ INTO x, y, ... ] [ USING a, b, ... ]

This command "Associate input parametrs and output targets

with a prepared

statement and execute the statement" (SQL92).

I don't know well about PREPARE statement.
But is above syntax for interative SQL command ?
Isn't it for embedded SQL or SQL module ?

- PREPARE save to cache any standard sql command (OptimizableStmt).
- EXECUTE run this cached plan (query) and send data to frontend or
INTO any relation.

Or what you mean?

In old Oracle(I don't know recent Oracle,sorry),PREPARE couldn't be called
as an interactive SQL command. It was used only in embedded SQL.

Oh, yes I understand you now. No, prepare is a standard command
(interactive) (IMO).

Seems x, y after INTO are output variables. In embedded SQL they are
host variables. But I don't know what they are in interactive SQL.

A INTO is same as (example) SELECT ..INTO, see:

PREPARE myplan AS SELECT * FROM tab;
EXECUTE myplan INTO newtab;

A INTO only remove query destination for cached plan.

...it is in my implementation. I don't no how it is in any others SQLs.
In my Oracle8's tutorial it isn't.

Karel