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 по дате отправления: