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 54B445E40BB for ; Wed, 18 Aug 2004 10:33:25 -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 68998-07 for ; Wed, 18 Aug 2004 13:33:24 +0000 (GMT) Received: from smtp104.mail.sc5.yahoo.com (smtp104.mail.sc5.yahoo.com [66.163.169.223]) by svr1.postgresql.org (Postfix) with SMTP id 75F155E37D0 for ; Wed, 18 Aug 2004 10:33:18 -0300 (ADT) Received: from unknown (HELO jupiter.black-lion.info) (janwieck@68.80.245.191 with login) by smtp104.mail.sc5.yahoo.com with SMTP; 18 Aug 2004 13:33:23 -0000 Received: from [172.21.8.18] (ismtp.afilias.com [216.217.55.254]) (authenticated bits=0) by jupiter.black-lion.info (8.12.10/8.12.9) with ESMTP id i7IDXBT7064208; Wed, 18 Aug 2004 09:33:11 -0400 (EDT) (envelope-from JanWieck@Yahoo.com) Message-ID: <41235A90.1080300@Yahoo.com> Date: Wed, 18 Aug 2004 09:33:04 -0400 From: Jan Wieck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Josh Berkus Cc: Markus Bertheau , olly@lfix.co.uk, pgsql-sql@postgresql.org Subject: Re: multi column foreign key for implicitly unique columns 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> In-Reply-To: <200408171945.15663.josh@agliodbs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=1.6 tagged_above=0.0 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL X-Spam-Level: * X-Archive-Number: 200408/189 X-Sequence-Number: 18686 On 8/17/2004 10:45 PM, Josh Berkus wrote: > Markus, > > Hey, I see you figured out a workaround to writing a trigger for this. Let's > see if we can make it work. > > ERROR: there is no unique constraint matching given keys > for referenced table "objects" > > The reason for this is that CASCADE behavior gets quite odd when there is an > FK reference to a non-unique column. We used to allow it, in 7.1, and I was > responsible for a number of bug reports that led to us disallowing it. It > should be theoretically implementable and relationally sound but will require > a *lot* of troubleshooting to make work. So far, nobody's really interested > enough. SQL92 4.10 Integrity constraints: ... In the case that a table constraint is a referential constraint, the table is referred to as the referencing table. The referenced columns of a referential constraint shall be the unique columns of some unique constraint of the referenced table. ... Meaning that not enforcing the uniqueness of those columns isn't an option. PostgreSQL is currently happy with a UNIQUE constraint that covers those columns in any order, which is to the letter spec compliant. "Really interested" will not do here. Jan > > However, you have an easy way out: > > ALTER TABLE objects ADD CONSTRAINT obj_unq_2 UNIQUE (name, class_name); > > This will add the unique constraint that Postgres wants without changing your > data at all. > -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #