From: | ilmari(at)ilmari(dot)org (Dagfinn Ilmari Mannsåker ) |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Making CASE error handling less surprising |
Date: | 2020-07-23 17:50:32 |
Message-ID: | 878sfajf2v.fsf@wibble.ilmari.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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?
- ilmari
--
"A disappointingly low fraction of the human race is,
at any given time, on fire." - Stig Sandbeck Mathisen
From | Date | Subject | |
---|---|---|---|
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 |