]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Fix EXPLAIN failure when deparsing SQL/JSON aggregates
authorRichard Guo <rguo@postgresql.org>
Tue, 7 Jul 2026 23:46:43 +0000 (08:46 +0900)
committerRichard Guo <rguo@postgresql.org>
Tue, 7 Jul 2026 23:48:29 +0000 (08:48 +0900)
commiteaa561fb6e278ed7ce293ed7d1e7ddaa7354180b
tree83cdb441e1df6b585ad0478d5b2cadef2162df25
parent28d498e28031f026b8416a4c8439ddda62dfb00f
Fix EXPLAIN failure when deparsing SQL/JSON aggregates

If an expression containing an aggregate is evaluated above the plan
node that computes the aggregate, as happens with window functions or
with expressions postponed to above the final sort, setrefs.c replaces
the Aggref or WindowFunc with a Var referencing the lower node's
output.  For SQL/JSON aggregates such as JSON_ARRAYAGG and
JSON_OBJECTAGG, deparsing the containing JsonConstructorExpr then
failed with "invalid JsonConstructorExpr underlying node type", since
get_json_agg_constructor() did not expect a Var there.

Fix by resolving the Var back to the underlying Aggref or WindowFunc
and deparsing the constructor as if the aggregate were computed at the
current node.  The JsonConstructorExpr retains the RETURNING clause
and the ABSENT/NULL ON NULL and WITH UNIQUE options, and the arguments
come from the resolved aggregate, so the original JSON aggregate
syntax is reproduced in full.  This mirrors how get_agg_expr() already
looks through such a Var when deparsing a combining aggregate.

Reported-by: Thom Brown <thom@linux.com>
Author: Richard Guo <guofenglinux@gmail.com>
Discussion: https://postgr.es/m/CAA-aLv5QYTaMOk=Qhv6cgwceeHETZV8YJvWZ_rH+yVZCuchATA@mail.gmail.com
Backpatch-through: 16
src/backend/utils/adt/ruleutils.c
src/test/regress/expected/sqljson.out
src/test/regress/sql/sqljson.sql