On Tue, 8 Jan 2002, Holger Krug wrote:
> > 2. Not sure about CHECK constraints but Uniq/PrimaryKey ones are not
> > deferrable currently -:( And this is muuuuuch worse drawback then absence
> > of comprehensive reports. It's more complex thing to do than on error
> > triggers but someday it will be implemented because of this is "must
> > have"
> > kind of things.
>
> A simple implementation of deferred UNIQUE constraints could be very
> easily provided bases on my error handlers. Imagine a deferred UNIQUE
> index where a DUPKEY is up to be inserted. When the DUPKEY appears in
> DEFERRED mode my error handler will:
>
> 1) not mark the transaction for rollback
> 2) add a trigger to the deferred trigger queue to do checks on the DUPKEY
> in the given index
> 3) that's all
ISTM that the above seems to imply that you could make unique
constraints that don't actually necessarily constrain to uniqueness (an
error handler that say didn't mark for rollback and did nothing to
enforce it later, or only enforced it in some cases, etc...). If so,
I'd say that any unique constraint that had an error condition for example
couldn't be used as if it guaranteed uniqueness (for example as targets
of fk constraints).
