On Tue, Jan 08, 2002 at 01:06:42AM -0800, Stephan Szabo wrote:
> On Tue, 8 Jan 2002, Holger Krug wrote:
> > 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).
What I said above was an extension of my original proposal, which consists of:
1) marking the transaction for rollback
2) ...
I only wanted to show, that the addition I'm going to make to
PostgreSQL, could be used to implemented DEFERRED UNIQUE constraints
in a very simple way. Of course, this special error handler for
DEFERRED UNIQUE constraints, which puts a trigger with the DUPKEY into
that deferred trigger queue, could not be up-to the user but must be
system-enforced.
But - you're right. My previous mail didn't express this explicitely,
hence your notice is correct. Thank you !
--
Holger Krug
hkrug@rationalizer.com
