Re: So, do we want to remove the "triggered data change" code?

> It seemed like the discussion a couple days ago ended without any
> definitive agreement on what to do. Since we're about to push out
> 7.2beta3, we need to decide whether we're going to change the code
> now, or wait another release cycle before doing anything.
>
> I would like to formally propose removing the "triggered data change"
> error check (for details, see the patch I posted to pgsql-patches on
> Monday). My reasoning is that the present code is:
>
> 1. broken --- it doesn't implement the spec.
> 2. slow --- it causes a *major* performance hit when a long
transaction
> updates many rows more than once in a table having foreign keys.
> 3. not likely to be the basis for a correct solution --- AFAICT,
> the correct interpretation of "triggered data change" is not
> trigger-specific; it would be better handled as part of what we
> call time qual checking.

yes, to all above.

>
> Point #2 is affecting some real-world applications I know of, and so
> I'd rather not wait another release cycle or more to offer a fix.

I have tried hard to fully understand the issue, and think that your
proposed patch is correct.

The whole check was only done for tuples modified inside this
transaction,
thus while I have the feeling that Tatsuo's concerns and above point 3
are
valid, they are not affected by this patch.

I thus think you should apply the patch.

Andreas