Re: [BUG] ON CONFLICT DO UPDATE SET x = EXCLUDED.<virtual-generated-column> errors or silently writes NULL

On Sat, 12 Sept 2026 at 19:10, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> wrote:
>
> On Sat, 12 Sept 2026 at 23:10, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
> >
> > Hmm, I'm not sure that this is the right approach. For example,
> > consider this case, without a generated column:
> >
> > CREATE TABLE t (id int PRIMARY KEY, val int);
> > INSERT INTO t VALUES (1,2)
> > ON CONFLICT (id) DO UPDATE SET val = 0 WHERE excluded.tableoid > 0;
> >
> > ERROR: column excluded.tableoid does not exist
> >
> > That error is on point -- "excluded" is not a real table, it is a
> > pseudo-table constructed from the values proposed for insertion, not
> > the existing values. As such, it has no system columns.
> >
> > So, ISTM that when "c" is a virtual generated column, and "excluded.c"
> > is expanded to "excluded.tableoid", it *should* produce an error.
>
> My thinking was that excluded.c could use the table that the row would
> have been inserted into when evaluating its generation expression.
>
> Would that be a reasonable meaning for tableoid here, or should it be
> considered unavailable because EXCLUDED represents only a proposed row?
> That was the distinction I had in mind, but I may be missing something.
>

I think it shouldn't be allowed. Besides the fact that EXCLUDED is the
proposed row, and doesn't have a tableoid, it would be inconsistent to
allow a virtual generated column to magic-up EXCLUDED.tableoid, when
that isn't available when referenced directly in SQL.

Regards,
Dean