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 2082F5E46D4 for ; Wed, 18 Aug 2004 11:38:44 -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 98956-07 for ; Wed, 18 Aug 2004 14:38:41 +0000 (GMT) Received: from megazone.bigpanda.com (megazone.bigpanda.com [64.147.171.210]) by svr1.postgresql.org (Postfix) with ESMTP id BC7CE5E46DE for ; Wed, 18 Aug 2004 11:38:38 -0300 (ADT) Received: by megazone.bigpanda.com (Postfix, from userid 1001) id 63E4735789; Wed, 18 Aug 2004 07:38:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by megazone.bigpanda.com (Postfix) with ESMTP id 608943577E; Wed, 18 Aug 2004 07:38:44 -0700 (PDT) Date: Wed, 18 Aug 2004 07:38:44 -0700 (PDT) From: Stephan Szabo To: Jan Wieck Cc: Markus Bertheau , Josh Berkus , olly@lfix.co.uk, pgsql-sql@postgresql.org, Bruce Momjian Subject: Re: multi column foreign key for implicitly unique columns In-Reply-To: <41236277.5060903@Yahoo.com> Message-ID: <20040818073152.W1646@megazone.bigpanda.com> References: <1092734724.2627.4.camel@dicaprio.akademie1.de> <1092735576.28365.48.camel@linda> <1092736197.2627.12.camel@dicaprio.akademie1.de> <200408171945.15663.josh@agliodbs.com> <41235A90.1080300@Yahoo.com> <1092836961.2630.3.camel@dicaprio.akademie1.de> <41236277.5060903@Yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE 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/193 X-Sequence-Number: 18690 On Wed, 18 Aug 2004, Jan Wieck wrote: > On 8/18/2004 9:49 AM, Markus Bertheau wrote: > > > =D0=92 =D0=A1=D1=80=D0=B4, 18.08.2004, =D0=B2 15:33, Jan Wieck =D0=BF= =D0=B8=D1=88=D0=B5=D1=82: > > > >> Meaning that not enforcing the uniqueness of those columns isn't an > >> option. > > > > The thing is that the columns _are_ unique, there's just no unique > > constraint on them. They are unique because there's a unique constraint > > on a subset of these columns. So no additional uniqueness enforcing > > needed. > > > > Yes, you are right, a superset of columns of a unique constraint is > allways unique as well. True, but the spec explicitly asks for the columns to be the members of a unique constraint, not that the columns be provably unique. See the other portion of the thread related to dropping constraints for other spec extensions doing this implies. I think the actual specific change to make it look for the subset should be trivial, but we'd really need to work out those dependency issues at the very least and I'm afraid there are more such little corners.