Thread: 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.
Re: So, do we want to remove the "triggered data change" code?
From
"Zeugswetter Andreas SB SD"
Date:
> 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