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