| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Stanislav Grozev <tacho(at)daemonz(dot)org>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: Incorrect UPDATE trigger invocation in the UPDATE clause of an UPSERT statement. |
| Date: | 2015-12-09 22:36:08 |
| Message-ID: | CAM3SWZQ0jNOfDf=FfmVxMxRz-vXMJzG03VtTDds2D9wAJPu9wQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Wed, Dec 9, 2015 at 1:43 PM, Andres Freund <andres(at)anarazel(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | exru | 2015-12-10 12:52:03 | BUG #13811: Default ordering colums |
| Previous Message | Andres Freund | 2015-12-09 21:55:11 | Re: Incorrect UPDATE trigger invocation in the UPDATE clause of an UPSERT statement. |