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 4060488F-D808-4CFB-8FDB-E0BD9F228C10@anarazel.de
Whole thread Raw
In response to Re: Making CASE error handling less surprising  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers

On July 24, 2020 10:30:37 AM PDT, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>pá 24. 7. 2020 v 19:13 odesílatel Andres Freund <andres@anarazel.de>
>napsal:
>> Your earlier example of a WHEN ... THEN upper('constant') ... would
>> still have the upper('constant') be evaluated, because it doesn't
>> involve a parameter. And e.g. THEN upper('constant') * $1 would also
>> still have the upper('constant') be evaluated, just the
>multiplication
>> with $1 wouldn't get evaluated.
>>
>>
>> I'm not sure what you're concerned about with the one-shot bit?
>>
>
>Now query parameters are evaluated like constant.

How's that related to oneeshot plans?

>I can imagine WHERE clause like WHERE col = CASE  $1 WHEN true THEN
>upper($2) ELSE $2 END
>
>I remember applications  that use these strange queries to support
>parameterized behaviour - like case sensitive or case insensitive
>searching.

I don't buy this as a significant issue. This could much more sensibly be written as an OR. If the policy is that we
cannotregress anything then there's no way we can improve at all. 

Andres

Andres

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.



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