Re: Making CASE error handling less surprising

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Making CASE error handling less surprising
Дата
Msg-id 4060488F-D808-4CFB-8FDB-E0BD9F228C10@anarazel.de
обсуждение исходный текст
Ответ на Re: Making CASE error handling less surprising  (Pavel Stehule <pavel.stehule@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Making CASE error handling less surprising
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Making CASE error handling less surprising