From: Tom Lane <tgl@sss.pgh.pa.us>
To: michael.banck@credativ.de
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19428: Lazy evaluation of type checking in CASE in SQL functions including subqueries no longer works in 18
In-reply-to: <19428-d9ac6c4d84c0bc81@postgresql.org>
References: <19428-d9ac6c4d84c0bc81@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Wed, 11 Mar 2026 16:50:07 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3707.1773251497.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 11 Mar 2026 13:51:37 -0400
Message-ID: <3708.1773251497@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/3708.1773251497%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.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 evaluatio=
n in
> CASE via the subquery to check if the second argument is a valid inet, w=
hich
> 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#FUN=
CTIONS-CASE