Re: Allow ON CONFLICT DO UPDATE to return EXCLUDED values - Mailing list pgsql-hackers

From Viktor Holmberg
Subject Re: Allow ON CONFLICT DO UPDATE to return EXCLUDED values
Date
Msg-id ec099f14-221d-41a0-9a83-f8adc95c85f5@Spark
Whole thread Raw
In response to Re: Allow ON CONFLICT DO UPDATE to return EXCLUDED values  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List pgsql-hackers
On 12 Feb 2026 at 13:23 +0100, Dean Rasheed <dean.a.rasheed@gmail.com>, wrote:
On Thu, 12 Feb 2026 at 11:11, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:

Rebased version attached (now also works with ON CONFLICT DO SELECT).


Something else to consider is the fact that this patch allows both
colname and EXCLUDED.colname to appear in the RETURNING list, where
the former refers to the target relation as it always has done. We're
pretty-much forced into that position, in order that people don't have
to rewrite all their existing queries (the same was true when support
for OLD/NEW was added to RETURNING).

But that then leads to the odd situation where colname has to be
qualified when it appears on the RHS of a SET clause, or in the WHERE
clause of INSERT ON CONFLICT, but not when it appears in the RETURNING
list.

There was a separate discussion [1] about whether we should remove
this requirement for colname to be qualified elsewhere in INSERT ON
CONFLICT, and I think this patch adds more weight to that argument.

[1] https://www.postgresql.org/message-id/flat/a31a76b6-b176-47fe-8778-9dfece231341@wikimedia.org

So should we do that, and allow unqualified column names in ON
CONFLICT SET and WHERE?
In my opinion, yes. Qualifying with the table name doesn’t really make it much clearer which version of the table you’re referring to than having it unqualified.

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: recovery.signal not cleaned up when both signal files are present
Next
From: "David E. Wheeler"
Date:
Subject: Re: pgsql: Add file_extend_method=posix_fallocate,write_zeros.