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 1w0iFU-00294L-0E for pgsql-bugs@arkaria.postgresql.org; Thu, 12 Mar 2026 15:46:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w0iFQ-00Fk6K-0V for pgsql-bugs@arkaria.postgresql.org; Thu, 12 Mar 2026 15:46:52 +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 1w0iFP-00Fk6C-2w for pgsql-bugs@lists.postgresql.org; Thu, 12 Mar 2026 15:46:52 +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.98.2) (envelope-from ) id 1w0iFO-00000002JvP-0Rv1 for pgsql-bugs@lists.postgresql.org; Thu, 12 Mar 2026 15:46:52 +0000 Received: from pro.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 62CFkYvV1476431; Thu, 12 Mar 2026 11:46:34 -0400 From: Tom Lane To: "David G. Johnston" cc: Damian Lukowski , "pgsql-bugs@lists.postgresql.org" Subject: Re: BUG #19428: Lazy evaluation of type checking in CASE in SQL functions including subqueries no longer works in 18 In-reply-to: References: <19428-d9ac6c4d84c0bc81@postgresql.org> <3708.1773251497@sss.pgh.pa.us> <0c78c92b-e3f5-42b6-a698-48855a1bd23b@arcsin.de> Comments: In-reply-to "David G. Johnston" message dated "Thu, 12 Mar 2026 06:29:31 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4502.1773330394.1@sss.pgh.pa.us> Date: Thu, 12 Mar 2026 11:46:34 -0400 Message-ID: <4503.1773330394@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > On Thursday, March 12, 2026, Damian Lukowski wrote: >> The `data` table could have millions of rows. Is the planner invoked for >> every actual call to `func`, or only once before any pages are read? > IIRC the first five invocations will get replanned using the parameter as a > constant; then after either every call will be replanned or none will. Read up on custom vs. generic plans for some more background on this. That behavior used to apply only to plpgsql functions, but since v18 SQL-language functions do it too. regards, tom lane