| 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 |
| 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 |