Re: Making CASE error handling less surprising - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Making CASE error handling less surprising
Date
Msg-id 273625.1595533424@sss.pgh.pa.us
Whole thread Raw
In response to Re: Making CASE error handling less surprising  (Andres Freund <andres@anarazel.de>)
Responses Re: Making CASE error handling less surprising
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: heap_abort_speculative() sets xmin to Invalid* without HEAP_XMIN_INVALID
Next
From: Pavel Stehule
Date:
Subject: Re: Making CASE error handling less surprising