Re: pg18 bug? SELECT query doesn't work
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Eric Ridge <eebbrr@gmail.com>
Cc: pgsql-general <pgsql-general@postgresql.org>,
Richard Guo <guofenglinux@gmail.com>
Date: 2026-01-06T18:52:12Z
Lists: pgsql-hackers, pgsql-general
Eric Ridge <eebbrr@gmail.com> writes:
> Here's an even more reduced test case. No tables or data:
> # SELECT * FROM (SELECT upper(unnest(ARRAY['cat', 'dog'])) as animal FROM generate_series(1, 10) GROUP BY 1) x WHERE animal ilike 'c%';
> pg15 returns:
> animal
> --------
> CAT
> (1 row)
> and pg18 says:
> # SELECT * FROM (SELECT upper(unnest(ARRAY['cat', 'dog'])) as animal FROM generate_series(1, 10) GROUP BY 1) x WHERE animal ilike 'c%';
> ERROR: set-valued function called in context that cannot accept a set
> LINE 1: SELECT * FROM (SELECT upper(unnest(ARRAY['cat', 'dog'])) as ...
> ^
I agree that this is a bug. "git bisect" says it broke at
247dea89f7616fdf06b7272b74abafc29e8e5860 is the first bad commit
commit 247dea89f7616fdf06b7272b74abafc29e8e5860 (HEAD)
Author: Richard Guo <rguo@postgresql.org>
Date: Tue Sep 10 12:35:34 2024 +0900
Introduce an RTE for the grouping step
I've not probed further than that, but my guess is that now we check
for set-returning tlist items while the tlist still has grouping Vars,
thus missing the fact that there's a SRF represented by one of those
Vars. This prompts us to flatten a subquery we shouldn't have
flattened (because that ends by introducing a SRF into the outer
WHERE).
regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix unsafe pushdown of quals referencing grouping Vars
- 7650eabb662f 18.2 landed
- 34740b90bc12 19 (unreleased) landed
-
Introduce an RTE for the grouping step
- 247dea89f761 18.0 cited