On 12 Feb 2026 at 13:23 +0100, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, wrote:
> On Thu, 12 Feb 2026 at 11:11, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)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(at)wikimedia(dot)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.