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 →
  1. Fix unsafe pushdown of quals referencing grouping Vars

  2. Introduce an RTE for the grouping step