Re: Making CASE error handling less surprising

Поиск
Список
Период
Сортировка
От ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)
Тема Re: Making CASE error handling less surprising
Дата
Msg-id 878sfajf2v.fsf@wibble.ilmari.org
обсуждение исходный текст
Ответ на Making CASE error handling less surprising  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Making CASE error handling less surprising  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Every so often we get a complaint like [1] about how a CASE should have
> prevented a run-time error and didn't, because constant-folding tried
> to evaluate a subexpression that would not have been entered at run-time.
>
> It struck me that it would not be hard to improve this situation a great
> deal.  If, within a CASE subexpression that isn't certain to be executed
> at runtime, we refuse to pre-evaluate *any* function (essentially, treat
> them all as volatile), then we should largely get the semantics that
> users expect.  There's some potential for query slowdown if a CASE
> contains a constant subexpression that we formerly reduced at plan time
> and now do not, but that doesn't seem to me to be a very big deal.
[…]
> Thoughts?

Would it be feasible to set up an exception handler when constant-
folding cases that might not be reached, and leave the expression
unfolded only if an error was thrown, or does that have too much
overhead to be worthwhile?

- ilmari
-- 
"A disappointingly low fraction of the human race is,
 at any given time, on fire." - Stig Sandbeck Mathisen



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Anastasia Lubennikova
Дата:
Сообщение: [BUG] Error in BRIN summarization
Следующее
От: Andres Freund
Дата:
Сообщение: Re: 'with' regression tests fails rarely (and spuriously)