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

From: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: Alexander Lakhin <exclusion(at)gmail(dot)com>, SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [BUG] ON CONFLICT DO UPDATE SET x = EXCLUDED.<virtual-generated-column> errors or silently writes NULL
Date: 2026-09-13 14:54:58
Message-ID: CAJTYsWXH1WxRbD3KBrxMm+ApHKC_7zwhhY2BhK9Gk1fOZHKo9A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Sun, 13 Sept 2026 at 17:46, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
>
> 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.

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

Attachment Content-Type Size
v2-0001-Reject-tableoid-in-EXCLUDED-virtual-generated-columns.patch application/octet-stream 4.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Borodin 2026-09-13 15:14:05 Re: SSI: ON CONFLICT DO SELECT takes no predicate lock on the returned row
Previous Message Dinesh Salve 2026-09-13 14:14:48 Re: explain plans for foreign servers