Re: BUG #18657: Using JSON_OBJECTAGG with volatile function leads to segfault
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tender Wang <tndrwang@gmail.com>
Cc: Amit Langote <amitlangote09@gmail.com>,
Michael Paquier <michael@paquier.xyz>, exclusion@gmail.com,
pgsql-bugs@lists.postgresql.org
Date: 2024-10-18T01:46:45Z
Lists: pgsql-bugs
Tender Wang <tndrwang@gmail.com> writes: >> In any case, whatever we do in master, you can't "simply revert" >> b6e1157e7 in released branches. It changed the way JsonValueExpr is >> represented in stored rules, and you don't get to undo that midstream. > Sorry, I can't fully understand what you said above. What's the stored > rule? > And "you don't get to undo that midstream." What is the Scenario that we > get to undo? If somebody has created a view that contains a JsonValueExpr, then the post-parse-analysis query tree for that is stored in pg_rewrite. A minor version update can't change that query tree. So basically, once a major version has shipped, its parse-analysis output format is frozen. We can redefine that sort of thing in major releases, because either pg_upgrade or dump/reload will result in re-parsing view definitions. But that doesn't happen in minor-version updates. This restriction doesn't apply to planner output trees, since those don't have any lifespan longer than a session. That's how come it's okay to consider changing the behavior of eval_const_expressions. regards, tom lane
Commits
-
SQL/JSON: Fix some oversights in commit b6e1157e7
- 7148cb3e3067 17.1 landed
- fa4f11854c8b 16.5 landed
- 11c87216d134 18.0 landed
-
Don't include CaseTestExpr in JsonValueExpr.formatted_expr
- b6e1157e7d33 17.0 cited