> On Apr 13, 2026, at 10:35, Richard Guo <[email protected]> wrote:
>
> On Mon, Apr 13, 2026 at 10:59 AM SATYANARAYANA NARLAPURAM
> <[email protected]> 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.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
