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