Hi Chao, On Mon, Apr 13, 2026 at 12:21 AM Chao Li <[email protected]> wrote:
> > > > 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. I have a patch with me, let me post it shortly. Thanks, Satya
