Content-Type: multipart/alternative;
 boundary="------------ypLnbivVHkRyIKzX600txxLm"
Message-ID: <0c78c92b-e3f5-42b6-a698-48855a1bd23b@arcsin.de>
Date: Thu, 12 Mar 2026 13:49:44 +0100
MIME-Version: 1.0
From: Damian Lukowski <pgsql-bugs@arcsin.de>
Subject: Re: BUG #19428: Lazy evaluation of type checking in CASE in SQL
 functions including subqueries no longer works in 18
To: "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
References: <19428-d9ac6c4d84c0bc81@postgresql.org>
 <3708.1773251497@sss.pgh.pa.us>
 <fac48759-8d95-41c2-a52f-19c6cb0c837a@arcsin.de>
 <CAKFQuwZN90TwSJJ=1zu88pkkC1e5c_wKDMsO5_849uwa2zDmhQ@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAKFQuwZN90TwSJJ=1zu88pkkC1e5c_wKDMsO5_849uwa2zDmhQ@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/0c78c92b-e3f5-42b6-a698-48855a1bd23b%40arcsin.de>
Precedence: bulk

This is a multi-part message in MIME format.
--------------ypLnbivVHkRyIKzX600txxLm
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

> On Thursday, March 12, 2026, Damian Lukowski <pgsql-bugs@arcsin.de> 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.
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?
--------------ypLnbivVHkRyIKzX600txxLm
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <blockquote type="cite"
cite="mid:CAKFQuwZN90TwSJJ=1zu88pkkC1e5c_wKDMsO5_849uwa2zDmhQ@mail.gmail.com">On
      Thursday, March 12, 2026, Damian Lukowski &lt;<a
        href="mailto:pgsql-bugs@arcsin.de" moz-do-not-send="true"
        class="moz-txt-link-freetext">pgsql-bugs@arcsin.de</a>&gt;
      wrote:<br>
      <blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
        <div>
          <blockquote type="cite">
            <pre>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.</pre>
          </blockquote>
          <p>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].</p>
          <p>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?</p>
        </div>
      </blockquote>
      <div>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.</div>
    </blockquote>
    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?
  </body>
</html>

--------------ypLnbivVHkRyIKzX600txxLm--