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

From Andres Freund
Subject Re: Making CASE error handling less surprising
Date
Msg-id 20200723190218.3bpozl3htqt4uaso@alap3.anarazel.de
Whole thread Raw
In response to Re: Making CASE error handling less surprising  (ilmari@ilmari.org (Dagfinn Ilmari Mannsåker))
Responses Re: Making CASE error handling less surprising
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: HOT vs freezing issue causing "cannot freeze committed xmax"
Next
From: Andres Freund
Date:
Subject: heap_abort_speculative() sets xmin to Invalid* without HEAP_XMIN_INVALID