Tom Lane <t...@sss.pgh.pa.us> wrote: > Florian Pflug <f...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers