Re: Making CASE error handling less surprising

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Making CASE error handling less surprising
Дата
Msg-id 273625.1595533424@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Making CASE error handling less surprising  (Andres Freund <andres@anarazel.de>)
Ответы Re: Making CASE error handling less surprising
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2020-07-23 18:50:32 +0100, Dagfinn Ilmari Mannsåker wrote:
>> 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.

That's my opinion as well.  It'd be a subtransaction for *each*
operator/function call we need to simplify, which seems completely
disastrous.

> 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).

Yeah.  I was wondering whether the existing "leakproof" marking would
be adequate for this purpose.  It's a little stronger than what we
need, but the pain-in-the-rear factor for adding YA function property
is high enough that I'm inclined to just use it anyway.

We do have to assume that "leakproof" includes "cannot throw any
input-dependent error", but it seems to me that that's true.

            regards, tom lane



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: heap_abort_speculative() sets xmin to Invalid* without HEAP_XMIN_INVALID
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: Making CASE error handling less surprising