X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id D96635E46D5
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Tue, 17 Aug 2004 12:38:17 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 31721-04
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Tue, 17 Aug 2004 15:38:22 +0000 (GMT)
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by svr1.postgresql.org (Postfix) with ESMTP id D17B25E46D3
	for <pgsql-sql@postgresql.org>; Tue, 17 Aug 2004 12:38:14 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.12.11/8.12.11) with ESMTP id i7HFcF5c004877;
	Tue, 17 Aug 2004 11:38:15 -0400 (EDT)
To: Stephan Szabo <sszabo@megazone.bigpanda.com>
Cc: Markus Bertheau <twanger@bluetwanger.de>,
	Richard Huxton <dev@archonet.com>, pgsql-sql@postgresql.org
Subject: Re: multi column foreign key for implicitly unique columns 
In-reply-to: <20040817081306.J61699@megazone.bigpanda.com> 
References: <1092734724.2627.4.camel@dicaprio.akademie1.de>
	<4121D55D.1040105@archonet.com>
	<20040817072443.S60684@megazone.bigpanda.com>
	<4307.1092753995@sss.pgh.pa.us>
	<1092754658.2627.32.camel@dicaprio.akademie1.de>
	<20040817080425.U61699@megazone.bigpanda.com>
	<1092755530.2627.36.camel@dicaprio.akademie1.de>
	<20040817081306.J61699@megazone.bigpanda.com>
Comments: In-reply-to Stephan Szabo <sszabo@megazone.bigpanda.com>
	message dated "Tue, 17 Aug 2004 08:24:18 -0700"
Date: Tue, 17 Aug 2004 11:38:14 -0400
Message-ID: <4876.1092757094@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests=
X-Spam-Level: 
X-Archive-Number: 200408/175
X-Sequence-Number: 18672

Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> ... It sounds like it'd be a pain at best.

Also, that would directly violate the SQL spec's model of dependencies,
with possibly unpleasant consequences.  The current implementation does
exactly what SQL says to do.  I cite from SQL99 11.99 DROP CONSTRAINT:

         3) If TC is a unique constraint and RC is a referential constraint
            whose referenced table is T and whose referenced columns are the
            unique columns of TC, then RC is said to be dependent on TC.

         ...

         6) If RESTRICT is specified, then:

            a) No table constraint shall be dependent on TC.

            NOTE 195 - If CASCADE is specified, then any such dependent
            object will be dropped by the effective execution of the
            <alter table statement> specified in the General Rules of this
            Subclause.

			regards, tom lane