Re: Making CASE error handling less surprising
| От | Andres Freund |
|---|---|
| Тема | Re: Making CASE error handling less surprising |
| Дата | |
| Msg-id | 20200724171345.cdbazcpe7rl2zlez@alap3.anarazel.de обсуждение исходный текст |
| Ответ на | Re: Making CASE error handling less surprising (Pavel Stehule <pavel.stehule@gmail.com>) |
| Ответы |
Re: Making CASE error handling less surprising
|
| Список | pgsql-hackers |
Hi,
On 2020-07-24 19:03:30 +0200, Pavel Stehule wrote:
> pá 24. 7. 2020 v 18:49 odesílatel Andres Freund <andres@anarazel.de> napsal:
> > Wouldn't the rule that I proposed earlier, namely that sub-expressions
> > that involve only "proper" constants continue to get evaluated even
> > within CASE, largely address that?
> >
>
> It doesn't solve a possible performance problem with one shot (EXECUTE stmt
> plpgsql) queries, or with parameterized queries
What precisely are you thinking of here? Most expressions involving
parameters would still get constant evaluated - it'd just be inside CASE
etc that they wouldn't anymore? Do you think it's that common to have a
parameter reference inside an expression inside a CASE where it's
crucial that that parameter reference gets constant evaluated? I'd think
that's a bit of a stretch.
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?
Greetings,
Andres Freund
В списке pgsql-hackers по дате отправления: