Re: Making CASE error handling less surprising

Hi,

On 2020-07-23 21:56:26 +0200, Pavel Stehule wrote:
> I am afraid of a performance impact.
>
> lot of people expects constant folding everywhere now and I can imagine
> query like
>
> SELECT CASE col1 WHEN 1 THEN upper('hello') ELSE upper('bye') END FROM ...
>
> Now, it is optimized well, but with the proposed patch, this query can be
> slow.

I'd be more concerned about thinks like conditional expressions that
involve both columns and non-comparison operations on constants. Where
right now we'd simplify the constant part of the expression, but
wouldn't at all anymore after this.

Is there an argument to continue simplifying expressions within case
when only involving "true" constants even with not leakproof functions,
but only simplify "pseudo" constants like parameters with leakproof
functions? I.e CASE WHEN ... THEN 1 / 0 would still raise an error
during simplification but CASE WHEN ... THEN 1 / $1 wouldn't, because $1
is not a real constant (even if PARAM_FLAG_CONST).

It doesn't seem like it'd be too hard to implement that, but that it'd
probably be fairly bulky because we'd need to track more state across
recursive expression_tree_mutator() calls.

Greetings,

Andres Freund