Re: multi column foreign key for implicitly unique columns

On 8/18/2004 12:46 PM, 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.

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(at)Yahoo(dot)com #