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 9E52A5E46FE for ; Wed, 18 Aug 2004 15:02:11 -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 84738-08 for ; Wed, 18 Aug 2004 18:02:14 +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 D80745E46F8 for ; Wed, 18 Aug 2004 15:02:04 -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 18:02:12 -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 i7II24T7065486; Wed, 18 Aug 2004 14:02:05 -0400 (EDT) (envelope-from JanWieck@Yahoo.com) Message-ID: <41239990.1000007@Yahoo.com> Date: Wed, 18 Aug 2004 14:01:52 -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: Tom Lane Cc: Richard Huxton , Markus Bertheau , Josh Berkus , olly@lfix.co.uk, pgsql-sql@postgresql.org, Bruce Momjian 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> <41235A90.1080300@Yahoo.com> <1092836961.2630.3.camel@dicaprio.akademie1.de> <41236277.5060903@Yahoo.com> <22808.1092842209@sss.pgh.pa.us> <41237DA2.9090405@archonet.com> <1535.1092845917@sss.pgh.pa.us> <4123837C.30408@Yahoo.com> <1803.1092847586@sss.pgh.pa.us> In-Reply-To: <1803.1092847586@sss.pgh.pa.us> 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/210 X-Sequence-Number: 18707 On 8/18/2004 12:46 PM, Tom Lane wrote: > Jan Wieck writes: >> If we allow for a unique index, that >> * it is NOT maintained (no index tuples in there) >> * depends on another index that has a subset of columns >> * if that subset-index is dropped, the index becomes maintained >> then the uncertainty is gone. At the time someone drops the other >> constraint or unique index, the data is unique with respect to the >> superset of columns. So building the unique index data at that time will >> succeed. > > My goodness this is getting ugly. The notion of having to invoke an > index build as a side-effect of a DROP sounds like a recipe for trouble. The idea sure needs some refinement :-) > I'd like to see more than one person needing it, before we go to that > kind of trouble to do something that's not in the spec. Actually, the whole thing strikes me more as a sign for a denormalized database schema. If a.x is unique, then (b.x, b.y) references (a.x, a.y) is only ensuring that the redundant copy of y in b.y stays in sync with a.y. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #