Re: Making CASE error handling less surprising
От | ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) |
---|---|
Тема | Re: Making CASE error handling less surprising |
Дата | |
Msg-id | 878sfajf2v.fsf@wibble.ilmari.org обсуждение исходный текст |
Ответ на | Making CASE error handling less surprising (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Making CASE error handling less surprising
|
Список | pgsql-hackers |
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? - ilmari -- "A disappointingly low fraction of the human race is, at any given time, on fire." - Stig Sandbeck Mathisen
В списке pgsql-hackers по дате отправления: