Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> No, because that would entail a genuine loss of capability: FK
>> constraints couldn't be built using indexes that were made by CREATE
>> UNIQUE INDEX rather than through the unique/pk constraint syntax.
>> In particular this would mean that non-btree indexes could not be used.
> But that means the deficiency is elsewhere, namely that you cannot build
> non-btree indexes for primary key or unique constraints.
So are you proposing we extend the constraint syntax instead? I think
it's better to keep our nonstandard index support in a separate,
nonstandard statement (CREATE INDEX) rather than mash it together with
spec-mandated syntax. That seems like a recipe for getting stuck when
the spec adds extensions.
> Isn't the whole unique index thing a dead end anyway? How are we ever
> going to get deferrable unique constraints that way?
The way that was just discussed --- with a deferrable constraint, you
don't elog immediately when the index detects a collision, but make a
note to recheck that particular key value at the time the constraint
should be enforced. I can't imagine that we'd want to do unique
constraints without any index support. How would you avoid having to
check lots and lots of uninteresting rows?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
