Uh oh,
I think deferred RI constraints must only fire the actions
that remain after all commands during the entire transaction
are condensed to the total minimum required to get that
state, because deferred RI must only check what VISIBLY
happened during the transaction.
Thinking on the tuple level, a sequence of
INSERT,UPDATE,UPDATE must fire only one INSERT trigger, but
with the values of the last UPDATE. An UPDATE,DELETE sequence
is in fact a DELETE of the original tuple and an
INSERT,UPDATE,DELETE sequence is nothing.
That means that the recording mechnism of the trigger events
must be very smart on UPDATE and DELETE events, looking at
the x_min of the old tuple if that resulted from the current
transaction. If so, follow the events backward, disable
previous ones and change the new event into what it really
has to be.
But some problems remain unsolvable by this:
- PK has an ON DELETE CASCADE for FK
- BEGIN
- DELETE PK
- INSERT same PK
- COMMIT.
This really shouldn't invoke the cascading delete, because at
COMMIT the PK still is there. Same for a constraint that
forbids deletion of a PK while referenced by FK. Therefore
the deferred event recorder must check on INSERT any previous
DELETES for the same relation if the key does match and drop
both deferred triggers if so. Therefore it needs to know
which attributes build the PK of that relation
(<relname>_pkey guaranteed?).
Well, I think that's finally the death of RI over rules. The
code managing those rules during CREATE/ALTER TABLE would
become totally unmaintainable. And (sorry Vadim) it's the
death of SLT for this too because this event tracking must be
done on the tuple level.
It complicated the trigger approach too, but IMHO not too
bad. Anyway, some co-developer(s) doing the parser- and
utility-statement stuff (SET CONSTRAINTS ... etc.) would be
great.
Volunteers?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #