Re: Bug in FOREIGN KEY - Mailing list pgsql-hackers
| From | Jan Wieck |
|---|---|
| Subject | Re: Bug in FOREIGN KEY |
| Date | |
| Msg-id | 200012141202.HAA03905@jupiter.jw.home Whole thread Raw |
| In response to | Re: Bug in FOREIGN KEY (Bruce Momjian <pgman@candle.pha.pa.us>) |
| Responses |
Re: Bug in FOREIGN KEY
Re: Bug in FOREIGN KEY Re: Bug in FOREIGN KEY |
| List | pgsql-hackers |
Bruce Momjian wrote:
> > Bruce Momjian writes:
> >
> > > ERROR: triggered data change violation on relation "primarytest2"
> >
> > We're getting this report about once every 48 hours, which would make it a
> > FAQ. (hint, hint)
> >
>
>
> First time I heard of it. Does anyone know more details?
Think I misinterpreted the SQL3 specs WR to this detail. The checks must be made per statement, not at the
transaction level. I'll try to fix it, but we need to define what will happen with referential actions in the
case of conflicting actions on the same key - there are some possible conflicts:
1. DEFERRED ON DELETE NO ACTION or RESTRICT
Do the referencing rows reference to the new PK row with the same key now, or is this still a
constraint violation? I would say it's not, because the constraint condition is satisfied at the end of
thetransaction. How do other databases behave?
2. DEFERRED ON DELETE CASCADE, SET NULL or SET DEFAULT
Again I'd say that the action should be suppressed because a matching PK row is present at
transactionend - it's not the same old row, but the constraint itself is still satisfied.
Implementing it that way (if it is correct that way) requires that the RI-triggers check that the key in
questionreally disappeared from the PK table, at least for the deferred invocation at transaction end. This
lookupis not required in the immediate case, so it would be possible to retain the current performance here,
but we'd need a mechanism that tells the trigger if it is actually invoked in immediate or deferred mode. Don't
knowhow to do that right now.
To fix it now, I'd tend to remove the triggered data change check in the trigger queue (where the error is
coming from) and add the extra PK lookup to the triggers for 7.1. Then think about the suppress of it with
an immediate/deferred flag mechanism for 7.2.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
pgsql-hackers by date: