| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Damian Lukowski <pgsql-bugs(at)arcsin(dot)de> |
| Cc: | "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #19428: Lazy evaluation of type checking in CASE in SQL functions including subqueries no longer works in 18 |
| Date: | 2026-03-12 12:40:12 |
| Message-ID: | CAKFQuwZN90TwSJJ=1zu88pkkC1e5c_wKDMsO5_849uwa2zDmhQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Thursday, March 12, 2026, Damian Lukowski <pgsql-bugs(at)arcsin(dot)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.
David J.
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Damian Lukowski | 2026-03-12 12:49:44 | Re: BUG #19428: Lazy evaluation of type checking in CASE in SQL functions including subqueries no longer works in 18 |
| Previous Message | PG Bug reporting form | 2026-03-12 12:11:06 | BUG #19431: limitation of the data type jsonb equals 8Kb |