Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vdCAI-00FAd7-0X for pgsql-general@arkaria.postgresql.org; Tue, 06 Jan 2026 18:52:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vdCAG-00A1Ya-33 for pgsql-general@arkaria.postgresql.org; Tue, 06 Jan 2026 18:52:21 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vdCAG-00A1YR-1v for pgsql-general@lists.postgresql.org; Tue, 06 Jan 2026 18:52:21 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vdCA9-004wlO-2S for pgsql-general@postgresql.org; Tue, 06 Jan 2026 18:52:15 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 606IqCVg1607958; Tue, 6 Jan 2026 13:52:12 -0500 From: Tom Lane To: Eric Ridge cc: pgsql-general , Richard Guo Subject: Re: pg18 bug? SELECT query doesn't work In-reply-to: References: <7900964C-F99E-481E-BEE5-4338774CEB9F@gmail.com> Comments: In-reply-to Eric Ridge message dated "Tue, 06 Jan 2026 10:52:56 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1607956.1767725532.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 06 Jan 2026 13:52:12 -0500 Message-ID: <1607957.1767725532@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Eric Ridge writes: > Here's an even more reduced test case. No tables or data: > # SELECT * FROM (SELECT upper(unnest(ARRAY['cat', 'dog'])) as animal FRO= M 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 FRO= M 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 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