Re: Making CASE error handling less surprising - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Making CASE error handling less surprising
Date
Msg-id 20200723202141.nf2wmijsqm45njsy@alap3.anarazel.de
Whole thread Raw
In response to Re: Making CASE error handling less surprising  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Making CASE error handling less surprising
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Making CASE error handling less surprising
Next
From: Tom Lane
Date:
Subject: Re: Making CASE error handling less surprising