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 1w0fKs-0026WF-2G for pgsql-bugs@arkaria.postgresql.org; Thu, 12 Mar 2026 12:40:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w0fKr-00Et7I-07 for pgsql-bugs@arkaria.postgresql.org; Thu, 12 Mar 2026 12:40:17 +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 1w0fKq-00Et79-2W for pgsql-bugs@lists.postgresql.org; Thu, 12 Mar 2026 12:40:17 +0000 Received: from mail-oa1-x31.google.com ([2001:4860:4864:20::31]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w0fKp-00000002IbZ-0K4T for pgsql-bugs@lists.postgresql.org; Thu, 12 Mar 2026 12:40:17 +0000 Received: by mail-oa1-x31.google.com with SMTP id 586e51a60fabf-4138136f02eso733935fac.2 for ; Thu, 12 Mar 2026 05:40:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773319213; cv=none; d=google.com; s=arc-20240605; b=leJDuHMkbimqlhR//LJZGUzIw7O2nPQv652bsk1Oid/IAlOH+KAus2FOPCOOH4OYin N1K77MUe7Zsbq/yUrYED9vrQ07mNwOh1NZsfhAO+RqpAndFEx2lFPl0WG8pK+MhrS7se UG0ler7zSgvZ5+USvZ1srV6ZtXrutkh/7gUPRtaDbhyWaCYVsBEwa/9jPzB1qmu9Eo2/ 3lzXBNe5kRz735W7qFkt38hqMWnu4ku9w7cG1nkvD4qAF6vBXgJoC04n95Ifc4Iamslg geECJMWx6dxTs2m9gG77zQk8toLIOQuRa4R5uEn3yV5VUcOIt9jPPYsD9Qyw5v0tVrLQ LPJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:dkim-signature; bh=KZ4Wr9+YwpPSu1mHV3z/rZukYAeXuU5hTaybGjRARUw=; fh=i8Hv2Ff3w6ZJaJDk6FeiwN4AVwxfFDkxoI5FfF/IDDU=; b=Xvuw+3uJrpoXXN4kw3L1a7u6s3xIHEGX82QZcVBRQg1rNDGon7V/s26/Qvz/d0x4qD oyaQd6CygE+CoBa5en8aH1B1/VzJiZo9Rp4BDhOL6425JK2WfH0Ua7H+P6ZlqQ+3uIpW 8IBmhSwev/HLnDjk/THMJPxZeeaLzfK+RGjSybtzux7ZwOMXi9nqUnFEPKn89eOy7tNr /5WSdWkM8hebjCt1TwG08bTnrjBBWMiPbledmaSvd1lyOg7beR2U1sXne4HUlnILG5QN e+frzz/0XDFEvRX6CvIBjMsm2XJVyLo1r+3ibKtUEb703rh2Rn8GZhuMTGW8jqAgIgct xw3Q==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773319213; x=1773924013; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KZ4Wr9+YwpPSu1mHV3z/rZukYAeXuU5hTaybGjRARUw=; b=FVwxoDgFCin78o8UstyF88D6jEpytffIk4/4i+41klCs9qR9XJFgCZUhG0X9epYApb fu2OaHOk1y6XKyACFGaVpaXU4OPsgxslO3Oz8qMjxYQIxIlZT2GCYzmpuYp85myx4Fd9 M8vtSeS4ySl0PsAYvF3I34pd0pEqg/KkKy0j5agNTn1q+4V2bXpG+OqOjVgm/TUI5CNZ Wg+iwVtA+9eleyJX9Hgemzcj0tcwadN22rZ9F4FyRbr4q7ypKeZcbp6A+H+rkgDbU05A Np5zA8jA/ONyf0E8sqtZBt3LjVStS1A/ScccA9VsEVrusokpWhuSMUy7IaF4AbfTBX8v iIPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773319213; x=1773924013; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=KZ4Wr9+YwpPSu1mHV3z/rZukYAeXuU5hTaybGjRARUw=; b=MTZIOmQrown9lfbXpbNSNvtxGQQNP2DWfST/bZ8yYL1BjoOYimsnLnwdeooisU6Xf2 Ak8UTkkWBdc4TYd41FK7qWH5GOQRFcAJSXndzz/PnrU46VEuvLQgHzDOAHC5xHJve1tk e96RiDVlucvsnMj2ZJ2SY9c8FwVrJDd4tIYE4eE7JQwF3wb0HBsUdzWPC58IFJJGcrM9 go/3FEPx7VcnJuuaYufYwn4O9feUgaCmFKdXcZsqIKj8c+R51b79ULVKQN8+ypu+iMgh pBe8ddfSeIK5eg3yiXu121XLz3WMlAcluSCIPRgbt1dpSumE1+sAHKV6zdUn8eHL+B51 QNjA== X-Gm-Message-State: AOJu0YxuIcbuqTplX3HtDCNMVe12mpPaF5rjD7lZuJt684OqtwAZBOkX dGyu/6b5I9Bu6oyNSUA+ozJSmh3uFX//G0IEjxCk7twrMFrBBGQJP3v2NVtYX8W2YHRJvF/FRGG VZko5jzUYAvIA8LZu6xqxLAZxNXAVCBPNyBKa X-Gm-Gg: ATEYQzyEPVVAaDp3eSyKdIfXVIrnmfDsSwSDeyzQkIfoFn+bYxAv9goOOa3EyoQpg1v 5MQZJnYUFdzDWhtO7kxBSUiGy31JcK3BrKAwWuSH43Q9BB+tOy67lMFIDHvtiN/tH+L7QwaEp4f RVjbchR7Eldk36IqCibP1m//wc4KqxFsosIo5uKp6huHSTjJOBbAeiFjaQxKCs2dzpEnse+T0Jy SR6Es27z+V/ZYIsKcYltc0gikCdUVXFkH2DWWoPVTdKAcB52FCgl7VEQW2Jb0R5dZXNgv+r2YbN O1wH X-Received: by 2002:a05:6820:220a:b0:67b:baca:a49b with SMTP id 006d021491bc7-67bc8a422aemr3859203eaf.67.1773319213147; Thu, 12 Mar 2026 05:40:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:5792:0:b0:625:1b10:199 with HTTP; Thu, 12 Mar 2026 05:40:12 -0700 (PDT) In-Reply-To: References: <19428-d9ac6c4d84c0bc81@postgresql.org> <3708.1773251497@sss.pgh.pa.us> From: "David G. Johnston" Date: Thu, 12 Mar 2026 05:40:12 -0700 X-Gm-Features: AaiRm522a2H9PRlstlic82fdyWWUHkxxfhe7EP0f8PNBMpAVgNJ2sqqULdPP1HE Message-ID: Subject: Re: BUG #19428: Lazy evaluation of type checking in CASE in SQL functions including subqueries no longer works in 18 To: Damian Lukowski Cc: "pgsql-bugs@lists.postgresql.org" Content-Type: multipart/alternative; boundary="000000000000c5ec17064cd30dd6" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000c5ec17064cd30dd6 Content-Type: text/plain; charset="UTF-8" On Thursday, March 12, 2026, Damian Lukowski wrote: > We have never promised to avoid constant-folding within the > subexpressions of a CASE [1]. So it was pure accident that > this example worked before, and I don't think it's a bug that > it doesn't work now. > > For a better understanding, which one is the constant that is being > folded? I have found several articles explaining constant folding but their > examples are obvious, e.g. `7 + 1` can be folded to `8` [1, 2], or `1 = 1` > can be folded to `TRUE` [3]. > > However, I have not found any articles that resemble this case. Aren't > `arg` and `$1` variables? Where is the boundary between constants and > non-constants? > The system is capable of postponing planning until (or performing replanning) after parameter values are known, in which the values they are given are constants. David J. > --000000000000c5ec17064cd30dd6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thursday, March 12, 2026, Damian Lukowski <pgsql-bugs@arcsin.de> wrote:
=20 =20 =20
We have never promised to avoid constant-folding within the
subexpressions of a CASE [1].  So it was pure accident that
this example worked before, and I don't think it's a bug that
it doesn't work now.

For a better understanding, which one is the constant that is being folded? I have found several articles explaining constant folding but their examples are obvious, e.g. `7 + 1` can be folded to `8` [1, 2], or `1 =3D 1` can be folded to `TRUE` [3].

However, I have not found any articles that resemble this case. Aren't `arg` and `$1` variables? Where is the boundary between constants and non-constants?

The system is= capable of postponing planning until (or performing replanning) after para= meter values are known, in which the values they are given are constants.

David J.

--000000000000c5ec17064cd30dd6--