From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jan Wieck <JanWieck@Yahoo.com>
Cc: Richard Huxton <dev@archonet.com>
Cc: Markus Bertheau <twanger@bluetwanger.de>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: olly@lfix.co.uk, pgsql-sql@postgresql.org, Bruce Momjian <pgman@candle.pha.pa.us>
Subject: Re: multi column foreign key for implicitly unique columns
Date: Wed, 18 Aug 2004 12:46:26 -0400
Message-ID: <1803.1092847586@sss.pgh.pa.us> (raw)
In-Reply-To: <4123837C.30408@Yahoo.com>
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>
Jan Wieck <JanWieck@Yahoo.com> 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.
(Sample problem: what you're actually trying to do is drop the entire
table ... but because the subset-index happens to get visited first,
you go off and build the superset-index before you let the DROP finish.
User will be unhappy, if table is large. Or try this one: the superset-
index build actually fails because you've already dropped something it
depends on. This seems quite possible in cases involving cascading from
a drop of an individual column or datatype, for instance.)
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.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: tgl@sss.pgh.pa.us, JanWieck@Yahoo.com, dev@archonet.com, twanger@bluetwanger.de, josh@agliodbs.com, pgman@candle.pha.pa.us
Subject: Re: multi column foreign key for implicitly unique columns
In-Reply-To: <1803.1092847586@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox