Re: Making CASE error handling less surprising

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

On 2020-07-23 18:50:32 +0100, Dagfinn Ilmari Mannsåker wrote:
> 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?

That'd require using a subtransaction for expression
simplification. That'd be way too high overhead.

Given how often we've had a need to call functions while handling
errors, I do wonder if it'd be worthwhile and feasible to mark functions
as being safe to call without subtransactions, or mark them as not
erroring out (e.g. comparators would usually be safe).

Greetings,

Andres Freund



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: HOT vs freezing issue causing "cannot freeze committed xmax"
Следующее
От: Andres Freund
Дата:
Сообщение: heap_abort_speculative() sets xmin to Invalid* without HEAP_XMIN_INVALID