Обсуждение: 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
havingforeign keys.
 
3. not likely to be the basis for a correct solution --- AFAICT,  the correct interpretation of "triggered data change"
isnot  trigger-specific; it would be better handled as part of what we  call time qual checking.
 

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 don't believe that removing the error check can break any applications
that are currently working, and so I see no real downside to taking this
code out.

Any objections out there?
        regards, tom lane

On Thu, 15 Nov 2001, Tom Lane wrote:

> Any objections out there?

I have no argument against ripping it out.

> 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