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.

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