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

Thu, 15 Nov 2001 19:01:00 -0500
Tom Lane <tgl@sss.pgh.pa.us>
So, do we want to remove the "triggered data change" code?
On Thu, 15 Nov 2001, Tom Lane wrote:

> Any objections out there?

I have no argument against ripping it out.


Thu, 15 Nov 2001 16:31:53 -0800 (PST)
Stephan Szabo <sszabo@megazone23.bigpanda.com>
Re: So, do we want to remove the "triggered data change"