Re: Bug in FOREIGN KEY

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Jan Wieck <janwieck(at)Yahoo(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug in FOREIGN KEY
Date: 2001-01-24 14:44:36
Message-ID: 200101241444.JAA20910@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


We have to decide how to address this, perhaps with a clearer error
message and a TODO item.

> 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 the transaction. 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 transaction end -
> 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 question really
> disappeared from the PK table, at least for the deferred
> invocation at transaction end. This lookup is 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 know how 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(at)Yahoo(dot)com #
>
>
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-01-24 14:45:02 Re: [GENERAL] User names
Previous Message Bruce Momjian 2001-01-24 14:44:08 Re: (one more time) Patches with vacuum fixes available .