| From: | Thom Brown <thom(at)linux(dot)com> |
|---|---|
| To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
| Cc: | pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: EXPLAIN (VERBOSE) fails with for JSON_ARRAYAGG/JSON_OBJECTAGG + window function |
| Date: | 2026-07-07 13:49:23 |
| Message-ID: | CAA-aLv5Tybb_PAG8vmxB8KJXNgwqEBtAnd_nneP2YNahxs9irg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Mon, 6 Jul 2026 at 03:17, Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
>
> On Fri, Jul 3, 2026 at 5:36 PM Thom Brown <thom(at)linux(dot)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.
I've tested it against the output from the 1st patch.
Patch 1:
((jsonb_agg_strict(e.emp_name ORDER BY e.emp_name)))
Patch 2:
(JSON_ARRAYAGG(e.emp_name ORDER BY e.emp_name RETURNING jsonb))
1:
((jsonb_object_agg_strict(e.emp_name, e.salary)))
2:
(JSON_OBJECTAGG(e.emp_name : e.salary ABSENT ON NULL RETURNING jsonb))
With that last one, why is that colon there?
Thom
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2026-07-07 14:13:44 | BUG #19545: Integer truncation of `GinTuple.keylen` causes out-of-bounds read in parallel GIN index build |
| Previous Message | David Rowley | 2026-07-07 12:02:30 | Re: BUG #19533: Wrong results from WindowAgg run-condition pushdown on count() with EXCLUDE CURRENT ROW |