Re: BUG #19353: Error XX000 if referencing expanded array in grouping set: variable not found in subplan target list

On Sat, Dec 13, 2025 at 7:02 PM Tender Wang <tndrwang(at)gmail(dot)com> wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 于2025年12月13日周六 00:54写道：
>> PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
>> > After upgrading to Postgres 18 I've come across an error I wasn't getting
>> > beforehand. Here's a minimal way to reproduce the issue, that used to work
>> > well in Postgres 12 and 17 at least.

>> Thank you for this well-crafted bug report! Bisecting shows that
>> it broke at
>>
>> f5050f795aea67dfc40bbc429c8934e9439e22e7 is the first bad commit
>> commit f5050f795aea67dfc40bbc429c8934e9439e22e7 (HEAD)
>> Author: Richard Guo <rguo(at)postgresql(dot)org>
>> Date: Tue Sep 10 12:36:48 2024 +0900
>>
>> Mark expressions nullable by grouping sets

> When there is SRF in the query, the grouping_target changes in grouping_planner when entering the following function:
> split_pathtarget_at_srfs(root, grouping_target, scanjoin_target,
> &grouping_targets,
> &grouping_targets_contain_srfs);

Yeah, the issue happens here. In split_pathtarget_at_srfs(), if we
find a subexpression that matches an expression already computed in
the previous plan level, we should treat it as a Var and should not
split it further. setrefs.c will later replace the expression with a
Var referencing the subplan output.

However, when processing the grouping target for grouping sets, this
function can fail to recognize that an expression is already computed
in the scan/join phase. This happens because the comparison crosses
the grouping boundary: expressions in the grouping target may carry
the grouping nulling bit, while the corresponding expressions in the
scan/join target do not.

This mismatch leads this function to incorrectly assume that the
expression (e.g., unnest(markets)) needs to be re-evaluated from its
arguments, which are often unavailable in the subplan.

To fix, I think we should ignore the grouping nulling bit when
checking if an expression from the grouping target is available in the
pre-grouping input target. This is actually what we do in setrefs.c.

Hence, attached patch.

(I'm currently on vacation and will take a closer look when I return.
Anyone who wants to move this forward before then is welcome.)

- Richard