Re: Making CASE error handling less surprising

Hi,

On 2020-07-23 15:43:44 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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.

I guess we could optimize it to be one subtransaction by having error
recovery be to redo simplification with a parameter that prevents doing
simplification within CASE etc. Still too unattractive performancewise
to consider imo.

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

Hm, I didn't consider that. Good idea.

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

A quick look through the list seems to confirm that. There's errors like
in text_starts_with:

if (mylocale && !mylocale->deterministic)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("nondeterministic collations are not supported for substring searches")));

but that's not a content dependent error, so I don't think it's problem.

So the idea would be to continue to do simplification like we do right
now for things outside a CASE but to only call leakproof functions
within a case?

Is there any concern about having to do additional lookups for
leakproofness? It doesn't seem likely to me since we already need to do
lookups for the FmgrInfo?

Greetings,

Andres Freund