Re: BUG #17689: Two UPDATE operators in common table expressions (CTE) perform not as expected

David G. Johnston <david.g.johnston@gmail.com>

From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Marko Tiikkaja <marko@joh.to>, eugene.pliskin@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2022-11-18T22:50:59Z
Lists: pgsql-bugs
On Fri, Nov 18, 2022 at 11:53 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > On 2022-Nov-18, Marko Tiikkaja wrote:
> >> This is a documented limitation:
> >>> Trying to update the same row twice in a single statement is not
> >>> supported.
>
> > I wonder if we should try to detect the case, and raise an error instead
> > of it resulting in undefined behavior.
>
> My recollection is that that is really fallout from an ancient and
> intentional executor behavior, that we have to ignore multiple updates
> in order to not get into infinite loops.  See comment about the
> "Halloween problem" in nodeLockRows.c.  (I'm pretty sure there were once
> more comments about that, somewhere closer to ExecUpdate/ExecDelete ---
> this all dates back to Berkeley.)
>
>
I'm not really sure I'd want to change the behavior to perform multiple
updates even if we could.  But in a green field development I would prefer
the error.  Right now I'd side with introducing an error as well.

David J.