Re: BUG #19428: Lazy evaluation of type checking in CASE in SQL functions including subqueries no longer works in 18

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.

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?

[1] https://www.cybertec-postgresql.com/en/how-the-postgresql-query-optimizer-works/
[2] https://www.oreilly.com/library/view/mastering-postgresql-12/9781838988821/b44dc21f-cefa-464a-82e1-391b84fc9f40.xhtml
[3] https://medium.com/@ukhore/deep-dive-postgresql-query-execution-mechanisms-777a79d8caf0