Re: [HACKERS] Re: Referential Integrity In PostgreSQL

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) #