Re: BUG #16368: Incorrect function inlining in the presence of a window function

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Wed, Apr 15, 2020 at 1:08 PM Elvis Pranskevichus <elprans(at)gmail(dot)com>
> wrote:
>> Consider any other case where an error is guarded by a "CASE WHEN", such
>> as division by zero.

> There aren't all that many and throwing out a perfectly good optimization
> for boundary cases that will error, as opposed to returning but including
> invalid results, isn't that desirable either.

In point of fact, there are many ways in which CASE and related constructs
fail to guarantee evaluation order, as noted in
https://www.postgresql.org/docs/current/sql-expressions.html#SYNTAX-EXPRESS-EVAL

The particular case mentioned there seems to be about the same as here:
constant-folding happens even in CASE arms that will never be reached at
runtime. Problems could happen earlier than that, too. It's not hard to
imagine cases that wouldn't execute "as desired" unless we didn't even do
parse analysis (e.g, subexpression type determination) on a CASE arm until
it's reached at runtime. But we're not going to make that sort of thing
happen; it's just too much contortion and inefficiency for too little
benefit. In particular, people for whom the current implementation works
OK would be quite unhappy with the performance impact of de-optimizing
CASE that way.

regards, tom lane