Re: BUG #12273: CASE Expression BUG

David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> "so that the principle that <quote><token>CASE</token>
> does not evaluate any subexpressions that are not needed to determine
> the result</quote> is not ironclad."

> so the principle that [...] only evaluates necessary subexpressions is not
> ironclad.

OK, done that way.

> The problem with your example is that the following does not error:

> SELECT CASE WHEN false THEN 1/0 ELSE 1 END;

That's why that isn't the example ;-). In this case, since the WHEN is a
constant, the constant-expression simplifier itself figures out that it
can throw away the THEN expression and replace the whole CASE with the
ELSE expression. So it doesn't bother const-simplifying the THEN, hence
no error.

> While it is a great word I don't really believe "panacea" is good for our
> documentation given the diverse English language experiences of its readers.

Hm. "cure-all" maybe?

> "the values of function parameters" == "function arguments" ... though not
> everyone is fully aware (or remembers) the difference between arguments and
> parameters.

OK.

> "Thus for example in [...] functions..." -> Therefore, in [...] functions
> it is more reliable to use an [...] statement to protect a risky [...]
> statement compared to using a nested CASE expression.

Meh. The same principle applies in other languages too, so I don't think
your wording is an improvement.

regards, tom lane