> On Apr 13, 2026, at 10:35, Richard Guo <guofenglinux@gmail.com> wrote: > > On Mon, Apr 13, 2026 at 10:59 AM SATYANARAYANA NARLAPURAM > <satyanarlapuram@gmail.com> wrote: >> NEW.<generated_coulmn> is resolved to the OLD row's value >> for update or NULL for insert cases in a DO ALSO rule action for >> generated columns. This bug affects both stored and virtual >> generated columns. Reporting here to see if this is a known issue >> with generated columns. > > I didn't find related item in open items. This does not seem to be a > known issue. I think we should fix it anyway. > > cc-ing Peter. > > - Richard >
Hi Richard and Satya,
I reproduced the bug following Satya’s procedure and spent some time debugging it.
I think the issue is that rewriteTargetListIU() removes generated columns from the target list, as described by this comment: ``` if (att_tup->attgenerated) { /* * virtual generated column stores a null value; stored generated * column will be fixed in executor */ new_tle = NULL; } ```
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.
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.
Do either of you plan to propose a patch for this? If so, please go ahead and I can review it. Otherwise, I can propose a patch in a couple of days.
