MIME-Version: 1.0
References: 
 <CAHg+QDexGTmCZzx=73gXkY2ZADS6LRhpnU+-8Y_QmrdTS6yUhA@mail.gmail.com>
 <CAMbWs4-SJ6B26ciFu_K_2M1ObDA=GirV87N1BKeAtSRmQGATUA@mail.gmail.com>
 <22B4A33A-99F3-46F5-BE0C-426A9E1D9ABA@gmail.com>
 <CAMbWs48=QrLy8gZprTfCmEtzoaUku54JXvAcnoRSo+OC8vUpwA@mail.gmail.com>
In-Reply-To: 
 <CAMbWs48=QrLy8gZprTfCmEtzoaUku54JXvAcnoRSo+OC8vUpwA@mail.gmail.com>
From: Dean Rasheed <dean.a.rasheed@gmail.com>
Date: Mon, 13 Apr 2026 12:03:53 +0100
Message-ID: 
 <CAEZATCWYqyJJJcMNEj-LEvCSwog2H_HS61hTROZLKYuaiy5YTg@mail.gmail.com>
Subject: Re: Bug: Rule actions see wrong values for generated columns (NEW.gen
 reads OLD value)
To: Richard Guo <guofenglinux@gmail.com>
Cc: Chao Li <li.evan.chao@gmail.com>,
	SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
	Peter Eisentraut <peter@eisentraut.org>
Content-Type: multipart/alternative; boundary="000000000000decae0064f557052"
Archived-At: 
 <https://www.postgresql.org/message-id/CAEZATCWYqyJJJcMNEj-LEvCSwog2H_HS61hTROZLKYuaiy5YTg%40mail.gmail.com>
Precedence: bulk

--000000000000decae0064f557052
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 13 Apr 2026, 09:20 Richard Guo, <guofenglinux@gmail.com> wrote:

> On Mon, Apr 13, 2026 at 4:21=E2=80=AFPM Chao Li <li.evan.chao@gmail.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 missin=
g
> 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 virtua=
l
> 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
>

One thing about that approach is that it leads to 2 full rewrites of the
rule action using ReplaceVarsFromTargetList(). I think that could be
avoided by using including generated column expressions in the targetlist
passed to ReplaceVarsFromTargetList() by rewriteRuleAction(). I haven't
tried it, but I imagine it could reuse some code
from expand_generated_columns_internal().

Regards,
Dean

>

--000000000000decae0064f557052
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote gmail_quote_container"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Mon, 13 Apr 2026, 09:20 Richard Guo, =
&lt;<a href=3D"mailto:guofenglinux@gmail.com">guofenglinux@gmail.com</a>&gt=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon,=
 Apr 13, 2026 at 4:21=E2=80=AFPM Chao Li &lt;<a href=3D"mailto:li.evan.chao=
@gmail.com" target=3D"_blank" rel=3D"noreferrer">li.evan.chao@gmail.com</a>=
&gt; wrote:<br>
&gt; I think the issue is that rewriteTargetListIU() removes generated colu=
mns from the target list, as described by this comment:<br>
<br>
&gt; 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 re=
ferencing the original target relation row, which gives the old value.<br>
<br>
I came to the same conclusion.<br>
<br>
&gt; One possible fix is to build a new target list that adds generated col=
umns back when there are rules to fire. I tried the solution locally with s=
ome quick and dirty code and it seems to fix both stored and virtual genera=
ted columns for me.<br>
<br>
I think a simpler fix might be to expand generated column references<br>
in the NEW relation to their generation expressions before<br>
ReplaceVarsFromTargetList resolves NEW references, so that the base<br>
column Vars within the expressions can be correctly resolved.<br>
Something like attached.<br>
<br>
- Richard<br></blockquote></div></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">One thing about that approach is that it leads to 2 full rewrites=
 of the rule action using ReplaceVarsFromTargetList(). I think that could b=
e avoided by using including generated column expressions in the targetlist=
 passed to ReplaceVarsFromTargetList() by rewriteRuleAction(). I haven&#39;=
t tried it, but I imagine it could reuse some code from=C2=A0expand_generat=
ed_columns_internal().</div><div dir=3D"auto"><br></div><div dir=3D"auto">R=
egards,</div><div dir=3D"auto">Dean</div><div dir=3D"auto"><div class=3D"gm=
ail_quote gmail_quote_container"><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">
</blockquote></div></div></div>

--000000000000decae0064f557052--