Re: Bug: Rule actions see wrong values for generated columns (NEW.gen reads OLD value)
Richard Guo <guofenglinux@gmail.com>
From: Richard Guo <guofenglinux@gmail.com>
To: Dean Rasheed <dean.a.rasheed@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>
Date: 2026-04-20T05:25:43Z
Lists: pgsql-hackers
On Fri, Apr 17, 2026 at 7:35 PM Dean Rasheed <dean.a.rasheed@gmail.com> wrote: > I don't quite buy the argument that the rule action is typically > small. We have no idea how big it might be. Note that, at that point > in the code, sub_action is the combination of both the original query > and the rule action. > > I do accept though that rules are not widely used, and that it's not > worth optimising too much, if it means a lot of extra complexity. > However, IMO, it is slightly simpler and neater to put the expanded > generated columns in the replacement list used by > ReplaceVarsFromTargetList() on sub_action. Fair point. > In the attached v2 patch, I've done that by refactoring > expand_generated_columns_internal(), renaming it to > get_generated_columns(), and making it just return the list of > generated column expressions, rather than doing the rewrite -- I never > particularly liked the separation of concerns between > expand_generated_columns_internal() and > expand_generated_columns_in_expr(), especially after the rest of the > code expanding virtual generated columns was moved out of the > rewriter, so that expand_generated_columns_in_expr() became the only > caller of expand_generated_columns_internal(). Doing this simplifies > the function, since it's no longer necessary to pass it node, rte, and > result_relation. > > With that change, all rewriteRuleAction() needs to do is get the > generated columns, rewrite any new.attribute references in them, and > then use that list plus the original target list as the replacement > list when rewriting sub_action. Yeah, this is a better approach. The change looks good to me. A nitpick: For the comment "The generated column expressions typically refer to new.attribute ...", maybe we can remove "typically", as generation expressions always refer to columns of the same relation. - Richard
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix incorrect NEW references to generated columns in rule rewriting
- 8e39951beac7 14.23 landed
- 7062bd577ec9 15.18 landed
- 07b257189ea4 16.14 landed
- 9d6208939a0a 17.10 landed
- e528bfe97190 18.4 landed
- c6a79be3f3c7 19 (unreleased) landed