Jan Wieck <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
