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: Amit Langote <amitlangote09@gmail.com>
Cc: Tender Wang <tndrwang@gmail.com>, Michael Paquier <michael@paquier.xyz>,
exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2024-10-17T20:30:17Z
Lists: pgsql-bugs
Amit Langote <amitlangote09@gmail.com> writes: > On Thu, Oct 17, 2024 at 1:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> In the short term, I suspect the only workable fix is to undo the >> optimization of having ExecInitExprRec not recurse into both raw_expr >> and formatted_expr. > This or actually I'm tempted to simply revert the whole thing > (b6e1157e7d3) as an ill-considered refactoring, because I am not able > to convince myself that calling ExecAggPlainTransByVal() twice, via > both raw_expr and formatted_expr, is always safe. Not following the concern here? As far as nodeAgg is concerned, they'd be two independent aggregates. 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. (The commit should have included a catversion bump, in fact.) I do think that reverting the ExecInitExprRec and eval_const_expressions_mutator changes would be good, but we can't undo the parser changes, at least not in v16/v17. 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