All numeric operators and functions on integer, floating point
and DECIMAL values now throw an 'out of range' error rather
than returning an incorrect value or NULL, when the result is
out of supported range for the corresponding data type.
Some test cases in the test suite had to be updated
accordingly either because the test case itself relied on a
value returned in case of a numeric overflow, or because a
numeric overflow was the root cause of the corresponding bugs.
The latter tests are no longer relevant, since the expressions
used to trigger the corresponding bugs are not valid anymore.
However, such test cases have been adjusted and kept "for the
record".
The Item_func_mod objects never had maybe_null set, so users had no reason
to expect that they can be NULL, and may therefore deduce wrong results.
Now, set maybe_null.
- Honor unsigned_flag in the corresponding functions
- Use compare_int_signed_unsigned()/compare_int_unsigned_signed() instead of explicit comparison in GREATEST() and LEAST()
Corrected results after the fix for bug #12791.
func_test.result, func_test.test:
Added test cases for bug #12791.
item_func.h, item_func.cc:
Fixed bug #12791.
Made LEAST/GREATES fully Oracle compliant.
LEAST/GREATEST did not return NULL if only some
arguments were NULLs. This did not comply with Oracle.
Added more DBUG statements
Ensure that we are comparing end space with BINARY strings
Use 'any_db' instead of '' to mean any database. (For HANDLER command)
Only strip ' ' when comparing CHAR, not other space-like characters (like \t)
Portability fixes for HPUX
Rename of CHECK_LOCK to IS_FREE_LOCK
Apply lower_case_table_names also to databases
Cleanup of describe code
Don't allow \ in database names
