| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | michael(dot)banck(at)credativ(dot)de |
| Cc: | 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-11 17:51:37 |
| Message-ID: | 3708.1773251497@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> A colleague has complained to me that the following (minimal reproducer he
> could come up with) worked on pre-18, but no longer does on 18:
> ...
> SELECT CASE
> WHEN selector IS NULL THEN $1::text
> ELSE $1::inet::text
> END
> ...
> I bisected this to 0dca5d68d7b. Looks like they depend on lazy evaluation in
> CASE via the subquery to check if the second argument is a valid inet, which
> no longer works after 0dca5d68d7b. Is that an intended change?
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.
You could possibly make this logic work reliably by wrapping
the cast-to-inet part in a volatile plpgsql function.
regards, tom lane
[1] https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-CASE
| From | Date | Subject | |
|---|---|---|---|
| Next Message | surya poondla | 2026-03-12 00:45:28 | Re: Two issues with REFRESH MATERIALIZED VIEW CONCURRENTLY |
| Previous Message | PG Bug reporting form | 2026-03-11 16:50:07 | BUG #19428: Lazy evaluation of type checking in CASE in SQL functions including subqueries no longer works in 18 |