Using DECIMAL constants with more than 65 digits in CREATE
TABLE ... SELECT led to bogus errors in release builds or
assertion failures in debug builds.
The problem was in inconsistency in how DECIMAL constants and
fields are handled internally. We allow arbitrarily long
DECIMAL constants, whereas DECIMAL(M,D) columns are limited to
M<=65 and D<=30. my_decimal_precision_to_length() was used in
both Item and Field code and truncated precision to
DECIMAL_MAX_PRECISION when calculating value length without
adjusting precision and decimals. As a result, a DECIMAL
constant with more than 65 digits ended up having length less
than precision or decimals which led to assertion failures.
Fixed by modifying my_decimal_precision_to_length() so that
precision is truncated to DECIMAL_MAX_PRECISION only for Field
object which is indicated by the new 'truncate' parameter.
Another inconsistency fixed by this patch is how DECIMAL
constants and expressions are handled for CREATE ... SELECT.
create_tmp_field_from_item() (which is used for constants) was
changed as a part of the bugfix for bug #24907 to handle long
DECIMAL constants gracefully. Item_func::tmp_table_field()
(which is used for expressions) on the other hand was still
using a simplistic approach when creating a Field_new_decimal
from a DECIMAL expression.
mysql-test/r/type_newdecimal.result:
Added a test case for bug #45262.
mysql-test/t/type_newdecimal.test:
Added a test case for bug #45262.
sql/item.cc:
Use the new 'truncate' parameter in
my_decimal_precision_to_length().
sql/item_cmpfunc.cc:
Use the new 'truncate' parameter in
my_decimal_precision_to_length().
sql/item_func.cc:
1. Use the new 'truncate' parameter in
my_decimal_precision_to_length().
2. Do not truncate decimal precision to DECIMAL_MAX_PRECISION
for additive expressions involving long DECIMAL constants.
3. Fixed an incosistency in how DECIMAL constants and
expressions are handled for CREATE ... SELECT.
sql/item_func.h:
Use the new 'truncate' parameter in
my_decimal_precision_to_length().
sql/item_sum.cc:
Use the new 'truncate' parameter in
my_decimal_precision_to_length().
sql/my_decimal.h:
Do not truncate precision to DECIMAL_MAX_PRECISION
when calculating length in
my_decimal_precision_to_length() if 'truncate' parameter
is FALSE.
sql/sql_select.cc:
1. Use the new 'truncate' parameter in
my_decimal_precision_to_length().
2. Use a more correct logic when adjusting value's length.
Using DECIMAL constants with more than 65 digits in CREATE
TABLE ... SELECT led to bogus errors in release builds or
assertion failures in debug builds.
The problem was in inconsistency in how DECIMAL constants and
fields are handled internally. We allow arbitrarily long
DECIMAL constants, whereas DECIMAL(M,D) columns are limited to
M<=65 and D<=30. my_decimal_precision_to_length() was used in
both Item and Field code and truncated precision to
DECIMAL_MAX_PRECISION when calculating value length without
adjusting precision and decimals. As a result, a DECIMAL
constant with more than 65 digits ended up having length less
than precision or decimals which led to assertion failures.
Fixed by modifying my_decimal_precision_to_length() so that
precision is truncated to DECIMAL_MAX_PRECISION only for Field
object which is indicated by the new 'truncate' parameter.
Another inconsistency fixed by this patch is how DECIMAL
constants and expressions are handled for CREATE ... SELECT.
create_tmp_field_from_item() (which is used for constants) was
changed as a part of the bugfix for bug #24907 to handle long
DECIMAL constants gracefully. Item_func::tmp_table_field()
(which is used for expressions) on the other hand was still
using a simplistic approach when creating a Field_new_decimal
from a DECIMAL expression.
with gcc 4.3.2
Compiling MySQL with gcc 4.3.2 and later produces a number of
warnings, many of which are new with the recent compiler
versions.
This bug will be resolved in more than one patch to limit the
size of changesets. This is the first patch, fixing a number
of the warnings, predominantly "suggest using parentheses
around && in ||", and empty for and while bodies.
with gcc 4.3.2
Compiling MySQL with gcc 4.3.2 and later produces a number of
warnings, many of which are new with the recent compiler
versions.
This bug will be resolved in more than one patch to limit the
size of changesets. This is the first patch, fixing a number
of the warnings, predominantly "suggest using parentheses
around && in ||", and empty for and while bodies.
with gcc 4.3.2
Compiling MySQL with gcc 4.3.2 and later produces a number of
warnings, many of which are new with the recent compiler
versions.
This bug will be resolved in more than one patch to limit the
size of changesets. This is the first patch, fixing a number
of the warnings, predominantly "suggest using parentheses
around && in ||", and empty for and while bodies.
with gcc 4.3.2
Compiling MySQL with gcc 4.3.2 and later produces a number of
warnings, many of which are new with the recent compiler
versions.
This bug will be resolved in more than one patch to limit the
size of changesets. This is the first patch, fixing a number
of the warnings, predominantly "suggest using parentheses
around && in ||", and empty for and while bodies.
HAVING
When calculating GROUP BY the server caches some expressions. It does
that by allocating a string slot (Item_copy_string) and assigning the
value of the expression to it. This effectively means that the result
type of the expression can be changed from whatever it was to a string.
As this substitution takes place after the compile-time result type
calculation for IN but before the run-time type calculations,
it causes the type calculations in the IN function done at run time
to get unexpected results different from what was prepared at compile time.
In the CASE ... WHEN ... THEN ... statement there was a similar problem
and it was solved by artificially adding a STRING argument to the set of
types of the IN/CASE arguments at compile time, so if any of the
arguments of the CASE function changes its type to a string it will
still be covered by the information prepared at compile time.
mysql-test/include/mix1.inc:
Bug #44399: extended the test to cover the different types
mysql-test/r/func_in.result:
Bug #44399: test case
mysql-test/r/innodb_mysql.result:
Bug #44399: extended the test to cover the different types
mysql-test/t/func_in.test:
Bug #44399: test case
sql/item.cc:
Bug #44399: Implement typed caching for GROUP BY
sql/item.h:
Bug #44399: Implement typed caching for GROUP BY
sql/item_cmpfunc.cc:
Bug #44399: remove the special case
sql/sql_select.cc:
Bug #44399: Implement typed caching for GROUP BY
HAVING
When calculating GROUP BY the server caches some expressions. It does
that by allocating a string slot (Item_copy_string) and assigning the
value of the expression to it. This effectively means that the result
type of the expression can be changed from whatever it was to a string.
As this substitution takes place after the compile-time result type
calculation for IN but before the run-time type calculations,
it causes the type calculations in the IN function done at run time
to get unexpected results different from what was prepared at compile time.
In the CASE ... WHEN ... THEN ... statement there was a similar problem
and it was solved by artificially adding a STRING argument to the set of
types of the IN/CASE arguments at compile time, so if any of the
arguments of the CASE function changes its type to a string it will
still be covered by the information prepared at compile time.
and HAVING
When calculating GROUP BY the server caches some expressions. It does
that by allocating a string slot (Item_copy_string) and assigning the
value of the expression to it. This effectively means that the result
type of the expression can be changed from whatever it was to a string.
As this substitution takes place after the compile-time result type
calculation for IN but before the run-time type calculations,
it causes the type calculations in the IN function done at run time
to get unexpected results different from what was prepared at compile time.
In the CASE ... WHEN ... THEN ... statement there was a similar problem
and it was solved by artificially adding a STRING argument to the matrix
at compile time, so if any of the arguments of the CASE function changes
its type to a string it will still be covered by the information prepared
at compile time.
Extended the CASE fix for cover the IN case.
An alternative way of fixing this problem is by caching the result type of
the arguments at compile time and using the cached information at run time
instead of re-calculating the result types.
Preferred the CASE approach for uniformity and fix localization.
mysql-test/r/func_in.result:
Bug #44399: test case
mysql-test/t/func_in.test:
Bug #44399: test case
sql/item_cmpfunc.cc:
Bug #44399: assume at compile time there's an extra string argument
in the IN function (similar to CASE) to cater for possible string
conversions in the process of calculating the GROUP BY/aggregates.
and HAVING
When calculating GROUP BY the server caches some expressions. It does
that by allocating a string slot (Item_copy_string) and assigning the
value of the expression to it. This effectively means that the result
type of the expression can be changed from whatever it was to a string.
As this substitution takes place after the compile-time result type
calculation for IN but before the run-time type calculations,
it causes the type calculations in the IN function done at run time
to get unexpected results different from what was prepared at compile time.
In the CASE ... WHEN ... THEN ... statement there was a similar problem
and it was solved by artificially adding a STRING argument to the matrix
at compile time, so if any of the arguments of the CASE function changes
its type to a string it will still be covered by the information prepared
at compile time.
Extended the CASE fix for cover the IN case.
An alternative way of fixing this problem is by caching the result type of
the arguments at compile time and using the cached information at run time
instead of re-calculating the result types.
Preferred the CASE approach for uniformity and fix localization.
In case of ROW item each compared pair does not
check if argumet collations can be aggregated and
thus appropiriate item conversion does not happen.
The fix is to add the check and convertion for ROW
pairs.
mysql-test/r/row.result:
test result
mysql-test/t/row.test:
test case
sql/item.cc:
added agg_item_set_converter() function which was a part of
agg_item_charsets() func. The only difference is that
agg_item_set_converter() checks and converts items
using already known collation.
sql/item.h:
added agg_item_set_converter() function
sql/item_cmpfunc.cc:
In case of ROW item each compared pair does not
check if argumet collations can be aggregated and
thus appropiriate item conversion does not happen.
The fix is to add the check and convertion for ROW
pairs.
In case of ROW item each compared pair does not
check if argumet collations can be aggregated and
thus appropiriate item conversion does not happen.
The fix is to add the check and convertion for ROW
pairs.
mysql-test/t/variables.test:
Reset delay_key_write, otherwise maria.maria test may fail
sql/set_var.cc:
Reset ha_open_options if one resets the delay_key_write variable.
Before there was no way to reset it without restarting mysqld, which caused some tests to fail
There were so many changes into mtr (this is the new mtr coming) that I rather
copied mtr from 6.0-main here (at least this one knows how to run Maria tests).
I also fixed suite/maria tests to be accepted by the new mtr.
mysys/thr_mutex.c:
adding DBUG_PRINT here, so that we can locate where the warning is issued.
- Added braces around expressions with &&, ||, & and |
- Added empty line before ; for empty while and for loops
- Added () around if with assignments
- Removed const before function returning simple type
Changed BUILD scripts to not build with NDB
BUILD/SETUP.sh:
By default, don't build ndb with --max in Maria tree.
NDB is not kept up to date anyway in 5.1
client/mysql.cc:
Added braces around && to get rid of compiler warnings
sql/event_db_repository.cc:
Added braces around && to get rid of compiler warnings
sql/events.cc:
Added braces around && to get rid of compiler warnings
sql/field.cc:
Added braces around && to get rid of compiler warnings
Fixed for loops
sql/field.h:
Added braces around & to get rid of compiler warnings
sql/field_conv.cc:
Added braces around && to get rid of compiler warnings
Fixed bug when copying between DATETIME fields and strict dates are used
Removed not needeed else
sql/gstream.cc:
Added braces around && to get rid of compiler warnings
sql/ha_ndbcluster.cc:
Added braces around && to get rid of compiler warnings
Added {} to get rid of compiler warnings
sql/handler.cc:
Added braces around && to get rid of compiler warnings
sql/item.cc:
Added braces around && to get rid of compiler warnings
sql/item_cmpfunc.cc:
Added braces around && to get rid of compiler warnings
Removed some not needed space
sql/item_func.cc:
Added braces around && to get rid of compiler warnings
sql/item_strfunc.cc:
Added braces around && to get rid of compiler warnings
sql/item_subselect.cc:
Added braces around && to get rid of compiler warnings
sql/item_sum.cc:
Added braces around && to get rid of compiler warnings
sql/item_timefunc.cc:
Added braces around && to get rid of compiler warnings
sql/item_xmlfunc.cc:
Added empty line before ; for empty while and for loops
sql/log.cc:
Added braces around && to get rid of compiler warnings
sql/log_event.cc:
Added braces around && to get rid of compiler warnings
Removed not needed else
sql/log_event_old.cc:
Added braces around && to get rid of compiler warnings
sql/opt_range.cc:
Added braces around && to get rid of compiler warnings
sql/opt_sum.cc:
Added braces around && to get rid of compiler warnings
sql/set_var.cc:
Added empty line before ; for empty while and for loops
Added () around if with assignments
sql/slave.cc:
Added braces around && to get rid of compiler warnings
Added empty line before ; for empty while and for loops
sql/spatial.h:
Added braces around && to get rid of compiler warnings
sql/sql_acl.cc:
Added braces around && to get rid of compiler warnings
sql/sql_analyse.cc:
Added empty line before ; for empty while and for loops
sql/sql_base.cc:
Added braces around && to get rid of compiler warnings
sql/sql_connect.cc:
Added braces around && to get rid of compiler warnings
sql/sql_db.cc:
Added braces around && to get rid of compiler warnings
sql/sql_delete.cc:
Added braces around && to get rid of compiler warnings
sql/sql_help.cc:
Added empty line before ; for empty while and for loops
sql/sql_insert.cc:
Added braces around && to get rid of compiler warnings
Added () around if with assignments
sql/sql_lex.cc:
Cast char array references to uchar; Fixed wrong array referencing when using characters > ASCII 128 in SQL statments
Added empty line before ; for empty while and for loops
Trivial indent fixes
Added braces around && to get rid of compiler warnings
sql/sql_load.cc:
Added braces around && to get rid of compiler warnings
sql/sql_parse.cc:
Added braces around && to get rid of compiler warnings
sql/sql_partition.cc:
Added braces around && to get rid of compiler warnings
sql/sql_plugin.cc:
Fixed bug in detecing if option variable should be readonly
Added empty line before ; for empty while and for loops
sql/sql_prepare.cc:
Added braces around && to get rid of compiler warnings
sql/sql_select.cc:
Added braces around && to get rid of compiler warnings
Added () around if with assignments
Added empty line before ; for empty while and for loops
sql/sql_show.cc:
Added braces around && to get rid of compiler warnings
sql/sql_table.cc:
Added braces around && to get rid of compiler warnings
sql/sql_trigger.cc:
Added braces around && to get rid of compiler warnings
sql/sql_update.cc:
Added braces around && to get rid of compiler warnings
sql/sql_yacc.yy:
Added braces around && to get rid of compiler warnings
sql/table.cc:
Added braces around && to get rid of compiler warnings
sql/table.h:
Added braces around && to get rid of compiler warnings
sql/time.cc:
Added braces around && to get rid of compiler warnings
sql/tztime.cc:
Added braces around && to get rid of compiler warnings
sql/uniques.cc:
Added braces around && to get rid of compiler warnings
storage/federated/ha_federated.cc:
Fixed bug in testing of variable to ha_info() (Not critical)
storage/heap/ha_heap.cc:
Added braces around && to get rid of compiler warnings
storage/maria/ha_maria.cc:
Fixed bug: Mark that maria_log_dir_path is readonly
Added braces around && to get rid of compiler warnings
storage/ndb/include/ndbapi/NdbEventOperation.hpp:
Removed const before function returning simple type
storage/ndb/include/ndbapi/NdbOperation.hpp:
Removed const before function returning simple type
storage/ndb/src/ndbapi/Ndb.cpp:
Added empty line before ; for empty while and for loops
storage/ndb/src/ndbapi/NdbEventOperation.cpp:
Removed const before function returning simple type
storage/ndb/src/ndbapi/NdbEventOperationImpl.cpp:
Removed const before function returning simple type
storage/ndb/src/ndbapi/NdbEventOperationImpl.hpp:
Removed const before function returning simple type
storage/ndb/src/ndbapi/NdbRecAttr.cpp:
Added empty line before ; for empty while and for loops
storage/ndb/src/ndbapi/TransporterFacade.hpp:
Added braces around && to get rid of compiler warnings
Item_in_optimizer::is_null() evaluated "NULL IN (SELECT ...)" to NULL regardless of
whether subquery produced any records, this was a documented limitation.
The limitation has been removed (see bugs 8804, 24085, 24127) now
Item_in_optimizer::val_int() correctly handles all cases with NULLs. Make
Item_in_optimizer::is_null() invoke val_int() to return correct values for
"NULL IN (SELECT ...)".
mysql-test/r/subselect.result:
BUG#37822: Correlated subquery with IN and IS UNKNOWN provides wrong result
- Testcase
mysql-test/t/subselect.test:
BUG#37822: Correlated subquery with IN and IS UNKNOWN provides wrong result
- Testcase
Item_in_optimizer::is_null() evaluated "NULL IN (SELECT ...)" to NULL regardless of
whether subquery produced any records, this was a documented limitation.
The limitation has been removed (see bugs 8804, 24085, 24127) now
Item_in_optimizer::val_int() correctly handles all cases with NULLs. Make
Item_in_optimizer::is_null() invoke val_int() to return correct values for
"NULL IN (SELECT ...)".
Execution of queries containing the CASE function of
aggregate function like in "SELECT ... CASE ARGV(...) WHEN ..."
crashed the server.
The CASE function caches pointers to concrete comparison
functions for an each pair of types of CASE-WHERE clause
parameters, i.e. for the "CASE INT_RESULT WHERE REAL_RESULT
THEN ... WHERE DECIMAL_RESULT ... END" function call it
caches comparisons for INT_RESULT with REAL_RESULT and
for INT_RESULT with DECIMAL_RESULT. Usually a result
type is known after a call to the fix_fields function,
however, the setup_copy_fields function call may
wrap aggregate items with Item_copy_string that has
STRING_RESULT result type, so setup_copy_fields may
change argument result types of the CASE function after
call to Item_func_case::fix_fields/fix_length_and_dec.
Then the Item_func_case::find_item function tries to
use comparison function for unexpected pair of the
STRING_RESULT and some other type - that caused
an assertion failure of server crash.
The Item_func_case::fix_length_and_dec function has
been modified to take into account possible STRING_RESULT
result type in the presence of aggregate arguments of
the CASE function.
mysql-test/r/func_in.result:
Added test case for bug #41363.
mysql-test/t/func_in.test:
Added test case for bug #41363.
sql/item_cmpfunc.cc:
Bug #41363: crash of mysqld on windows with aggregate in case
The Item_func_case::fix_length_and_dec function has
been modified to take into account possible STRING_RESULT
result type in the presence of aggregate arguments of
the CASE function.
Execution of queries containing the CASE function of
aggregate function like in "SELECT ... CASE ARGV(...) WHEN ..."
crashed the server.
The CASE function caches pointers to concrete comparison
functions for an each pair of types of CASE-WHERE clause
parameters, i.e. for the "CASE INT_RESULT WHERE REAL_RESULT
THEN ... WHERE DECIMAL_RESULT ... END" function call it
caches comparisons for INT_RESULT with REAL_RESULT and
for INT_RESULT with DECIMAL_RESULT. Usually a result
type is known after a call to the fix_fields function,
however, the setup_copy_fields function call may
wrap aggregate items with Item_copy_string that has
STRING_RESULT result type, so setup_copy_fields may
change argument result types of the CASE function after
call to Item_func_case::fix_fields/fix_length_and_dec.
Then the Item_func_case::find_item function tries to
use comparison function for unexpected pair of the
STRING_RESULT and some other type - that caused
an assertion failure of server crash.
The Item_func_case::fix_length_and_dec function has
been modified to take into account possible STRING_RESULT
result type in the presence of aggregate arguments of
the CASE function.
Fixed bug when removing a newly inserted record (in case of duplicate key).
The bug caused a crash for rows with several blobs and the first blob was small enough to fit into the head page.
Don't change state_history if nothing changed (speed optimization that also simplifies logic).
Reset state_history if we added/deleted or updated rows without versioning.
Fixed wrong test in trnman_exists_active_transactions() if state is visible or not.
Other bugs fixed:
Fixed wrong argument to (lock->get_status) when we had to wait for TL_WRITE_CONCURRENT_INSERT.
Item_equal::update_used_tables() didn't calculate const_item_cache properly.
Added assert's to detect if join_read_const_table() was called under wrong assumptions..
Fixed that _ma_setup_live_state() is called from thr_lock() instead of handler::external_lock().
This was needed to get versioning information to be setup correctly.
Fixed error in debug binaries during a call to _ma_check_table_is_closed() when another thread was opening/closing a table.
Fixed wrong test when finding right history_state to use.
mysql-test/suite/maria/r/maria.result:
Added test for Bug#40311 Assert in MARIA_RECORD_POS during pushbuild 2 test
mysql-test/suite/maria/t/maria.test:
Added test for Bug#40311 Assert in MARIA_RECORD_POS during pushbuild 2 test
mysys/thr_lock.c:
Fixed wrong argument to (lock->get_status) when we had to wait for TL_WRITE_CONCURRENT_INSERT
sql/item_cmpfunc.cc:
Item_equal::update_used_tables() didn't calculate const_item_cache properly, which later caused a wrong result for item->const_item()
sql/sql_base.cc:
In debug mode, Initilize record buffer with unexpected data to catch usage of uninitialized memory
sql/sql_select.cc:
Fixed indentation
Added assert's to detect if join_read_const_table() was called under wrong assumptions.
One assert() is disabled for now as Item_equal() doesn't behave as expected.
storage/maria/ha_maria.cc:
Move calling to _ma_setup_live_state() to ma_state.c::_ma_block_get_status()
This was needed as _ma_setup_live_state() needed to know if the table will be used concurrently or not
storage/maria/ma_blockrec.c:
Fixed bug when removing a newly inserted record (in case of duplicate key).
The bug caused a crash for rows with several blobs and the first blob was small enough to fit into the head page.
storage/maria/ma_dbug.c:
Added mutex to protect the open table list during _ma_check_table_is_closed().
Without the protection we could get a error in debug binaries during a call to _ma_check_table_is_closed()
storage/maria/ma_delete_table.c:
Removed not used code
storage/maria/ma_rename.c:
Removed not used code
storage/maria/ma_state.c:
Fixed wrong test when finding right history_state to use
Mark in tables->state_current.no_transid if we are using transid's or not.
Don't change state_history if nothing changed (speed optimization that also simplifies logic)
Reset state_history if we added/deleted or updated rows without versioning.
More DBUG_ASSERT's and more DBUG
Updated maria_versioning() to initialize environment before calling _ma_blok_get_status(). This was needed because of the new logic in _ma_block_get_status()
storage/maria/ma_state.h:
Added flags to detect if table changed and/or if we changed table without versioning
storage/maria/ma_write.c:
Simple cleanups (No logic changes)
storage/maria/trnman.c:
Fixed wrong test in trnman_exists_active_transactions() if state is visible or not.
IF(..., CAST(longtext AS UNSIGNED), signed_val)
(was: LEFT JOIN on inline view crashes server)
Select from a LONGTEXT column wrapped with an expression
like "IF(..., CAST(longtext_column AS UNSIGNED), smth_signed)"
failed an assertion or crashed the server. IFNULL function was
affected too.
LONGTEXT column item has a maximum length of 32^2-1 bytes,
at the same time this is a maximum possible length of any
MySQL item. CAST(longtext_column AS UNSIGNED) returns some
unsigned numeric result of length 32^2-1, so the result of
IF/IFNULL function of this number and some other signed number
will have text length of (32^2-1)+1=32^2 (one byte for the
minus sign) - there is integer overflow, and the length is
equal to zero. That caused assert/crash.
The bug has been fixed by the same solution as in the CASE
function implementation.
mysql-test/r/func_if.result:
Added test case for bug #40761.
mysql-test/t/func_if.test:
Added test case for bug #40761.
sql/item_cmpfunc.cc:
Bug #40761: Assert on sum function on
IF(..., CAST(longtext AS UNSIGNED), signed_val)
1. Item_func_case::agg_str_lengths method has been moved
to the Item_func superclass.
2. Item_func_ifnull/Item_func_if::fix_length_and_dec methods
have been updated to calculate max_length, decimals and
unsigned flag like Item_func_case.
sql/item_cmpfunc.h:
Bug #40761: Assert on sum function on
IF(..., CAST(longtext AS UNSIGNED), signed_val)
Item_func_case::agg_str_lengths method has been moved to
the Item_func superclass.
sql/item_func.cc:
Bug #40761: Assert on sum function on
IF(..., CAST(longtext AS UNSIGNED), signed_val)
Item_func_case::agg_str_lengths method has been moved to
the Item_func superclass.
sql/item_func.h:
Bug #40761: Assert on sum function on
IF(..., CAST(longtext AS UNSIGNED), signed_val)
Item_func_case::agg_str_lengths method has been moved to
the Item_func superclass.
IF(..., CAST(longtext AS UNSIGNED), signed_val)
(was: LEFT JOIN on inline view crashes server)
Select from a LONGTEXT column wrapped with an expression
like "IF(..., CAST(longtext_column AS UNSIGNED), smth_signed)"
failed an assertion or crashed the server. IFNULL function was
affected too.
LONGTEXT column item has a maximum length of 32^2-1 bytes,
at the same time this is a maximum possible length of any
MySQL item. CAST(longtext_column AS UNSIGNED) returns some
unsigned numeric result of length 32^2-1, so the result of
IF/IFNULL function of this number and some other signed number
will have text length of (32^2-1)+1=32^2 (one byte for the
minus sign) - there is integer overflow, and the length is
equal to zero. That caused assert/crash.
The bug has been fixed by the same solution as in the CASE
function implementation.
Field_varstring::store
The code that temporary saved the bitmaps of the read set and the write set so that
it can set it to all columns for debug purposes was not expecting that the
table->read_set and table->write_set can be the same. And was always saving both in
sequence.
As a result the original value was never restored.
Fixed by saving & restoring the original value only once if the two sets are the
same (in a special set of functions).
mysql-test/r/select.result:
Bug #37936: test case
mysql-test/t/select.test:
Bug #37936: test case
sql/item_cmpfunc.cc:
Bug #37936: don't save/restore twice if the read and write sets are the same
sql/opt_range.cc:
Bug #37936: don't save/restore twice if the read and write sets are the same
sql/table.h:
Bug #37936: Make a designated set of functions that save/restore
both the read and the write sets in a single call.
Field_varstring::store
The code that temporary saved the bitmaps of the read set and the write set so that
it can set it to all columns for debug purposes was not expecting that the
table->read_set and table->write_set can be the same. And was always saving both in
sequence.
As a result the original value was never restored.
Fixed by saving & restoring the original value only once if the two sets are the
same (in a special set of functions).
We pretended that TIMEDIFF() would always return positive results;
this gave strange results in comparisons of the TIMEDIFF(low,hi)<TIME(0)
type that rendered a negative result, but still gave false in comparison.
We also inadvertantly dropped the sign when converting times to
decimal.
CAST(time AS DECIMAL) handles signs of the times correctly.
TIMEDIFF() marked up as signed. Time/date comparison code switched to
signed for clarity.
mysql-test/r/func_sapdb.result:
show that time-related comparisons work with negative
time values now.
show that converting time to DECIMAL no longer drops sign.
mysql-test/t/func_sapdb.test:
show that time-related comparisons work with negative
time values now.
show that converting time to DECIMAL no longer drops sign.
sql/item_cmpfunc.cc:
signed returns
sql/item_cmpfunc.h:
signed now (time/date < > =)
sql/item_func.cc:
signed now
sql/item_timefunc.h:
Functions such as TIMEDIFF() return signed results!
The file-comments pretended we were doing that all along, anyway...
sql/my_decimal.cc:
heed sign when converting time to my_decimal;
times may actually be negative!
Needed for SELECT CAST(time('-73:42:12') AS DECIMAL);
sql/mysql_priv.h:
using signed for dates and times now
We pretended that TIMEDIFF() would always return positive results;
this gave strange results in comparisons of the TIMEDIFF(low,hi)<TIME(0)
type that rendered a negative result, but still gave false in comparison.
We also inadvertantly dropped the sign when converting times to
decimal.
CAST(time AS DECIMAL) handles signs of the times correctly.
TIMEDIFF() marked up as signed. Time/date comparison code switched to
signed for clarity.
the problem is the same as reported in bug#20835,
so the fix is backport of bug#20835 patch.
mysql-test/r/subselect.result:
test result
mysql-test/t/subselect.test:
test case
