Eric Ridge <[email protected]> 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 <[email protected]> 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
