On Sat, 12 Sept 2026 at 19:10, Ayush Tiwari <[email protected]> wrote: > > On Sat, 12 Sept 2026 at 23:10, Dean Rasheed <[email protected]> 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
