On Thu, Jan 12, 2012 at 4:30 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: >> Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Also, what's the point of testing update_ctid? I don't see that >>> it matters whether the outdate was a delete or an update. > >> The update_ctid code was a carry-over from my old, slightly >> different approach, which I failed to change as I should have. I'll >> fix that along with the other. > > Actually, on reflection there might be a reason for checking > update_ctid, with a view to allowing "harmless" cases. I see > these cases: > > * UPDATE finds a trigger already updated the row: must throw error > since we can't apply the update. > > * UPDATE finds a trigger already deleted the row: arguably, we could > let the deletion stand and ignore the update action. > > * DELETE finds a trigger already updated the row: must throw error > since we can't apply the delete. > > * DELETE finds a trigger already deleted the row: arguably, there's > no reason to complain. > > Don't know if that was your reasoning as well. But if it is, then again > the comment needs to cover that.
Just been reading this thread a little. ISTM that seeing a SelfUpdated row on a cursor when we didn't use WHERE CURRENT OF really ought to raise some kind of exception condition like a WARNING or a NOTICE. That situation seems most likely to be a bug or at least an unintended consequence. As Tom points out, the multiple flavours of weirdness that can result even if we do fix this are not things we should do silently. I think we should do the best job we can without throwing an error, but we must make some attempt to let the developer know we did that for them so they can investigate. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
