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 79ECF5E46C4 for ; Wed, 18 Aug 2004 14:49:19 -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 80818-05 for ; Wed, 18 Aug 2004 17:49:24 +0000 (GMT) Received: from anchor-post-37.mail.demon.net (anchor-post-36.mail.demon.net [194.217.242.86]) by svr1.postgresql.org (Postfix) with ESMTP id 1470A5E46DE for ; Wed, 18 Aug 2004 14:49:13 -0300 (ADT) Received: from mwynhau.demon.co.uk ([193.237.186.96] helo=mainbox.archonet.com) by anchor-post-37.mail.demon.net with esmtp (Exim 3.35 #1) id 1BxUYo-000Ir2-0b; Wed, 18 Aug 2004 17:49:18 +0000 Received: from [192.168.1.17] (client17.archonet.com [192.168.1.17]) by mainbox.archonet.com (Postfix) with ESMTP id B54E416CCD; Wed, 18 Aug 2004 18:49:17 +0100 (BST) Message-ID: <4123969A.4020509@archonet.com> Date: Wed, 18 Aug 2004 18:49:14 +0100 From: Richard Huxton User-Agent: Mozilla Thunderbird 0.7 (X11/20040615) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Lane Cc: Jan Wieck , 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=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200408/208 X-Sequence-Number: 18705 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. I'm not sure it needs to be as clever as Jan suggested (but then I'm not as clever as Jan :-). I'd have thought a reference that forces you to use DROP...CASCADE would be enough. In those cases where you're dropping a whole table, presumably that's already implied. -- Richard Huxton Archonet Ltd