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