Re: multi column foreign key for implicitly unique columns

Tom Lane wrote:
> Jan Wieck <JanWieck(at)Yahoo(dot)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.

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