Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oizAR-000824-MW for pgsql-bugs@arkaria.postgresql.org; Thu, 13 Oct 2022 14:26:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oizAQ-00044N-E1 for pgsql-bugs@arkaria.postgresql.org; Thu, 13 Oct 2022 14:26:34 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oizAQ-00044E-5x for pgsql-bugs@lists.postgresql.org; Thu, 13 Oct 2022 14:26:34 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oizAO-0002AU-2t for pgsql-bugs@lists.postgresql.org; Thu, 13 Oct 2022 14:26:33 +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 29DEQT7w955803; Thu, 13 Oct 2022 10:26:29 -0400 From: Tom Lane To: Richard Guo cc: hctf90@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17637: case-when branches taken even if they dont match, raising errors In-reply-to: References: <17637-5904e3fdee533c7f@postgresql.org> Comments: In-reply-to Richard Guo message dated "Thu, 13 Oct 2022 19:30:53 +0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <955801.1665671189.1@sss.pgh.pa.us> Date: Thu, 13 Oct 2022 10:26:29 -0400 Message-ID: <955802.1665671189@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Richard Guo writes: > On Thu, Oct 13, 2022 at 6:08 PM PG Bug reporting form < > noreply@postgresql.org> wrote: >> with tmp as (select 1::int8 id, '123.4'::text v) >> select t.id, >> case m.mapped_to when 1 then v::float8 else null end, >> case m.mapped_to when 2 then v::bool else null end >> from tmp t >> join tmap m on m.id = t.id; > I'm not sure about this being a bug. I'm not buying it either. The point is that the constants from the WITH clause get pulled up into the outer query, whereupon you have case m.mapped_to when 2 then '123.4'::text::bool else null end and then we apply constant-folding which tries to perform the bool conversion. (There are some folding rules whereby if a WHEN condition reduces to constant true or constant false, we drop all the therefore-unreachable THEN/ELSE arms without folding them --- but that doesn't help here since m.mapped_to isn't a constant.) I'm not especially eager to lobotomize the const-folding rules in order to make toy examples like this one work. I don't think it's representative of real queries; but we *would* be penalizing real queries if we didn't perform such folding. I believe you could dodge the issue in this particular case by marking the WITH query as MATERIALIZED, which'll serve as an optimization fence to prevent the constants from being hoisted into the outer query. regards, tom lane