| From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Subject: | Re: Bug: Rule actions see wrong values for generated columns (NEW.gen reads OLD value) |
| Date: | 2026-04-13 08:20:35 |
| Message-ID: | CAMbWs48=QrLy8gZprTfCmEtzoaUku54JXvAcnoRSo+OC8vUpwA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Apr 13, 2026 at 4:21 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
> I think the issue is that rewriteTargetListIU() removes generated columns from the target list, as described by this comment:
> Later, when the rule action is rewritten, ReplaceVarsFromTargetList() cannot find a target list entry for NEW.gen. For UPDATE rules, the missing NEW column is handled with REPLACEVARS_CHANGE_VARNO, so it falls back to referencing the original target relation row, which gives the old value.
I came to the same conclusion.
> One possible fix is to build a new target list that adds generated columns back when there are rules to fire. I tried the solution locally with some quick and dirty code and it seems to fix both stored and virtual generated columns for me.
I think a simpler fix might be to expand generated column references
in the NEW relation to their generation expressions before
ReplaceVarsFromTargetList resolves NEW references, so that the base
column Vars within the expressions can be correctly resolved.
Something like attached.
- Richard
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Fix-incorrect-NEW-references-to-generated-columns.patch | application/octet-stream | 11.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | JoongHyuk Shin | 2026-04-13 08:21:39 | [PATCH] Don't call ereport(ERROR) from recovery target GUC assign hooks |
| Previous Message | David Rowley | 2026-04-13 08:16:55 | Re: quoteOneName() inconsistency with quote_all_identifiers — replacement API proposed |