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 275065E46C1 for ; Tue, 17 Aug 2004 06:39:46 -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 86737-04 for ; Tue, 17 Aug 2004 09:39:44 +0000 (GMT) Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by svr1.postgresql.org (Postfix) with ESMTP id D619A5E3F15 for ; Tue, 17 Aug 2004 06:39:42 -0300 (ADT) Received: from lfix.demon.co.uk ([80.177.205.209] helo=cerberus.lfix.co.uk) by anchor-post-34.mail.demon.net with esmtp (Exim 3.35 #1) id 1Bx0RT-000A1H-0Y; Tue, 17 Aug 2004 09:39:44 +0000 Received: from linda.lfix.co.uk ([192.168.1.1]) by cerberus.lfix.co.uk with esmtp (Exim 4.34) id 1Bx0RM-0001Vz-UF; Tue, 17 Aug 2004 10:39:36 +0100 Subject: Re: multi column foreign key for implicitly unique columns From: Oliver Elphick Reply-To: olly@lfix.co.uk To: Markus Bertheau Cc: pgsql-sql@postgresql.org In-Reply-To: <1092734724.2627.4.camel@dicaprio.akademie1.de> References: <1092734724.2627.4.camel@dicaprio.akademie1.de> Content-Type: text/plain Organization: LFIX Limited Message-Id: <1092735576.28365.48.camel@linda> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 17 Aug 2004 10:39:36 +0100 Content-Transfer-Encoding: 7bit X-LFIX-MailScanner: Found to be clean X-MailScanner-From: olly@lfix.co.uk 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/155 X-Sequence-Number: 18652 On Tue, 2004-08-17 at 10:25, Markus Bertheau wrote: > Hi, > > PostgreSQL doesn't allow the creation of a foreign key to a combination > of fields that has got no dedicated unique key but is unique nonetheless > because a subset of the combination of fields has a unique constraint. > Example: > > CREATE TABLE p ( > name TEXT PRIMARY KEY, > "type" TEXT > ); > > CREATE TABLE f ( > name TEXT, > "type" TEXT, > FOREIGN KEY(name, "type") REFERENCES p(name, "type") > ); > ERROR: there is no unique constraint matching given keys for referenced table "p" What's the point of this? p.name is the primary key and is therefore unique in p, so your foreign key should simply reference p.name. Having f.type as a repetition of p.type violates normalisation principles, since name is completely derivable by a join of f to p on name. > Is this on purpose? I think the foreign key should be allowed. Creating > an extra unique key only has a negative impact on performance, right? If there is no unique key, how does the foreign key trigger find the referenced row except by doing a sequential scan? Bad news! And when one of the duplicate referenced rows changes, what should happen with ON UPDATE or ON DELETE? -- Oliver Elphick olly@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA ======================================== "If ye abide in me, and my words abide in you, ye shall ask what ye will, and it shall be done unto you." John 15:7