|From:||ilmari(at)ilmari(dot)org (Dagfinn Ilmari Mannsåker )|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Subject:||Re: Making CASE error handling less surprising|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Every so often we get a complaint like  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.
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?
"A disappointingly low fraction of the human race is,
at any given time, on fire." - Stig Sandbeck Mathisen
|Next Message||Andres Freund||2020-07-23 18:00:59||Re: 'with' regression tests fails rarely (and spuriously)|
|Previous Message||Anastasia Lubennikova||2020-07-23 17:39:11||[BUG] Error in BRIN summarization|