Re: Bug: Rule actions see wrong values for generated columns (NEW.gen reads OLD value) - Mailing list pgsql-hackers

From Chao Li
Subject Re: Bug: Rule actions see wrong values for generated columns (NEW.gen reads OLD value)
Date
Msg-id 22B4A33A-99F3-46F5-BE0C-426A9E1D9ABA@gmail.com
Whole thread Raw
In response to Re: Bug: Rule actions see wrong values for generated columns (NEW.gen reads OLD value)  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: Bug: Rule actions see wrong values for generated columns (NEW.gen reads OLD value)
List pgsql-hackers

> 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
UPDATErules, the missing NEW column is handled with REPLACEVARS_CHANGE_VARNO, so it falls back to referencing the
originaltarget 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
thesolution 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
apatch in a couple of days. 

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/







pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Use XLogRecPtrIsValid() instead of negated XLogRecPtrIsInvalid
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: parallel data loading for pgbench -i