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 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
