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

Tender Wang <tndrwang@gmail.com>

From: Tender Wang <tndrwang@gmail.com>
To: Richard Guo <guofenglinux@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, marian.muller@serli.com, pgsql-bugs@lists.postgresql.org
Date: 2025-12-24T02:40:00Z
Lists: pgsql-bugs
Richard Guo <guofenglinux@gmail.com> 于2025年12月24日周三 10:15写道:

> On Mon, Dec 15, 2025 at 11:28 PM Richard Guo <guofenglinux@gmail.com>
> wrote:
> > 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.
>
> Regarding back-patching, we need to pass a new parameter to
> split_pathtarget_at_srfs() to indicate whether we are processing a
> grouping target.  But doing that would break ABI compatibility.
>

Indeed. I ignored this issue.

>
> To avoid this, I refactored the logic into a new static workhorse
> function which accepts the new parameter.  The original
> split_pathtarget_at_srfs() is preserved as a wrapper that calls this
> static function.  I believe this is ABI safe.
>

Yeah, A wrapper function can make the ABI safe.


>
> The patch also introduces a new extern function that calls the
> workhorse with the grouping flag enabled.  Additionally, it adds two
> new fields to struct split_pathtarget_context, but that struct is
> defined entirely within the .c file.
>

It is safe if the struct is only used in a .c file. It would be better to
add a note in the comment for the struct to notice.


> Could someone confirm if this is ABI safe?  I don't want to cause ABI
> troubles in back branches.
>
> - Richard
>


-- 
Thanks,
Tender Wang