Re: multi column foreign key for implicitly unique columns

Tom Lane wrote:
> 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.

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