GROUP BY/DISTINCT pruning optimization must be done before ORDER BY
optimization because ORDER BY may be removed when GROUP BY/DISTINCT
sorts as a side effect, e.g. in
SELECT DISTINCT <non-key-col>,<pk> FROM t1
ORDER BY <non-key-col> DISTINCT
must be removed before ORDER BY as if done the other way around
it will remove both.
mysql-test/r/distinct.result:
Test for BUG#21456.
mysql-test/t/distinct.test:
Test for BUG#21456.
sql/sql_select.cc:
Bug #21456: SELECT DISTINCT(x) produces incorrect results when using order by
GROUP BY/DISTINCT pruning optimization must be done before ORDER BY
optimization because ORDER BY may be removed when GROUP BY/DISTINCT
sorts as a side effect.
into mysql.com:/usr/home/bar/mysql-4.1.b9509
mysql-test/r/ctype_utf8.result:
Auto merged
mysql-test/t/ctype_utf8.test:
Auto merged
sql/sql_select.cc:
Auto merged
into moonbone.local:/work/tmp_merge-4.1-opt-mysql
sql/item_strfunc.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_select.cc:
Auto merged
When processing aggregate functions all tables values are reset
to NULLs at the end of each group.
When doing that if there are no rows found for a group
the const tables must not be reset as they are not recalculated
by do_select()/sub_select() for each group.
mysql-test/r/subselect2.result:
* Bug #20792: Incorrect results from aggregate subquery
- test suite for the bug. This is dependent on InnoDB despite
the fact that the bug and the fix are not InnoDB specific.
This is because of the table flag HA_NOT_EXACT_COUNT.
When this flag is off (as in MyISAM) both t2 and t3 become of
join type 'system' as they are estimated to have 1 record and
and this statistics can be trusted (according to the absence of
HA_NOT_EXACT_COUNT).
mysql-test/t/subselect2.test:
* Bug #20792: Incorrect results from aggregate subquery
- test suite for the bug
sql/sql_select.cc:
* Bug #20792: Incorrect results from aggregate subquery
- when clearing results if there are not rows found for group
the const tables must not be reset as they are not recalculated
for each group.
Too many cursors (more than 1024) could lead to memory corruption.
This affects both, stored routines and C API cursors, and the
threshold is per-server, not per-connection. Similarly, the
corruption could happen when the server was under heavy load
(executing more than 1024 simultaneous complex queries), and this is
the reason why this bug is fixed in 4.1, which doesn't support
cursors.
The corruption was caused by a bug in the temporary tables code, when
an attempt to create a table could lead to a write beyond allocated
space. Note, that only internal tables were affected (the tables
created internally by the server to resolve the query), not tables
created with CREATE TEMPORARY TABLE. Another pre-condition for the
bug is TRUE value of --temp-pool startup option, which, however, is a
default.
The cause of a bug was that random memory was overwritten in
bitmap_set_next() due to out-of-bound memory access.
mysys/my_bitmap.c:
Local 'bitmap_size' is measured in bytes, no need to multiply it by 8.
sql/sql_select.cc:
Clear the temp_pool_slot bit only if we have set it previously.
When optimizing conditions like 'a = <some_val> OR a IS NULL' so that they're
united into a single condition on the key and checked together the server must
check which value is the NULL value in a correct way : not only using ->is_null
but also check if the expression doesn't depend on any tables referenced in the
current statement.
This additional check must be performed because that optimization takes place
before the actual execution of the statement, so if the field was initialized
to NULL from a previous statement the optimization would be applied incorrectly.
mysql-test/r/select.result:
Bug #21019: First result of SELECT COUNT(*) different than consecutive runs
- test case
mysql-test/t/select.test:
Bug #21019: First result of SELECT COUNT(*) different than consecutive runs
- test case.
Note that ALTER TABLE is important here : it happens to
leave the Field instance for t1.b set to NULL, witch is vital for
demonstrating the problem fixed by this changeset.
sql/sql_select.cc:
Bug #21019: First result of SELECT COUNT(*) different than consecutive runs
- check whether a value is null taking into account its table dependency.
The problem was in that opt_sum_query() replaced MIN/MAX functions
with the corresponding constant found in a key, but due to imprecise
representation of float numbers, when evaluating the where clause,
this comparison failed.
When MIN/MAX optimization detects that all tables can be removed,
also remove all conjuncts in a where clause that refer to these
tables. As a result of this fix, these conditions are not evaluated
twice, and in the case of float number comparisons we do not discard
result rows due to imprecise float representation.
As a side-effect this fix also corrects an unnoticed problem in
bug 12882.
mysql-test/r/func_group.result:
BUG#20954 - test result adjustment.
Adjusted the test result of bug 12882 which was not preperly fixed.
The current patch corrects the problem that was fully corrected by the
patch for 12882.
The problem was that opt_sum_query() indicated that the optimizer may
remove all tables because all MIN/MAX/COUNT functions are constants,
but this lead to an empty result instead of NULL because the WHERE
clause was still evaluated.
The current fix removes all conjuncts in the where clause that
reference the removed tables, and thus corrects the problem.
mysql-test/r/select.result:
BUG#20954 - added test
mysql-test/r/subselect.result:
BUG#20954 - test result adjustment.
The fix removes those conditions in a where clause that refer to
tables optimized away by MIN/MAX optimization (opt_sum_query()).
mysql-test/t/select.test:
BUG#20954 - added test
sql/sql_select.cc:
Fix for BUG#20954: avg(keyval) retuns 0.38 but max(keyval) returns an empty set
When MIN/MAX optimization detects that all tables can be removed,
also remove all conjuncts in a where clause that refer to these
tables. As a result of this fix, these conditions are not evaluated
twice, and in the case of float number comparisons we do not discard
result rows due to imprecise float representation.
As a side-effect this fix also corrects an unnoticed problem in
bug 12882.
* don't use join cache when the incoming data set is already ordered
for ORDER BY
This choice must be made because join cache will effectively
reverse the join order and the results will be sorted by the index
of the table that uses join cache.
mysql-test/r/innodb_mysql.result:
Bug #17212 results not sorted correctly by ORDER BY when using index
* Test suite for the bug
mysql-test/t/innodb_mysql.test:
Bug #17212 results not sorted correctly by ORDER BY when using index
* Test suite for the bug
sql/sql_select.cc:
Bug #17212 results not sorted correctly by ORDER BY when using index
* don't use join cache when the incoming data set is already sorted
may return a wrong result.
An Item_sum_hybrid object has the was_values flag which indicates whether any
values were added to the sum function. By default it is set to true and reset
to false on any no_rows_in_result() call. This method is called only in
return_zero_rows() function. An ALL/ANY subquery can be optimized by MIN/MAX
optimization. The was_values flag is used to indicate whether the subquery
has returned at least one row. This bug occurs because return_zero_rows() is
called only when we know that the select will return zero rows before
starting any scans but often such information is not known.
In the reported case the return_zero_rows() function is not called and
the was_values flag is not reset to false and yet the subquery return no rows
Item_func_not_all and Item_func_nop_all functions return a wrong
comparison result.
The end_send_group() function now calls no_rows_in_result() for each item
in the fields_list if there is no rows were found for the (sub)query.
mysql-test/t/subselect.test:
Added test case for bug#18503: Queries with a quantified subquery returning empty set may return a wrong result.
mysql-test/r/subselect.result:
Added test case for bug#18503: Queries with a quantified subquery returning empty set may return a wrong result.
sql/sql_select.cc:
Fixed bug#18503: Queries with a quantified subquery returning empty set may return a wrong result.
The end_send_group() function now calls no_rows_in_result() for each item
in the fields_list if there is no matching rows were found.
To make MySQL compatible with some ODBC applications, you can find
the AUTO_INCREMENT value for the last inserted row with the following query:
SELECT * FROM tbl_name WHERE auto_col IS NULL.
This is done with a special code that replaces 'auto_col IS NULL' with
'auto_col = LAST_INSERT_ID'.
However this also resets the LAST_INSERT_ID to 0 as it uses it for a flag
so as to ensure that only the first SELECT ... WHERE auto_col IS NULL
after an INSERT has this special behaviour.
In order to avoid resetting the LAST_INSERT_ID a special flag is introduced
in the THD class. This flag is used to restrict the second and subsequent
SELECTs instead of LAST_INSERT_ID.
mysql-test/r/odbc.result:
test suite for the bug
mysql-test/r/rpl_insert_id.result:
test for the fix in replication
mysql-test/t/odbc.test:
test suite for the bug
mysql-test/t/rpl_insert_id.test:
test for the fix in replication
sql/sql_class.cc:
initialize the flag
sql/sql_class.h:
flag's declaration and set code when setting the last_insert_id
sql/sql_select.cc:
the special flag is used instead of last_insert_id
'SELECT DISTINCT a,b FROM t1' should not use temp table if there is unique
index (or primary key) on a.
There are a number of other similar cases that can be calculated without the
use of a temp table : multi-part unique indexes, primary keys or using GROUP BY
instead of DISTINCT.
When a GROUP BY/DISTINCT clause contains all key parts of a unique
index, then it is guaranteed that the fields of the clause will be
unique, therefore we can optimize away GROUP BY/DISTINCT altogether.
This optimization has two effects:
* there is no need to create a temporary table to compute the
GROUP/DISTINCT operation (or the temporary table will be smaller if only GROUP
is removed and DISTINCT stays or if DISTINCT is removed and GROUP BY stays)
* this causes the statement in effect to become updatable in Connector/Java
because the result set columns will be direct reference to the primary key of
the table (instead to the temporary table that it currently references).
Implemented a check that will optimize away GROUP BY/DISTINCT for queries like
the above.
Currently it will work only for single non-constant table in the FROM clause.
mysql-test/r/distinct.result:
Bug #16458: Simple SELECT FOR UPDATE causes "Result Set not updatable" error
- test case
mysql-test/t/distinct.test:
Bug #16458: Simple SELECT FOR UPDATE causes "Result Set not updatable" error
- test case
sql/sql_select.cc:
Bug #16458: Simple SELECT FOR UPDATE causes "Result Set not updatable" error
- disable GROUP BY if contains the fields of a unique index.
tables
Currently in INSERT ... SELECT ... LIMIT ... the compiler uses a
temporary table to store the results of SELECT ... LIMIT .. and then
uses that table as a source for INSERT. The problem is that in some cases
it actually skips the LIMIT clause in doing that and materializes the
whole SELECT result set regardless of the LIMIT.
This fix is limiting the process of filling up the temp table with only
that much rows that will be actually used by propagating the LIMIT value.
mysql-test/r/insert_select.result:
* Bug #9676: INSERT INTO x SELECT .. FROM x LIMIT 1; slows down with big
tables
- a test demonstrating the code path
mysql-test/t/insert_select.test:
* Bug #9676: INSERT INTO x SELECT .. FROM x LIMIT 1; slows down with big
tables
- a test demonstrating the code path
sql/sql_select.cc:
* Bug #9676: INSERT INTO x SELECT .. FROM x LIMIT 1; slows down with big
tables
- pass through the real LIMIT number if the temp table is created for
buffering results.
- set the counter for all the cases when the temp table is not used for
grouping
The bug report revealed two problems related to min/max optimization:
1. If the length of a constant key used in a SARGable condition for
for the MIN/MAX fields is greater than the length of the field an
unwanted warning on key truncation is issued;
2. If MIN/MAX optimization is applied to a partial index, like INDEX(b(4))
than can lead to returning a wrong result set.
mysql-test/r/func_group.result:
Added test cases for bug #18206.
mysql-test/t/func_group.test:
Added test cases for bug #18206.
sql/opt_sum.cc:
Fixed bug #18206.
Suppressed the warning about data truncation when store_val_in_field
was used to store keys for the field used in MIN/MAX optimization.
Blocked MIN/MAX optimization for partial keys, such as in INDEX(b(4)).
sql/sql_select.cc:
Fixed bug #18206.
Added a parameter for the function store_val_in_field allowing to
control setting warnings about data truncation in the function.
sql/sql_select.h:
Fixed bug #18206.
Added a parameter for the function store_val_in_field allowing to
control setting warnings about data truncation in the function.
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.
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 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.
Fixing part2 of this problem: AND didn't work well
with utf8_czech_ci and utf8_lithianian_ci in some cases.
The problem was because when during condition optimization
field was replaced with a constant, the constant's collation
and collation derivation was used later for comparison instead
of the field collation and derivation, which led to non-equal
new condition in some cases.
This patch copies collation and derivation from the field being removed
to the new constant, which makes comparison work using the same collation
with the one which would be used if no condition optimization were done.
In other words:
where s1 < 'K' and s1 = 'Y';
was rewritten to:
where 'Y' < 'K' and s1 = 'Y';
Now it's rewritten to:
where 'Y' collate collation_of_s1 < 'K' and s1 = 'Y'
(using derivation of s1)
Note, the first problem of this bug (with latin1_german2_ci) was fixed
earlier in 5.0 tree, in a separate changeset.
mysql-test/r/ctype_utf8.result:
Adding test case
mysql-test/t/ctype_utf8.test:
Adding test case
sql/sql_select.cc:
Set proper collation of the new item
used
In a simple queries a result of the GROUP_CONCAT() function was always of
varchar type.
But if length of GROUP_CONCAT() result is greater than 512 chars and temporary
table is used during select then the result is converted to blob, due to
policy to not to store fields longer than 512 chars in tmp table as varchar
fields.
In order to provide consistent behaviour, result of GROUP_CONCAT() now
will always be converted to blob if it is longer than 512 chars.
Item_func_group_concat::field_type() is modified accordingly.
mysql-test/t/func_gconcat.test:
Added test case for bug#14169: type of group_concat() result changed to blob if tmp_table was used
mysql-test/r/func_gconcat.result:
Added test case for bug#14169: type of group_concat() result changed to blob if tmp_table was used
sql/unireg.h:
Added the CONVERT_IF_BIGGER_TO_BLOB constant
sql/sql_select.cc:
Fixed bug#14169: type of group_concat() result changed to blob if tmp_table was used
The unnamed constant 255 in the create_tmp_field() and create_tmp_field_from_item() functions now defined as the CONVERT_IF_BIGGER_TO_BLOB constant.
The create_tmp_field() function now converts the Item_sum string result to a blob field based on its char length.
sql/item_sum.h:
Fixed bug#14169: type of group_concat() result changed to blob if tmp_table was used
To the Item_func_group_concat calls added the member function field_type() which returns the BLOB or VAR_STRING type based on the items length.
sql/item_func.cc:
Fixed bug#14169: type of group_concat() result changed to blob if tmp_table was used
In the Item_func::tmp_table_field() function the unnamed constant 255 is changed to the CONVERT_IF_BIGGER_TO_BLOB constant.
The Item_func::tmp_table_field() function now measures the result length in chars rather than bytes when converting string result to a blob.
The GROUP_CONCAT uses its own temporary table. When ROLLUP is present
it creates the second copy of Item_func_group_concat. This copy receives the
same list of arguments that original group_concat does. When the copy is
set up the result_fields of functions from the argument list are reset to the
temporary table of this copy.
As a result of this action data from functions flow directly to the ROLLUP copy
and the original group_concat functions shows wrong result.
Since queries with COUNT(DISTINCT ...) use temporary tables to store
the results the COUNT function they are also affected by this bug.
The idea of the fix is to copy content of the result_field for the function
under GROUP_CONCAT/COUNT from the first temporary table to the second one,
rather than setting result_field to point to the second temporary table.
To achieve this goal force_copy_fields flag is added to Item_func_group_concat
and Item_sum_count_distinct classes. This flag is initialized to 0 and set to 1
into the make_unique() member function of both classes.
To the TMP_TABLE_PARAM structure is modified to include the similar flag as
well.
The create_tmp_table() function passes that flag to create_tmp_field().
When the flag is set the create_tmp_field() function will set result_field
as a source field and will not reset that result field to newly created
field for Item_func_result_field and its descendants. Due to this there
will be created copy func to copy data from old result_field to newly
created field.
mysql-test/t/func_gconcat.test:
Added test for bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
mysql-test/r/func_gconcat.result:
Added test for bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
sql/sql_table.cc:
Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
Added 0 as a last parameter to create_tmp_field() to force old behaviour.
sql/sql_select.cc:
Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
Added the flag 'make_copy_field' to create_tmp_field(), so that for Item_result_field descendants create_tmp_field() sets the item's result field as a source field and deny resetting that result field to a new value.
sql/sql_class.h:
Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
Added the flag 'force_copy_fields' to the structure TMP_TABLE_PARAM in order to make create_tmp_field() force the creation of 'copy_field' objects.
sql/mysql_priv.h:
Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
Added the bool parameter 'make_copy_field' to create_tmp_field().
sql/item_sum.cc:
Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
Added initialization of the force_copy_fields flag and passing it to create_tmp_table() through TMP_TBLE_PARAM in the Item_func_group_concat and Item_sum_count_distinct member functions.
sql/item_sum.h:
Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
Added the flag 'force_copy_fields' to the Item_func_group_concat and Item_sum_count_distinct classes.
mysql-test/r/kill.result:
BUG#14851 test
mysql-test/t/kill.test:
BUG#14851 test
sql/sql_class.cc:
Debug prints are added.
sql/sql_select.cc:
Allocation of tmp_join fixed to involve constructor (it is not related to the bug directly but might cause other problems).
Excluded posibility of tmp_table_param.copy_field double deletion (BUG#14851).
sql/sql_select.h:
JOINs constructor added, initialization of them fixed (it is not related to the bug directly but might cause other problems).
into mysql.com:/home/my/mysql-4.1
client/mysqlimport.c:
Auto merged
myisam/myisam_ftdump.c:
Auto merged
sql/sql_select.cc:
Auto merged
sql/item_cmpfunc.cc:
merge (keep old code)
sql/sql_handler.cc:
manual merge
mysql-test/r/having.result:
Added a test case for bug #14274.
mysql-test/t/having.test:
Added a test case for bug #14274.
sql/sql_select.cc:
Fixed bug #14274: a query with a having clause containing only set function returned a wrong result set.
It happened because processing of the set functions in having started with a call of the split_sum_func
method, instead of the split_sum_func2 method.
Remove wrong fix for Bug#14397 - OPTIMIZE TABLE with an open HANDLER causes a crash
Safety fix for bug #13855 "select distinct with group by caused server crash"
client/mysqlimport.c:
Remove not used variable
myisam/myisam_ftdump.c:
Fixed compiler warning
sql/item_cmpfunc.cc:
Removed compiler warning
sql/sql_handler.cc:
Remove wrong fix for Bug#14397 - OPTIMIZE TABLE with an open HANDLER causes a crash.
It's better to let mysql_lock_tables reopen the TABLE object in case of OPTIMIZE TABLE and fix items AFTER mysql_lock_table() instead of before
sql/sql_select.cc:
Safety fix for bug #13855 "select distinct with group by caused server crash"
The previous patch only removed the symptomps, this fix removed the cause of the problem
(Which was that not all hidden_fields was stored in the temporary table)
Initialized usable_keys from table->keys_in_use instead of ~0
in test_if_skip_sort_order(). It was possible that a disabled
index was used for sorting.
mysql-test/r/myisam.result:
Bug#14616 - Freshly imported table returns error 124 when using LIMIT
The test result.
mysql-test/t/myisam.test:
Bug#14616 - Freshly imported table returns error 124 when using LIMIT
The test case.
Procedure analyse() redefines select's fields_list. setup_copy_fields() assumes
that fields_list is a part of all_fields_list. Because select have only
3 columns and analyse() redefines it to have 10 columns, int overrun in
setup_copy_fields() occurs and server goes to almost infinite loop.
Because fields_list used not only to send data ad fields types, it's wrong
to allow procedure redefine it. This patch separates select's fileds_list
and procedure's one. Now if procedure is present, copy of fields_list is
created in procedure_fields_list and it is used for sending data and fields.
mysql-test/t/analyse.test:
Test case for bug #14138 ROLLUP and PROCEDURE ANALYSE() hang server
mysql-test/r/analyse.result:
Test case for bug #14138 ROLLUP and PROCEDURE ANALYSE() hang server
sql/sql_select.h:
Fix bug #14138 ROLLUP and PROCEDURE ANALYSE() hang server
To JOIN Added separate fields_list for procedure.
sql/sql_select.cc:
Fix bug #14138 ROLLUP and PROCEDURE ANALYSE() hang server
SELECT's fields_list and procedure's fields_list made split. If procedure is defined
then procedure's fields_list is used to send fields and data.
Date field was declared as not null, thus expression 'datefield is null'
was always false. For SELECT special handling of such cases is used.
There 'datefield is null' converted to 'datefield eq "0000-00-00"'.
In mysql_update() before creation of select added remove_eq_conds() call.
It makes some optimization of conds and in particular performs conversion
from 'is null' to 'eq'.
Also remove_eq_conds() makes some evaluation of conds and if it founds that
conds is always false then update statement is not processed further.
All this allows to perform some update statements process faster due to
optimized conds, and not wasting resources if conds known to be false.
sql/sql_select.cc:
Fix bug#14186 select datefield is null not updated
Remove static from remove_eq_conds()
sql/sql_select.h:
Fix bug#14186 select datefield is null not updated
Added remove_eq_conds() prototype.
mysql-test/r/update.result:
Test case for bug#14186 select datefield is null not updated
mysql-test/t/update.test:
Test case for bug#14186 select datefield is null not updated
sql/sql_update.cc:
Fix bug#14186 select datefield is null not updated
To mysql_update() added call to remove_eq_conds() to optimize conds and convert 'datefield is null' to 'datefield eq 0000-00-00'
include/config-netware.h:
Auto merged
sql/sql_select.cc:
Auto merged
mysql-test/r/select.result:
Manually merged fix for bug#13855
mysql-test/t/select.test:
Manuall merged fix for bug#13855
DISTINCT wasn't optimized away and caused creation of tmp table in wrong
case. This result in integer overrun and running out of memory.
Fix backported from 4.1. Now if optimizer founds that in result be only 1
row it removes distinct.
sql/sql_select.cc:
Fix bug #13855 select distinct with group by caused server crash
mysql-test/r/select.result:
Test case for bug#13855 select distinct with group by caused server crash
mysql-test/t/select.test:
Test case for bug#13855 select distinct with group by caused server crash
When fixing Item_func_plus in ORDER BY clause field c is searched in all
opened tables, but because c is an alias it wasn't found there.
This patch adds a flag to select_lex which allows Item_field::fix_fields()
to look up in select's item_list to find aliased fields.
sql/item.cc:
Fix bug#7672 Unknown column error in order clause
When fixing fields in ORDER BY clause allow Item_field::fix_fields() to look up items in select's item list to find aliased fields.
sql/sql_lex.cc:
Fix bug#7672 Unknown column error in order clause
sql/sql_lex.h:
Fix bug#7672 Unknown column error in order clause
Added flag to select_lex allowing Item_field::fix_fields to look up items in select's item list.
sql/sql_select.cc:
Fix bug#7672 Unknown column error in order clause
mysql-test/t/select.test:
Test case for bug#7672 Unknown column error in order clause
mysql-test/r/select.result:
Test case for bug#7672 Unknown column error in order clause
not equivalent to "x=y" when item->negated == TRUE.
mysql-test/r/func_in.result:
Testcase for BUG#13419
mysql-test/t/func_in.test:
Testcase for BUG#13419
sql/sql_select.cc:
Fix for BUG#13419:
* Take into account that item=Item_func_in(x,y) is not equivalent to "x=y" when
item->negated == TRUE.
* Removed comment that is no longer true.
For queries with GROUP BY and without hidden GROUP BY fields DISTINCT is
optimized away becuase such queries produce result set without duplicates.
But ROLLUP can add rows which may be same to some rows and this fact was
ignored.
Added check so if ROLLUP is present DISTINCT can't be optimized away.
sql/sql_select.cc:
Fix bug #12887 Distinct is not always applied after rollup
mysql-test/r/olap.result:
Test case for bug #12887 Distinct is not always applied after rollup
mysql-test/t/olap.test:
Test case for bug #12887 Distinct is not always applied after rollup
Fix for bug #13025; Server crash in filesort because wrong call to handler::position()
client/mysqltest.c:
Code cleanup during review
mysql-test/r/innodb.result:
Added test case for bug #13025; Server crash in filesort because wrong call to handler::position()
mysql-test/t/innodb.test:
Added test case for bug #13025; Server crash in filesort because wrong call to handler::position()
sql/filesort.cc:
Don't call handler::position() if row was not found
sql/item_cmpfunc.cc:
Indentation changes
sql/sql_select.cc:
Moved variable to outer level
Fixed bug #12885.
Forced inheritence of the maybe_null flag for the expressions
containing GROUP BY attributes in selects with ROLLUP.
olap.test, olap.result:
Added test case for bug #12885.
mysql-test/r/olap.result:
Added test case for bug #12885.
mysql-test/t/olap.test:
Added test case for bug #12885.
sql/sql_select.cc:
Fixed bug #12885.
Forced inheritence of the maybe_null flag for the expressions
containing GROUP BY attributes in selects with ROLLUP.
Item::tmp_table_field_from_field_type() and create_tmp_field_from_item()
was converting string field to blob depending on byte-wise length instead of
character length, which results in converting valid varchar string with
length == 86 to longtext.
Made that functions above take into account max width of character when
converting string fields to blobs.
sql/item.cc:
Fix bug #12537 UNION produces longtext instead of varchar
Item::tmp_table_field_from_field_type() now taking into account max char width when creating tmp field for string fields.
sql/sql_select.cc:
Fix bug #12537 UNION produces longtext instead of varchar
create_tmp_field_from_item()now taking into account max char width when creating tmp field for string fields.
mysql-test/r/create.result:
Test case for bug #12537 UNION produces longtext instead of varchar
mysql-test/t/create.test:
Test case for bug #12537 UNION produces longtext instead of varchar
