Re: Remembering bug #6123 - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Remembering bug #6123
Date
Msg-id 4F0EDEE90200002500044724@gw.wicourts.gov
Whole thread Raw
In response to Re: Remembering bug #6123  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Florian Pflug <fgp@phlo.org> writes:
>> On Jan12, 2012, at 17:30 , Tom Lane wrote:
>>> Actually, on reflection there might be a reason for checking
>>> update_ctid, with a view to allowing "harmless" cases.
> 
>> I've argued against that in the past, and I still think it's a
>> bad idea.
> 
> Well, the main argument for it in my mind is that we could avoid
> breaking existing behavior in cases where it's not clearly
> essential to do so.  Perhaps that's less compelling than keeping
> the behavior simple, since it's true that the specific cases we
> could preserve the old behavior in are pretty infrequent.  I'm not
> wedded to the idea, but would like to hear a few other peoples'
> opinions.
FWIW, I started from the position that the "harmless" cases should
be quietly handled.  But Florian made what, to me, were persuasive
arguments against that.  A DELETE trigger might fire twice for one
delete, mucking up data integrity, for example.  His proposal seemed
to make my use case hard to handle, but then he pointed out how
triggers could be coded to allow that -- it's just that you would
need to go out of your way to do so, reducing the chance of falling
into bad behavior accidentally.
So count me as a convert to Florian's POV, even if I didn't succeed
in ripping out all the code from my former POV from the v3 patch.
-Kevin


pgsql-hackers by date:

Previous
From: Jaime Casanova
Date:
Subject: Re: create index regression fail
Next
From: Alvaro Herrera
Date:
Subject: Re: create index regression fail