Re: Incorrect UPDATE trigger invocation in the UPDATE clause of an UPSERT statement.

On Wed, Dec 9, 2015 at 1:43 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2015-12-08 15:32:03 -0800, Peter Geoghegan wrote:
>> I actually think that there is an argument to be made for doing
>> nothing here, and not allowing a cardinality violation at all.
>
> Works for me. I'll add a short comment before the ExecUpdate() detailing
> that the row could, in rather uncommon cases, be updated by that
> point. Adding an extra parameter to ExecUpdate() + additional concerns
> to it's already nontrivial HTSV codepath doesn't seem worth it to
> me.

I would prefer to throw an error (not a cardinality violation error),
since there is a critical change between locking the tuple, and the
corresponding DO UPDATE call to ExecUpdate().

I'm not going to insist on that, though (just as I didn't insist on
the exact style of the fix). I only insist that this new
HealTupleSatisfiesSelf-in-ExecUpdate() case should not be treated as a
cardinality violation specifically, and should be separately
acknowledge at some level.

--
Peter Geoghegan