| From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
|---|---|
| To: | Tender Wang <tndrwang(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, marian(dot)muller(at)serli(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19353: Error XX000 if referencing expanded array in grouping set: variable not found in subplan target list |
| Date: | 2025-12-24 02:15:34 |
| Message-ID: | CAMbWs48jBYroJ90kc9uxNNQbwniQ4-Cg_+FnOYtSXS42_OOCCA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Mon, Dec 15, 2025 at 11:28 PM Richard Guo <guofenglinux(at)gmail(dot)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.
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.
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.
Could someone confirm if this is ABI safe? I don't want to cause ABI
troubles in back branches.
- Richard
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tender Wang | 2025-12-24 02:40:00 | Re: BUG #19353: Error XX000 if referencing expanded array in grouping set: variable not found in subplan target list |
| Previous Message | Andrey Rachitskiy | 2025-12-23 19:02:57 | Re: BUG #19362: Extremely log processing of jsonb_path_exists_opr |