Re: Making CASE error handling less surprising

čt 23. 7. 2020 v 21:43 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:

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.

I am afraid of a performance impact. 

lot of people expects constant folding everywhere now and I can imagine query like

SELECT CASE col1 WHEN 1 THEN upper('hello') ELSE upper('bye')  END FROM ...

Now, it is optimized well, but with the proposed patch, this query can be slow.

We should introduce planner safe functions for some usual functions, or maybe better explain the behaviour, the costs, and benefits.  I don't think this issue is too common.

Regards

Pavel

                        regards, tom lane