Hi, On Sun, 13 Sept 2026 at 17:46, Dean Rasheed <[email protected]> wrote: > > 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.
Thanks for the feedback. I reworked the patch to reject the expanded tableoid reference with a proper error and added a regression test for the reported case. [Unsure whether this should be backpatched to PG 18 though] Attaching v2. Thoughts on the placement and error message? Regards, Ayush
v2-0001-Reject-tableoid-in-EXCLUDED-virtual-generated-columns.patch
Description: Binary data
