Re: BUG #19353: Error XX000 if referencing expanded array in grouping set: variable not found in subplan target list
| От | Richard Guo |
|---|---|
| Тема | Re: BUG #19353: Error XX000 if referencing expanded array in grouping set: variable not found in subplan target list |
| Дата | |
| Msg-id | CAMbWs48jBYroJ90kc9uxNNQbwniQ4-Cg_+FnOYtSXS42_OOCCA@mail.gmail.com обсуждение исходный текст |
| Ответ на | BUG #19353: Error XX000 if referencing expanded array in grouping set: variable not found in subplan target list (PG Bug reporting form <noreply@postgresql.org>) |
| Список | pgsql-bugs |
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. 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
В списке pgsql-bugs по дате отправления: