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