Vadim wrote:
> I believe that things are much simpler.
> For each deferable constraint (trigger) we have to remember
> the LastCommandIdProccessedByConstraint. When the mode of
> a constraint changes from defered to immediate (SET CONSTRAINT MODE),
> modified tuple will be fetched from WAL from down to up until
> tuple modified by LastCommandIdProccessedByConstraint is fetched
> and this is show stopper. Now we remember CommandId of
> SET CONSTRAINT MODE as new LastCommandIdProccessedByConstraint.
> When LastCommandIdProccessedByConstraint is changed by
> SET CONSTRAINT MODE DEFERRED we remeber this in flag to
> update LastCommandIdProccessedByConstraint later with higher
> CommandId of first modification of triggered table (to reduce
> amount of data to read from WAL).
Hmmm,
I'm not sure what side effects it could have if the triggers
at the time of
SET CONSTRAINTS c1, c2 IMMEDIATE
arent fired in the same order they have been recorded - must
think about that for a while. In that case I must be able to
scan WAL from one command ID until another regardless of the
resultrelation. Is that possible?
Another issue is this: isn't it possible to run a database
(or maybe an entire installation) without WAL? Does it make
the code better maintainable to have WAL and RI coupled that
strong?
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) #
