On 8/18/2004 12:46 PM, 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.
The idea sure needs some refinement :-)
> 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.
Actually, the whole thing strikes me more as a sign for a denormalized
database schema.
If a.x is unique, then (b.x, b.y) references (a.x, a.y) is only ensuring
that the redundant copy of y in b.y stays in sync with a.y.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #