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 628D25E46C3 for ; Tue, 17 Aug 2004 12:06:03 -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 14056-06 for ; Tue, 17 Aug 2004 15:06:07 +0000 (GMT) Received: from megazone.bigpanda.com (megazone.bigpanda.com [64.147.171.210]) by svr1.postgresql.org (Postfix) with ESMTP id 4EF295E46C1 for ; Tue, 17 Aug 2004 12:05:59 -0300 (ADT) Received: by megazone.bigpanda.com (Postfix, from userid 1001) id C439E35284; Tue, 17 Aug 2004 08:06:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by megazone.bigpanda.com (Postfix) with ESMTP id C2A0D351A2; Tue, 17 Aug 2004 08:06:05 -0700 (PDT) Date: Tue, 17 Aug 2004 08:06:05 -0700 (PDT) From: Stephan Szabo To: Markus Bertheau Cc: Tom Lane , Richard Huxton , pgsql-sql@postgresql.org Subject: Re: multi column foreign key for implicitly unique columns In-Reply-To: <1092754658.2627.32.camel@dicaprio.akademie1.de> Message-ID: <20040817080425.U61699@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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8 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/171 X-Sequence-Number: 18668 On Tue, 17 Aug 2004, Markus Bertheau wrote: > =D0=92 =D0=92=D1=82=D1=80, 17.08.2004, =D0=B2 16:46, Tom Lane =D0=BF=D0= =B8=D1=88=D0=B5=D1=82: > > > I think one reason for this is that otherwise it's not clear which > > unique constraint the FK constraint depends on. Consider > > > > create table a (f1 int unique, f2 int unique); > > > > create table b (f1 int, f2 int, > > foreign key (f1,f2) references a(f1,f2)); > > > > How would you decide which constraint to make the FK depend on? > > Either way, the semantics are the same, right? Unfortunately, not in the case of dropping the chosen constraint. Theoretically in that case, you'd probably have to extend the spec there as well to say that you check any dependent objects again to see if they would still be valid rather than dropping them (on cascade) or erroring (on restrict).