Re: Approved

Please see the attached file for details.

From pgsql-hackers-owner@postgresql.org Tue Aug 19 18:48:52 2003

X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [64.117.224.130])
by svr1.postgresql.org (Postfix) with ESMTP id AEC42D1D1A5
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>; Tue, 19 Aug 2003 18:22:04 -0300 (ADT)
Received: from svr1.postgresql.org ([64.117.224.193])
by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024)
with ESMTP id 78871-06
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
Tue, 19 Aug 2003 18:21:56 -0300 (ADT)
Received: from www.postgresql.com (unknown [64.117.225.209])
by svr1.postgresql.org (Postfix) with ESMTP id 15897D1D198
for <pgsql-hackers@postgresql.org>; Tue, 19 Aug 2003 18:21:54 -0300 (ADT)
Received: from TOMEK (www.abg.com.pl [195.94.196.142])
by www.postgresql.com (Postfix) with ESMTP id CA880CF4945
for <pgsql-hackers@postgresql.org>; Tue, 19 Aug 2003 18:20:31 -0300 (ADT)
From: <ler@lerctr.org>
To: <pgsql-hackers@postgresql.org>
Subject: Re: Your application
Date: Tue, 19 Aug 2003 23:22:18 +0200
X-MailScanner: Found to be clean
Importance: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MSMail-Priority: Normal
X-Priority: 3 (Normal)
MIME-Version: 1.0
Message-Id: <20030819212031.CA880CF4945@www.postgresql.com>
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Spam-Status: No, hits=3.6 tagged_above=0.0 required=5.0
tests=FORGED_MUA_OUTLOOK, MIME_BOUND_NEXTPART, MISSING_MIMEOLE, NO_REAL_NAME
X-Spam-Level: ***
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset="iso-8859-1"
X-Archive-Number: 200308/917
X-Sequence-Number: 42574

See the attached file for details

From pgsql-hackers-owner@postgresql.org Tue Aug 19 18:48:58 2003

X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [64.117.224.130])
by svr1.postgresql.org (Postfix) with ESMTP id 8532CD1D189
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>; Tue, 19 Aug 2003 18:18:40 -0300 (ADT)
Received: from svr1.postgresql.org ([64.117.224.193])
by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024)
with ESMTP id 78871-05
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
Tue, 19 Aug 2003 18:18:31 -0300 (ADT)
Received: from filer (12-234-86-219.client.attbi.com [12.234.86.219])
by svr1.postgresql.org (Postfix) with ESMTP id 9AD4CD1D18E
for <pgsql-hackers@postgresql.org>; Tue, 19 Aug 2003 18:18:28 -0300 (ADT)
Received: from localhost (localhost [127.0.0.1])
(uid 1000)
by filer with local; Tue, 19 Aug 2003 14:18:30 -0700
Date: Tue, 19 Aug 2003 14:18:30 -0700
From: Kevin Brown <kevin@sysexperts.com>
To: Hackers <pgsql-hackers@postgresql.org>
Subject: Re: set constraints docs page
Message-ID: <20030819211830.GK16911@filer>
Mail-Followup-To: Kevin Brown <kevin@sysexperts.com>,
Hackers <pgsql-hackers@postgresql.org>
References: <20030813081405.T48694-100000@megazone.bigpanda.com> <Pine.LNX.4.56.0308190932380.4847@krusty.localdomain> <064701c36625$c8f701c0$2800a8c0@mars> <Pine.LNX.4.56.0308190949220.4847@krusty.localdomain> <005201c3664a$9518f640$6401a8c0@DUNSLANE> <28221.1061300815@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <28221.1061300815@sss.pgh.pa.us>
Organization: Frobozzco International
User-Agent: Mutt/1.5.4i
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Archive-Number: 200308/918
X-Sequence-Number: 42575

Tom Lane wrote:

"Andrew Dunstan" <andrew@dunslane.net> writes:

I object to creating gratuitous incompatibilities with the SQL standard,
which will obstruct legitimate features down the road. The SQL standard
says it is <schema>.<constraint>.

Is there a case for enforcing uniqueness on constraint names, then?

Other than "SQL92 says so"? Very little. This seems to me to be a
design error in the spec. Per-table constraint names are easier to
work with --- if they're global across a schema then you have a serious
problem avoiding collisions.

I assume that SQL99 and later don't specify anything different than what
SQL92 calls for in this regard?

Without any meaningful guidance from the spec, the best we can do is
support per-table constraint names and provide optional (via a GUC
variable) support for SQL92-compliant constraint names. Let the DBA
decide which (if not both) is best for his situation. Inasmuch as
one of our "selling points" is our compliance with the SQL spec, I see
little reason to entirely avoid compliance with the spec on this issue --
just make it possible to do something else when/if necessary.

The two approaches aren't necessarily mutually exclusive (though SQL99
compliance on constraint names would obviously make it unnecessary to
specify a tablename along with a constraint name), so I see little
problem here. But the current arrangement is obviously untenable,
because it allows you to create a situation (multiple constraints by
the same name) that you can't reasonably extricate yourself from.

--
Kevin Brown kevin@sysexperts.com