Bug #633: CASE statement evaluation does not short-circut
James Cole (colejatmsu.edu) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
CASE statement evaluation does not short-circut
Long Description
In 7.2.1, Both the WHEN and THEN clauses of a CASE statement are evaluated, even if the WHEN clause evaluates to FALSE.
(I'm not sure if this behavior is allowed by the '92 spec, but it's different than under 7.1.x)
Platform info:
joel2=# select version();
version
------------------------------------------------------------------
PostgreSQL 7.2.1 on sparc-sun-solaris2.6, compiled by GCC 2.95.2
(1 row)
Sample Code
joel2=#
SELECT
CASE
WHEN 1 = 2 THEN 1 / 0
WHEN 1 = 1 THEN 1.0
END;
ERROR: floating point exception! The last floating point operation either exceeded legal ranges or was a divide by zero
No file was uploaded with this report
pgsql-bugs@postgresql.org writes:
In 7.2.1, Both the WHEN and THEN clauses of a CASE statement are evaluated, even if the WHEN clause evaluates to FALSE.
Not in the normal case.
SELECT
CASE
WHEN 1 = 2 THEN 1 / 0
WHEN 1 = 1 THEN 1.0
END;
ERROR: floating point exception! The last floating point operation either exceeded legal ranges or was a divide by zero
Hmm. The reason for this is that the constant-expression simplifier
reduces all the subexpressions of the CASE before it tries to discard
the ones with constant-FALSE preconditions. This particular example
could be fixed by rearranging the order of the simplification operations,
but you'd still see a failure with, say,
SELECT CASE WHEN boolCol THEN 1 / 0 END FROM table;
since 1/0 will be const-folded at planning time whether the table
contains any TRUE entries or not.
I don't really consider this a bug; at least, fixing it would imply not
const-simplifying the result expressions of CASEs, which is a cure far
worse than the disease IMHO. Does anyone think we *should* allow CASE
to defeat const-simplification? Are there any real-world cases (as
opposed to made-up examples) where this is necessary?
regards, tom lane
...
I don't really consider this a bug; at least, fixing it would imply not
const-simplifying the result expressions of CASEs, which is a cure far
worse than the disease IMHO. Does anyone think we *should* allow CASE
to defeat const-simplification?
No. Constant-folding during parsing should *always* be allowed.
- Thomas