transfer NO_DEFAULT_VALUE_FLAG flag to new field
mysql-test/r/strict.result:
Fix for bug#17626 CREATE TABLE ... SELECT failure with TRADITIONAL SQL mode
test case
mysql-test/r/type_ranges.result:
Fix for bug#17626 CREATE TABLE ... SELECT failure with TRADITIONAL SQL mode
result fix
mysql-test/t/strict.test:
Fix for bug#17626 CREATE TABLE ... SELECT failure with TRADITIONAL SQL mode
test case
When a CREATE TABLE command created a table from a materialized
view id does not inherit default values from the underlying table.
Moreover the temporary table used for the view materialization
does not inherit those default values.
In the case when the underlying table contained ENUM fields it caused
misleading error messages. In other cases the created table contained
wrong default values.
The code was modified to ensure inheritance of default values for
materialized views.
mysql-test/r/view.result:
Added a test case for bug #19089.
mysql-test/t/view.test:
Added a test case for bug #19089.
sql/field.cc:
Fixed bug ##19089.
Added field dflt_field to the class Field.
This field is set for temp table fields that inherits
default values of items from which they are created.
sql/field.h:
Fixed bug ##19089.
Added field dflt_field to the class Field.
This field is set for temp table fields that inherits
default values of items from which they are created.
sql/sql_select.cc:
Fixed bug #19089.
When a CREATE TABLE command created a table from a materialized
view id does not inherit default values from the underlying table.
Moreover the temporary table used for the view materialization
does not inherit those default values.
The code was modified to ensure inheritance of default values for
materialized views.
When a CREATE TABLE command created a table from a materialized
view id does not inherit default values from the underlying table.
Moreover the temporary table used for the view materialization
does not inherit those default values.
In the case when the underlying table contained ENUM fields it caused
misleading error messages. In other cases the created table contained
wrong default values.
The code was modified to ensure inheritance of default values for
materialized views.
into mysql.com:/home/psergey/mysql-5.1-merge2
mysql-test/r/select.result:
Auto merged
mysql-test/r/subselect.result:
Auto merged
sql/sql_select.cc:
Auto merged
sql/table.h:
Auto merged
sql/opt_range.cc:
Manual merge
Re-work best_access_path() and find_best() to reuse E(#rows(range access)) as
E(#rows(ref[_or_null](const) access) only when it is appropriate.
[This is the final cumulative patch]
mysql-test/r/select.result:
BUG#17379: Testcase
mysql-test/r/subselect.result:
BUG#17379: Updated test results
mysql-test/t/select.test:
BUG#17379: Testcase
sql/opt_range.cc:
BUG#17379: Wrong reuse of E(#rows(range)) as E(#rows(ref(const))):
Make range optimizer together with TABLE::quick_* also return TABLE::quick_n_ranges
sql/sql_select.cc:
BUG#17379: Wrong reuse of E(#rows(range)) as E(#rows(ref(const))):
Re-work best_access_path() to reuse E(#rows(range access)) as
E(#rows(ref[_or_null](const) access) only when it is appropriate.
sql/table.h:
BUG#17379: Wrong reuse of E(#rows(range)) as E(#rows(ref(const))):
Make range optimizer together with TABLE::quick_* also return TABLE::quick_n_ranges
Re-work best_access_path() and find_best() to reuse E(#rows(range access)) as
E(#rows(ref[_or_null](const) access) only when it is appropriate.
[This is the final cumulative patch]
When converting DISTINCT to GROUP BY where the columns are from the covering
index and they are quoted twice in the SELECT list the optimizer is creating
improper processing sequence. This is because of the fact that the columns
of the covering index are not recognized as such and treated as non-index
columns.
Generally speaking duplicate columns can safely be removed from the GROUP
BY/DISTINCT list because this will not add or remove new rows in the
resulting set. Duplicates can be removed even if they are not consecutive
(as is the case for ORDER BY, where the duplicate columns can be removed
only if they are consecutive).
So we can safely transform "SELECT DISTINCT a,a FROM ... ORDER BY a" to
"SELECT a,a FROM ... GROUP BY a ORDER BY a" instead of
"SELECT a,a FROM .. GROUP BY a,a ORDER BY a". We can even transform
"SELECT DISTINCT a,b,a FROM ... ORDER BY a,b" to
"SELECT a,b,a FROM ... GROUP BY a,b ORDER BY a,b".
The fix to this bug consists of checking for duplicate columns in the SELECT
list when constructing the GROUP BY list in transforming DISTINCT to GROUP
BY and skipping the ones that are already in.
mysql-test/r/distinct.result:
test case for the bug without loose index scan
mysql-test/r/group_min_max.result:
test case for the bug
mysql-test/t/distinct.test:
test case for the bug without loose index scan
mysql-test/t/group_min_max.test:
test case for the bug
sql/sql_select.cc:
duplicates check and removal
When converting DISTINCT to GROUP BY where the columns are from the covering
index and they are quoted twice in the SELECT list the optimizer is creating
improper processing sequence. This is because of the fact that the columns
of the covering index are not recognized as such and treated as non-index
columns.
Generally speaking duplicate columns can safely be removed from the GROUP
BY/DISTINCT list because this will not add or remove new rows in the
resulting set. Duplicates can be removed even if they are not consecutive
(as is the case for ORDER BY, where the duplicate columns can be removed
only if they are consecutive).
So we can safely transform "SELECT DISTINCT a,a FROM ... ORDER BY a" to
"SELECT a,a FROM ... GROUP BY a ORDER BY a" instead of
"SELECT a,a FROM .. GROUP BY a,a ORDER BY a". We can even transform
"SELECT DISTINCT a,b,a FROM ... ORDER BY a,b" to
"SELECT a,b,a FROM ... GROUP BY a,b ORDER BY a,b".
The fix to this bug consists of checking for duplicate columns in the SELECT
list when constructing the GROUP BY list in transforming DISTINCT to GROUP
BY and skipping the ones that are already in.
A query with a group by and having clauses could return a wrong
result set if the having condition contained a constant conjunct
evaluated to FALSE.
It happened because the pushdown condition for table with
grouping columns lost its constant conjuncts.
Pushdown conditions are always built by the function make_cond_for_table
that ignores constant conjuncts. This is apparently not correct when
constant false conjuncts are present.
mysql-test/r/having.result:
Added a test case for bug #14927.
mysql-test/t/having.test:
Added a test case for bug #14927.
sql/sql_lex.cc:
Fixed bug #14927.
Initialized fields for having conditions in st_select_lex::init_query().
sql/sql_lex.h:
Fixed bug #14927.
Added a field to restore having condititions for execution in SP and PS.
sql/sql_prepare.cc:
Fixed bug #14927.
Added code to restore havinf conditions for execution in SP and PS.
sql/sql_select.cc:
Fixed bug #14927.
Performed evaluation of constant expressions in having clauses.
If the having condition contains a constant conjunct that is always false
an empty result set is returned after the optimization phase.
In this case the corresponding EXPLAIN command now returns
"Impossible HAVING" in the last column.
A query with a group by and having clauses could return a wrong
result set if the having condition contained a constant conjunct
evaluated to FALSE.
It happened because the pushdown condition for table with
grouping columns lost its constant conjuncts.
Pushdown conditions are always built by the function make_cond_for_table
that ignores constant conjuncts. This is apparently not correct when
constant false conjuncts are present.
The bug was as follows: When merge_key_fields() encounters "t.key=X OR t.key=Y" it will
try to join them into ref_or_null access via "t.key=X OR NULL". In order to make this
inference it checks if Y<=>NULL, ignoring the fact that value of Y may be not yet known.
The fix is that the check if Y<=>NULL is made only if value of Y is known (i.e. it is a
constant).
TODO: When merging to 5.0, replace used_tables() with const_item() everywhere in merge_key_fields().
mysql-test/r/innodb_mysql.result:
Testcase for BUG16798
mysql-test/t/innodb_mysql.test:
Testcase for BUG16798
sql/sql_select.cc:
BUG#16798: Inapplicable ref_or_null query plan and bad query result on random occasions
In merge_key_fields() don't call val->is_null() if the value of val is not known.
The bug was as follows: When merge_key_fields() encounters "t.key=X OR t.key=Y" it will
try to join them into ref_or_null access via "t.key=X OR NULL". In order to make this
inference it checks if Y<=>NULL, ignoring the fact that value of Y may be not yet known.
The fix is that the check if Y<=>NULL is made only if value of Y is known (i.e. it is a
constant).
TODO: When merging to 5.0, replace used_tables() with const_item() everywhere in merge_key_fields().
into mysql.com:/home/my/mysql-5.1
mysql-test/lib/mtr_report.pl:
Auto merged
mysql-test/mysql-test-run.sh:
Auto merged
mysql-test/r/subselect.result:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_test.cc:
Auto merged
sql/sql_view.cc:
Auto merged
sql/sql_lex.cc:
manual merge
into rurik.mysql.com:/home/igor/dev/mysql-5.0-0
mysql-test/r/subselect.result:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/sql_select.cc:
Auto merged
This performance degradation was due to the fact that some
cost evaluation code added into 4.1 in the function find_best was
not merged into the code of the function best_access_path added
together with other code for greedy optimizer.
Added a parameter to the function print_plan. The parameter contains
accumulated cost for a given partial join.
The patch does not include a special test case since this performance
degradation is hard to reproduse with a simple example.
TODO: make the function find_best use the function best_access_path
in order to remove duplication of code which might result in incomplete
merges in the future.
mysql-test/r/delete.result:
Fixed bug #14292: performance degradation for a benchmark query.
Adjusted test results.
mysql-test/r/subselect.result:
Fixed bug #14292: performance degradation for a benchmark query.
Adjusted test results.
sql/mysql_priv.h:
Fixed bug #14292: performance degradation for a benchmark query.
Added a parameter to the function print_plan. The parameter contains
accumulated cost for a given partial join.
sql/sql_select.cc:
Fixed bug #14292: performance degradation for a benchmark query.
This performance degradation was due to the fact that some
cost evaluation code added into 4.1 in the function find_best was
not merged into the code of the function best_access_path added
together with other code for greedy optimizer.
sql/sql_test.cc:
Fixed bug #14292: performance degradation for a benchmark query.
Added a parameter to the function print_plan. The parameter contains
accumulated cost for a given partial join.
This performance degradation was due to the fact that some
cost evaluation code added into 4.1 in the function find_best was
not merged into the code of the function best_access_path added
together with other code for greedy optimizer.
Added a parameter to the function print_plan. The parameter contains
accumulated cost for a given partial join.
The patch does not include a special test case since this performance
degradation is hard to reproduse with a simple example.
TODO: make the function find_best use the function best_access_path
in order to remove duplication of code which might result in incomplete
merges in the future.
into mysql.com:/home/jimw/my/mysql-5.1-clean
mysql-test/r/user_var.result:
Auto merged
mysql-test/r/variables.result:
Auto merged
mysql-test/t/variables.test:
Auto merged
sql/item.cc:
Auto merged
sql/item_func.cc:
Auto merged
sql/sql_select.cc:
Auto merged
mysql-test/mysql-test-run.pl:
Resolve conflict
mysql-test/ndb/ndbcluster.sh:
Resolve conflict
sql/set_var.cc:
Resolve conflict
sql/share/errmsg.txt:
Resolve conflict
client/mysql.cc:
Auto merged
mysql-test/mysql-test-run.sh:
Auto merged
mysql-test/r/func_gconcat.result:
Auto merged
mysql-test/t/rpl_relayrotate.test:
Auto merged
mysys/mf_keycache.c:
Auto merged
BitKeeper/deleted/.del-innodb_unsafe_binlog-master.opt~9cbe1bb3d8696c5b:
Auto merged
mysql-test/t/rpl_stm_until.test:
Auto merged
sql/item_func.cc:
Auto merged
sql/lock.cc:
Auto merged
sql/sql_lex.h:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_union.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
sql/unireg.h:
Auto merged
storage/ndb/src/kernel/SimBlockList.cpp:
Auto merged
storage/ndb/src/kernel/blocks/ndbcntr/NdbcntrInit.cpp:
Auto merged
The bug caused wrong result sets for union constructs of the form
(SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2.
For such queries order lists were concatenated and limit clause was
completely neglected.
mysql-test/r/order_by.result:
Added a test case for bug #18767.
mysql-test/t/order_by.test:
Added a test case for bug #18767.
sql/sql_lex.h:
Fixed bug #18767.
Placed the code the created a fake SELECT_LEX into a separate function.
sql/sql_parse.cc:
Fixed bug #18767.
Placed the code the created a fake SELECT_LEX into a separate function.
sql/sql_select.cc:
Fixed bug #18767.
Changed the condition on which a SELECT is treated as part of a UNION.
The SELECT in
(SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2
now is handled in the same way as the first SELECT in a UNION
sequence.
sql/sql_union.cc:
Fixed bug #18767.
Changed the condition at which a SELECT is treated as part of a UNION.
The SELECT in
(SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2
now is handled in the same way as the first SELECT in a UNION
sequence.
sql/sql_yacc.yy:
Fixed bug #18767.
Changed the condition at which a SELECT is treated as part of a UNION.
The SELECT in
(SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2
now is handled in the same way as the first SELECT in a UNION
sequence. In the same way is handled the SELECT in
(SELECT ... LIMIT n) ORDER BY order list.
Yet if there is neither ORDER BY nor LIMIT in the single-select
union construct
(SELECT ...) ORDER BY order_list
then it is still handled as simple select with an order clause.
The bug caused wrong result sets for union constructs of the form
(SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2.
For such queries order lists were concatenated and limit clause was
completely neglected.
The SQL standard doesn't allow to use in HAVING clause fields that are not
present in GROUP BY clause and not under any aggregate function in the HAVING
clause. However, mysql allows using such fields. This extension assume that
the non-grouping fields will have the same group-wise values. Otherwise, the
result will be unpredictable. This extension allowed in strict
MODE_ONLY_FULL_GROUP_BY sql mode results in misunderstanding of HAVING
capabilities.
The new error message ER_NON_GROUPING_FIELD_USED message is added. It says
"non-grouping field '%-.64s' is used in %-.64s clause". This message is
supposed to be used for reporting errors when some field is not found in the
GROUP BY clause but have to be present there. Use cases for this message are
this bug and when a field is present in a SELECT item list not under any
aggregate function and there is GROUP BY clause present which doesn't mention
that field. It renders the ER_WRONG_FIELD_WITH_GROUP error message obsolete as
being more descriptive.
The resolve_ref_in_select_and_group() function now reports the
ER_NON_GROUPING_FIELD_FOUND error if the strict mode is set and the field for
HAVING clause is found in the SELECT item list only.
sql/share/errmsg.txt:
Added the new ER_NON_GROUPING_FIELD_USED error message for the bug#14169.
mysql-test/t/having.test:
Added test case for the bug#18739: non-standard HAVING extension was allowed in strict ANSI sql mode.
mysql-test/r/having.result:
Added test case for the bug#18739: non-standard HAVING extension was allowed in strict ANSI sql mode.
sql/sql_select.cc:
Added TODO comment to change the ER_WRONG_FIELD_WITH_GROUP to more detailed ER_NON_GROUPING_FIELD_USED message.
sql/item.cc:
Fixed bug#18739: non-standard HAVING extension was allowed in strict ANSI sql mode.
The resolve_ref_in_select_and_group() function now reports the
ER_NON_GROUPING_FIELD_FOUND error if the strict MODE_ONLY_FULL_GROUP_BY mode
is set and the field for HAVING clause is found in the SELECT item list only.
