On Fri, Jul 3, 2026 at 5:36 PM Thom Brown <thom@linux.com> wrote:
> Thanks for taking a look at this. It's unfortunate that reconstructing
> the syntax is problematic, because in the case of the original query
> that tripped on this bug, I lose the following from my original query:
> ...
> I guess the relevant information can be gleaned from this, but not for
> JSON_ARRAYAGG(i RETURNING text) because we get the same output whether
> we're returning text or json.
Yeah, the v1 patch is lossy, and the lost information cannot be
recovered from the plan at all.
So I'm switching back to the resolve_special_varno() reconstruction I
had tried and set aside. My earlier objection was that it makes the
WindowAgg look like it computes a JSON aggregate when it only passes
through a value computed below. But the lower node still prints
jsonb_agg_strict(name), so the plan does show where the aggregate is
computed, and I think that is a smaller cost than losing the
information outright. Also, partial aggregation already deparses this
way. The combining aggregate's argument is a Var referencing the
partial aggregate's output, and get_agg_expr() resolves it back with
resolve_special_varno() to reprint the aggregate at the finalizing
node.
I still don't want to hack the planner to keep the JsonConstructorExpr
with its Aggref in make_window_input_target(), because I still think
that that is too invasive and changes which node evaluates the
wrapper.
Hence, I end up with the attached v2 patch.
- Richard
