* Finished Monty and Jani's merge
* Some InnoDB tests still fail (because it's old xtradb code run against
newer testsuite). They are expected to go after mergning with the latest
xtradb.
with gcc 4.3.2
This patch fixes a number of GCC warnings about variables used
before initialized. A new macro UNINIT_VAR() is introduced for
use in the variable declaration, and LINT_INIT() usage will be
gradually deprecated. (A workaround is used for g++, pending a
patch for a g++ bug.)
GCC warnings for unused results (attribute warn_unused_result)
for a number of system calls (present at least in later
Ubuntus, where the usual void cast trick doesn't work) are
also fixed.
client/mysqlmanager-pwgen.c:
A fix for warn_unused_result, adding fallback to use of
srand()/rand() if /dev/random cannot be used. Also actually
adds calls to rand() in the second branch so that it actually
creates a random password.
client/mysql.cc:
Remove leading whitespace.
Remove extra text after #else directive.
client/mysqldump.c:
Function does not take a parameter.
mysys/array.c:
buffer is a uchar pointer.
sql/item.cc:
Assert if it should not happen.
storage/myisam/mi_check.c:
Cast to expected type. This is probably a bug, but it is
casted in a similar way in another part of the code.
storage/ndb/include/mgmapi/ndb_logevent.h:
Apply fix from cluster team.
tests/mysql_client_test.c:
Remove extraneous slash.
sql/opt_range.cc:
Removed duplicate code (if statement must have been duplicated during earlier merge).
sql/sql_partition.cc:
After mergeing bug#46362 and bug#20577, the NULL partition was also searched
when col = const, fixed by checking if = or range.
There were a problem since pruning uses the field
for comparison (while evaluate_join_record uses longlong),
resulting in pruning failures when comparing DATE to DATETIME.
Fix was to always comparing DATE vs DATETIME as DATETIME,
by adding ' 00:00:00' to the DATE string.
And adding optimization for comparing with 23:59:59, so that
DATETIME_col > '2001-02-03 23:59:59' ->
TO_DAYS(DATETIME_col) > TO_DAYS('2001-02-03 23:59:59') instead
of '>='.
mysql-test/r/partition_pruning.result:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Updated result-file
mysql-test/t/partition_pruning.test:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Added testcases.
sql-common/my_time.c:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
removed duplicate assignment.
sql/item.cc:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Changed field_is_equal_to_item into field_cmp_to_item, to
better handling DATE vs DATETIME comparision.
sql/item.h:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Updated comment
sql/item_timefunc.cc:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Added optimization (pruning) of DATETIME where time-part is
23:59:59
sql/opt_range.cc:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Using the new stored_field_cmp_to_item for better pruning.
The problem was that creating a DECIMAL column from a decimal
value could lead to a failed assertion as decimal values can
have a higher precision than those attached to a table. The
assert could be triggered by creating a table from a decimal
with a large (> 30) scale. Also, there was a problem in
calculating the number of digits in the integral and fractional
parts if both exceeded the maximum number of digits permitted
by the new decimal type.
The solution is to ensure that truncation procedure is executed
when deducing a DECIMAL column from a decimal value of higher
precision. If the integer part is equal to or bigger than the
maximum precision for the DECIMAL type (65), the integer part
is truncated to fit and the fractional becomes zero. Otherwise,
the fractional part is truncated to fit into the space left
after the integer part is copied.
This patch borrows code and ideas from Martin Hansson's patch.
mysql-test/r/type_newdecimal.result:
Add test case result for Bug#45261. Also, update test case to
reflect that an additive operation increases the precision of
the resulting type by 1.
mysql-test/t/type_newdecimal.test:
Add test case for Bug#45261
sql/field.cc:
Added DBUG_ASSERT to ensure object's invariant is maintained.
Implement method to create a field to hold a decimal value
from an item.
sql/field.h:
Explain member variable. Add method to create a new decimal field.
sql/item.cc:
The precision should only be capped when storing the value
on a table. Also, this makes it impossible to calculate the
integer part if Item::decimals (the scale) is larger than the
precision.
sql/item.h:
Simplify calculation of integer part.
sql/item_cmpfunc.cc:
Do not limit the precision. It will be capped later.
sql/item_func.cc:
Use new method for allocating a new decimal field.
Add a specialized method for retrieving the precision
of a user variable item.
sql/item_func.h:
Add method to return the precision of a user variable.
sql/item_sum.cc:
Use new method for allocating a new decimal field.
sql/my_decimal.h:
The integer part could be improperly calculated for a decimal
with 31 digits in the fractional part.
sql/sql_select.cc:
Use new method which truncates the integer or decimal parts
as needed.
Address review feedback:
- Change from Wave-based approach (a-la const table detection) to
building and walking functional dependency graph.
- Change from piggy-backing on ref-access code and KEYUSE structures
to using our own expression analyzer.
sql/item.cc:
MWL#17: Table elimination
- Move from C-ish Field_processor_info to C++ ish and generic Field_enumerator
sql/item.h:
MWL#17: Table elimination
- Move from C-ish Field_processor_info to C++ ish and generic Field_enumerator
sql/sql_bitmap.h:
MWL#17: Table elimination
- Backport of Table_map_iterator from 6.0
When during the optimization an item is moved to the upper select
the item's context left unchanged. This caused wrong result in the
PS/SP mode.
The Item_ident::remove_dependence_processor now sets the context
of the select to which the item is moved to.
mysql-test/r/subselect.result:
The test case for the bug#46051 is adjusted.
mysql-test/t/subselect.test:
The test case for the bug#46051 is adjusted.
sql/item.cc:
Bug#46051: Incorrectly market field caused wrong result.
The Item_ident::remove_dependence_processor now sets the context
of the select to which the item is moved to.
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.
contains ONLY_FULL_GROUP_BY
The partitioning code needs to issue a Item::fix_fields()
on the partitioning expression in order to prepare
it for being evaluated.
It does this by creating a special table and a table list
for the scope of the partitioning expression.
But when checking ONLY_FULL_GROUP_BY the
Item_field::fix_fields() was relying that there always be
cached_table set and was trying to use it to get the
select_lex of the SELECT the field's table is in.
But the cached_table was not set by the partitioning code
that creates the artificial TABLE_LIST used to resolve the
partitioning expression and this resulted in a crash.
Fixed by rectifying the following errors :
1. Item_field::fix_fields() : the code that check for
ONLY_FULL_GROUP_BY relies on having tables with
cacheable_table set. This is mostly true, the only
two exceptions being the partitioning context table
and the trigger context table.
Fixed by taking the current parsing context if no pointer
to the TABLE_LIST instance is present in the cached_table.
2. fix_fields_part_func() :
2a. The code that adds the table being created to the
scope for the partitioning expression is mostly a copy
of the add_table_to_list and friends with one exception :
it was not marking the table as cacheable (something that
normal add_table_to_list is doing). This caused the
problem in the check for ONLY_FULL_GROUP_BY in
Item_field::fix_fields() to appear.
Fixed by setting the correct members to make the table
cacheable.
The ideal structural fix for this is to use a unified
interface for adding a table to a table list
(add_table_to_list?) : noted in a TODO comment
2b. The Item::fix_fields() was called with a NULL destination
pointer. This causes uninitalized memory reads in the
overloaded ::fix_fields() function (namely
Item_field::fix_fields()) as it expects a non-zero pointer
there. Fixed by passing the source pointer similarly to how
it's done in JOIN::prepare().
mysql-test/r/partition.result:
Bug #45807: test case
mysql-test/t/partition.test:
Bug #45807: test case
sql/item.cc:
Bug #45807: fix the ONLY_FULL_GROUP_BY check code to
handle correctly non-cacheable tables.
sql/sql_partition.cc:
Bug #45807: fix the Item::fix_fields() context
initializatio for the partitioning expression in
CREATE TABLE.
- Last fixes
sql/item.cc:
MWL#17: Table elimination
- Don't make multiple calls of ::walk(check_column_usage_processor),
call once and cache the value
sql/item.h:
MWL#17: Table elimination
- s/KEYUSE::usable/KEYUSE::type/, more comments
sql/opt_table_elimination.cc:
MWL#17: Table elimination
- Don't make multiple calls of ::walk(check_column_usage_processor),
call once and cache the value
sql/sql_select.cc:
MWL#17: Table elimination
- s/KEYUSE::usable/KEYUSE::type/, more comments
sql/sql_select.h:
MWL#17: Table elimination
- s/KEYUSE::usable/KEYUSE::type/, more comments
sql/table.h:
MWL#17: Table elimination
- Better comments
In Item_param::set_from_user_var
value.cs_info.character_set_client is set
to 'fromcs' value. It's wrong, it should be set to
thd->variables.character_set_client.
mysql-test/r/ctype_gbk_binlog.result:
test result
mysql-test/t/ctype_gbk_binlog.test:
test case
sql/item.cc:
In Item_param::set_from_user_var
value.cs_info.character_set_client is set
to 'fromcs' value. It's wrong, it should be set to
thd->variables.character_set_client.
- fix a typo bug in has_eqref_access_candidate()
- Adjust test to remove race condition
mysql-test/r/mysql-bug41486.result:
Adjust test to remove race condition
mysql-test/t/mysql-bug41486.test:
Adjust test to remove race condition
sql/item.cc:
MWL#17: Table elimination:
fix a typo bug in has_eqref_access_candidate()
- Make elimination check to be able detect cases like t.primary_key_col1=othertbl.col AND t.primary_key_col2=func(t.primary_key_col1).
These are needed to handle e.g. the case of func() being a correlated subquery that selects the latest value.
- If we've removed a condition with subquery predicate, EXPLAIN [EXTENDED] won't show the subquery anymore
sql/item.cc:
MWL#17: Table elimination
- Add tem_field::check_column_usage_processor(). it allows to check which key parts a condition depends on.
sql/item.h:
MWL#17: Table elimination
- Add tem_field::check_column_usage_processor(). it allows to check which key parts a condition depends on.
sql/item_subselect.cc:
MWL#17: Table elimination
- Item_subselect got 'eliminated' attribute. It is used only to determine if the subselect should be printed by EXPLAIN.
- Item_subselect got List<Item> refers_to - a list of item in the current select that are referred to from within the subselect.
- Added Item_*::check_column_usage_processor(). it allows to check which key parts a condition depends on.
- Added a comment about possible problem in Item_subselect::walk
sql/item_subselect.h:
MWL#17: Table elimination
- Item_subselect got 'eliminated' attribute. It is used only to determine if the subselect should be printed by EXPLAIN.
- Item_subselect got List<Item> refers_to - a list of item in the current select that are referred to from within the subselect.
- Added Item_*::check_column_usage_processor(). it allows to check which key parts a condition depends on.
sql/item_sum.cc:
MWL#17: Table elimination
sql/sql_lex.cc:
MWL#17: Table elimination
sql/sql_lex.h:
MWL#17: Table elimination
sql/sql_select.h:
MWL#17: Table elimination
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 second patch, fixing more
of the warnings.
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 second patch, fixing more
of the warnings.
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.
When copying the Item class one must copy its attributes as well.
mysql-test/r/innodb_mysql.result:
Bug #36995: test case
mysql-test/t/innodb_mysql.test:
Bug #36995: test case
sql/item.cc:
Bug #36995: copy attributes in the copy constructor
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
assertion .\filesort.cc, line 797
A query with the "ORDER BY @@some_system_variable" clause,
where @@some_system_variable is NULL, causes assertion
failure in the filesort procedures.
The reason of the failure is in the value of
Item_func_get_system_var::maybe_null: it was unconditionally
set to false even if the value of a variable was NULL.
mysql-test/r/variables.result:
Added test case for bug #42778.
mysql-test/suite/sys_vars/r/innodb_data_home_dir_basic.result:
Updated test case for bug #42778:
system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/r/innodb_flush_method_basic.result:
Updated test case for bug #42778:
system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/r/rpl_init_slave_func.result:
Updated test case for bug #42778:
system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/r/ssl_capath_basic.result:
Updated test case for bug #42778:
system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/r/ssl_cipher_basic.result:
Updated test case for bug #42778:
system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/t/innodb_data_home_dir_basic.test:
Updated test case for bug #42778:
system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/t/innodb_flush_method_basic.test:
Updated test case for bug #42778:
system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/t/ssl_capath_basic.test:
Updated test case for bug #42778:
system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/t/ssl_cipher_basic.test:
Updated test case for bug #42778:
system variables were NOT NULL, now they are nullable.
mysql-test/t/variables.test:
Added test case for bug #42778.
sql/item.cc:
Bug #42778: delete order by null global variable causes
assertion .\filesort.cc, line 797
The longlong_from_string_with_check function has been modified
to skip unwanted warnings: now it uses the THD::no_errors
flag to suppress warnings.
The Item_func_get_system_var::update_null_value method
sets the no_error flag.
sql/item_func.cc:
Bug #42778: delete order by null global variable causes
assertion .\filesort.cc, line 797
1. The Item_func_get_system_var::fix_length_and_dec method
has been modified to make system variables truly nullable.
2. The Item_func_get_system_var::update_null_value method
method has been overloaded with a simple wrapper (like
Item_field::update_null_value) to suppress unwanted warnings
from Item_func_get_system_var::val_int() calls on non-numeric
variable values: the Item_func_get_system_var::update_null_value
method sets and restores THD::no_errors flag for a nested
call of the longlong_from_string_with_check function.
sql/item_func.h:
Bug #42778: delete order by null global variable causes
assertion .\filesort.cc, line 797
The Item_func_get_system_var::update_null_value method
method has been overloaded.
bug#44766: valgrind error when using convert() in a subquery
Problem: input and output buffers may be the same
converting a string to some charset.
That may lead to wrong results/valgrind warnings.
Fix: use different buffers.
mysql-test/r/cast.result:
Fix for bug#44743: Join in combination with concat does not always work
bug#44766: valgrind error when using convert() in a subquery
- test result.
mysql-test/r/func_concat.result:
Fix for bug#44743: Join in combination with concat does not always work
bug#44766: valgrind error when using convert() in a subquery
- test result.
mysql-test/t/cast.test:
Fix for bug#44743: Join in combination with concat does not always work
bug#44766: valgrind error when using convert() in a subquery
- test case.
mysql-test/t/func_concat.test:
Fix for bug#44743: Join in combination with concat does not always work
bug#44766: valgrind error when using convert() in a subquery
- test case.
sql/item.cc:
Fix for bug#44743: Join in combination with concat does not always work
bug#44766: valgrind error when using convert() in a subquery
- comment added.
sql/item_strfunc.cc:
Fix for bug#44743: Join in combination with concat does not always work
bug#44766: valgrind error when using convert() in a subquery
- '&args[0]->str_value' used as a parameter of args[0]->val_str(),
as 'str' may be equal to 'str_value' which we use as the output buffer
converting strings.
sql/sql_string.cc:
Fix for bug#44743: Join in combination with concat does not always work
bug#44766: valgrind error when using convert() in a subquery
- input and output buffers must NOT be the same.
with a "HAVING" clause though query works
SELECT from views defined like:
CREATE VIEW v1 (view_column)
AS SELECT c AS alias FROM t1 HAVING alias
fails with an error 1356:
View '...' references invalid table(s) or column(s)
or function(s) or definer/invoker of view lack rights
to use them
CREATE VIEW form with a (column list) substitutes
SELECT column names/aliases with names from a
view column list.
However, alias references in HAVING clause was
not substituted.
The Item_ref::print function has been modified
to write correct aliased names of underlying
items into VIEW definition generation/.frm file.
mysql-test/r/view.result:
Added test file for bug #40825.
mysql-test/t/view.test:
Added test file for bug #40825.
sql/item.cc:
Bug#40825: Error 1356 while selecting from a view
with a "HAVING" clause though query works
The Item_ref::print function has been modified
to write correct aliased names of underlying
items into VIEW definition generation/.frm file.
Bug #40925: Equality propagation takes non indexed attribute
Query execution plans and execution time of queries like
select a, b, c from t1
where a > '2008-11-21' and b = a limit 10
depended on the order of equality operator parameters:
"b = a" and "a = b" are not same.
An equality propagation algorithm has been fixed:
the substitute_for_best_equal_field function should not
substitute a field for an equal field if both fields belong
to the same table.
mysql-test/r/select.result:
Added test case for bug #40925.
mysql-test/t/select.test:
Added test case for bug #40925.
sql/item.cc:
Bug #40925: Equality propagation takes non indexed attribute
An equality propagation algorithm has been fixed:
the substitute_for_best_equal_field function should not
substitute a field for an equal field if both fields belong
to the same table.
Original commentary:
Bug #37348: Crash in or immediately after JOIN::make_sum_func_list
The optimizer pulls up aggregate functions which should be aggregated in
an outer select. At some point it may substitute such a function for a field
in the temporary table. The setup_copy_fields function doesn't take this
into account and may overrun the copy_field buffer.
Fixed by filtering out the fields referenced through the specialized
reference for aggregates (Item_aggregate_ref).
Added an assertion to make sure bugs that cause similar discrepancy
don't go undetected.
mysql-test/r/func_group.result:
Backport bug #37348 fix 5.1 --> 5.0.
mysql-test/t/func_group.test:
Backport bug #37348 fix 5.1 --> 5.0.
sql/item.cc:
Backport bug #37348 fix 5.1 --> 5.0.
sql/item.h:
Backport bug #37348 fix 5.1 --> 5.0.
sql/sql_select.cc:
Backport bug #37348 fix 5.1 --> 5.0.
UNION could convert fixed-point FLOAT(M,D)/DOUBLE(M,D) columns
to FLOAT/DOUBLE when aggregating data types from the SELECT
substatements. While there is nothing particularly wrong with
this behavior, especially when M is greater than the hardware
precision limits, it could be confusing in cases when all
SELECT statements in a union have the same
FLOAT(M,D)/DOUBLE(M,D) columns with equal precision
specifications listed in the same position.
Since the manual is quite vague on what data type should be
returned in such cases, the bug was fixed by implementing the
most 'expected' behavior: do not convert FLOAT(M,D)/DOUBLE(M,D)
to anything else if all SELECT statements in a UNION have the
same precision for that column.
mysql-test/r/union.result:
Added a test case for bug #43432.
mysql-test/t/union.test:
Added a test case for bug #43432.
sql/field.cc:
Replaced FLT_DIG+6 and DBL_DIG+7 with a symbolic constant.
sql/item.cc:
Do not convert FLOAT(M,D)/DOUBLE(M,D)
to anything else if all SELECT statements in a UNION have the
same precision for that column.
sql/mysql_priv.h:
Added a symbolic constant for FLT_DIG+6 and DBL_DIG+7.
When add an aliase name after NAME_CONST, the aliase name will be overwrite.
NAME_CONST will re-set the field's name only if there isn't an aliase in the
function fix-fields().
If there is an aliase, NAME_CONST doesn't re-set the field's name and keeps the old
name.
mysql-test/r/func_misc.result:
Test result.
mysql-test/r/rpl_name_const.result:
Test case.
mysql-test/t/func_misc.test:
Add NAME_CONST test.
mysql-test/t/rpl_name_const.test:
Test result.
sql/item.cc:
Re-set field's name if the name is autogenerated, that mean without aliase.
