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  (Pavel Stehule <pavel.stehule@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Soumyadeep Chakraborty
Дата:
Сообщение: Re: [Patch] ALTER SYSTEM READ ONLY
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Improving connection scalability: GetSnapshotData()