Re: multi column foreign key for implicitly unique columns

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 #