into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.1-opt
BitKeeper/deleted/.del-bdb.result:
Auto merged
mysql-test/r/func_gconcat.result:
Auto merged
mysql-test/r/group_min_max.result:
Auto merged
mysql-test/r/innodb.result:
Auto merged
mysql-test/r/merge.result:
Auto merged
mysql-test/r/myisam.result:
Auto merged
mysql-test/r/olap.result:
Auto merged
mysql-test/r/select.result:
Auto merged
mysql-test/r/type_decimal.result:
Auto merged
mysql-test/r/view.result:
Auto merged
mysql-test/t/func_gconcat.test:
Auto merged
mysql-test/t/group_min_max.test:
Auto merged
mysql-test/t/select.test:
Auto merged
sql/item_cmpfunc.cc:
Auto merged
sql/item_cmpfunc.h:
Auto merged
sql/opt_range.cc:
Auto merged
sql/opt_range.h:
Auto merged
sql/sql_base.cc:
Auto merged
sql/sql_delete.cc:
Auto merged
sql/sql_lex.cc:
Auto merged
sql/sql_lex.h:
Auto merged
sql/sql_select.h:
Auto merged
sql/sql_update.cc:
Auto merged
sql/table.cc:
Auto merged
include/my_base.h:
SCCS merged
mysql-test/include/mix1.inc:
SCCS merged
mysql-test/r/group_by.result:
SCCS merged
mysql-test/r/innodb_mysql.result:
SCCS merged
mysql-test/t/group_by.test:
SCCS merged
sql/sql_select.cc:
SCCS merged
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt
mysql-test/r/merge.result:
Auto merged
mysql-test/r/myisam.result:
Auto merged
mysql-test/r/select.result:
Auto merged
mysql-test/r/view.result:
Auto merged
sql/item_cmpfunc.cc:
Auto merged
sql/item_cmpfunc.h:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/opt_range.cc:
Auto merged
sql/opt_range.h:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_table.cc:
Auto merged
sql/sql_update.cc:
Auto merged
sql/table.cc:
Auto merged
into mysql.com:/usr/home/ram/work/bug20732/my50-bug20732
sql/opt_range.cc:
Auto merged
sql/opt_range.h:
Auto merged
sql/sql_select.cc:
Auto merged
sql/table.cc:
Auto merged
mysql-test/r/range.result:
SCCS merged
mysql-test/t/range.test:
SCCS merged
We miss some records sometimes using RANGE method if we have
partial key segments.
Example:
Create table t1(a char(2), key(a(1)));
insert into t1 values ('a'), ('xx');
select a from t1 where a > 'x';
We call index_read() passing 'x' key and HA_READ_AFTER_KEY flag
in the handler::read_range_first() wich is wrong because we have
a partial key segment for the field and might miss records like 'xx'.
Fix: don't use open segments in such a case.
mysql-test/r/range.result:
Fix for bug #20732: Partial index and long sjis search with '>' fails sometimes
- test result.
mysql-test/t/range.test:
Fix for bug #20732: Partial index and long sjis search with '>' fails sometimes
- test case.
sql/opt_range.cc:
Fix for bug #20732: Partial index and long sjis search with '>' fails sometimes
- check if we have a partial key segment for a Item_func::GT_FUNC;
if so, don't set NEAR_MIN flag in order to use HA_READ_KEY_OR_NEXT
instead of HA_READ_AFTER_KEY.
sql/opt_range.h:
Fix for bug #20732: Partial index and long sjis search with '>' fails sometimes
- key segment 'flag' slot added.
sql/sql_select.cc:
Fix for bug #20732: Partial index and long sjis search with '>' fails sometimes
- test (HA_PART_KEY_SEG | HA_NULL_PART) as we split it in the sql/table.cc
sql/table.cc:
Fix for bug #20732: Partial index and long sjis search with '>' fails sometimes
- set HA_NULL_PART flag instead of HA_PART_KEY_SEG in order not to mix them.
We miss some records sometimes using RANGE method if we have
partial key segments.
Example:
Create table t1(a char(2), key(a(1)));
insert into t1 values ('a'), ('xx');
select a from t1 where a > 'x';
We call index_read() passing 'x' key and HA_READ_AFTER_KEY flag
in the handler::read_range_first() wich is wrong because we have
a partial key segment for the field and might miss records like 'xx'.
Fix: don't use open segments in such a case.
When using index for group by and range access the server isolates
a set of ranges based on the conditions over the key parts of the
index used. Then it uses only the ranges over the GROUP BY fields to
jump from one group to another. Since the GROUP BY fields may form a
prefix over the index, we may use only a prefix of the ranges produced
by the range optimizer.
Each range contains a notion on whether it includes its border values.
The problem is that when using a range prefix, the last range is open
because it assumes that there is a range on the next keypart. Thus when
we use a prefix range as it is, it excludes all border values.
The solution is when ignoring the suffix of the range conditions
(to jump over the GROUP BY prefix only) the server must change the
remaining intervals so they always contain their borders, e.g.
if the whole range was :
(1,-inf) <= (<group_by_col>,<min_max_arg_col>) < (1, 3) we must make
(1) <= (<group_by_col>) <= (1) because (a,b) < (c1,c2) means :
a < c1 OR (a = c1 AND b < c2).
mysql-test/r/group_min_max.result:
Bug #22342: No results returned for query using max and group by
- test case
mysql-test/t/group_min_max.test:
Bug #22342: No results returned for query using max and group by
- test case
sql/opt_range.cc:
Bug #22342: No results returned for query using max and group by
- open the intervals for prefix select when there are more conditions
than used for the prefix search.
sql/opt_range.h:
Bug #22342: No results returned for query using max and group by
- open the intervals for prefix select when there are more conditions
than used for the prefix search.
When using index for group by and range access the server isolates
a set of ranges based on the conditions over the key parts of the
index used. Then it uses only the ranges over the GROUP BY fields to
jump from one group to another. Since the GROUP BY fields may form a
prefix over the index, we may use only a prefix of the ranges produced
by the range optimizer.
Each range contains a notion on whether it includes its border values.
The problem is that when using a range prefix, the last range is open
because it assumes that there is a range on the next keypart. Thus when
we use a prefix range as it is, it excludes all border values.
The solution is when ignoring the suffix of the range conditions
(to jump over the GROUP BY prefix only) the server must change the
remaining intervals so they always contain their borders, e.g.
if the whole range was :
(1,-inf) <= (<group_by_col>,<min_max_arg_col>) < (1, 3) we must make
(1) <= (<group_by_col>) <= (1) because (a,b) < (c1,c2) means :
a < c1 OR (a = c1 AND b < c2).
into neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint
BitKeeper/etc/collapsed:
auto-union
mysql-test/lib/mtr_process.pl:
Auto merged
mysql-test/mysql-test-run.pl:
Auto merged
mysql-test/r/ps.result:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/opt_range.cc:
Auto merged
sql/sql_acl.cc:
Auto merged
into neptunus.(none):/home/msvensson/mysql/mysql-5.1-new-maint
BitKeeper/etc/collapsed:
auto-union
mysql-test/mysql-test-run.pl:
Auto merged
mysql-test/lib/mtr_process.pl:
Auto merged
mysql-test/r/ps.result:
Auto merged
mysql-test/t/ps.test:
Auto merged
sql/item.cc:
Auto merged
sql/item_func.h:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/opt_range.cc:
Auto merged
sql/set_var.cc:
Auto merged
sql/sql_acl.cc:
Auto merged
sql/sql_class.h:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_select.cc:
Auto merged
into neptunus.(none):/home/msvensson/mysql/mysql-5.1-new-maint
BitKeeper/etc/ignore:
auto-union
mysql-test/r/ctype_ucs.result:
Auto merged
mysql-test/r/func_gconcat.result:
Auto merged
mysql-test/r/func_group.result:
Auto merged
mysql-test/r/group_by.result:
Auto merged
mysql-test/r/partition.result:
Auto merged
mysql-test/r/ps.result:
Auto merged
mysql-test/r/subselect.result:
Auto merged
mysql-test/r/view.result:
Auto merged
mysql-test/t/ctype_ucs.test:
Auto merged
mysql-test/t/func_gconcat.test:
Auto merged
mysql-test/t/ps.test:
Auto merged
mysql-test/t/view.test:
Auto merged
sql/field.h:
Auto merged
sql/filesort.cc:
Auto merged
sql/item.cc:
Auto merged
sql/item_cmpfunc.cc:
Auto merged
sql/item_cmpfunc.h:
Auto merged
sql/item_sum.cc:
Auto merged
sql/log.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/mysqld.cc:
Auto merged
sql/opt_range.cc:
Auto merged
sql/sql_base.cc:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_lex.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_view.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
storage/innobase/handler/ha_innodb.cc:
Auto merged
storage/innobase/handler/ha_innodb.h:
Auto merged
storage/myisam/mi_check.c:
Auto merged
sql/share/errmsg.txt:
Manul merge(conflict with new german text)
sql/unireg.cc:
Manual merge(as it is in 5.1)
into mockturtle.local:/home/dlenev/src/mysql-5.1-rt-merge
mysql-test/r/ps.result:
Auto merged
mysql-test/t/ps.test:
Auto merged
sql/item.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/opt_range.cc:
Auto merged
sql/sql_select.cc:
Auto merged
into mockturtle.local:/home/dlenev/src/mysql-5.0-bg20670-2
mysql-test/r/trigger.result:
Auto merged
mysql-test/t/trigger.test:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/opt_range.cc:
Auto merged
sql/opt_range.h:
Auto merged
sql/sql_update.cc:
Auto merged
into mockturtle.local:/home/dlenev/src/mysql-5.1-bg20670
mysql-test/r/trigger.result:
Auto merged
mysql-test/t/trigger.test:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/opt_range.cc:
Auto merged
sql/opt_range.h:
Auto merged
sql/sql_partition.cc:
Auto merged
sql/sql_update.cc:
Auto merged
into rama.(none):/home/jimw/my/mysql-5.1-clean
include/m_ctype.h:
Auto merged
include/m_string.h:
Auto merged
include/my_global.h:
Auto merged
include/my_sys.h:
Auto merged
sql/item_subselect.cc:
Auto merged
sql/item_timefunc.cc:
Auto merged
sql/opt_range.cc:
Auto merged
sql/slave.cc:
Auto merged
sql/sql_acl.cc:
Auto merged
sql/mysql_priv.h:
Resolve conflict
sql/mysqld.cc:
Resolve conflict
sql/set_var.cc:
Resolve conflict
sql/slave.h:
Resolve conflict
sql/sql_class.h:
Resolve conflict
into rama.(none):/home/jimw/my/mysql-5.0-clean
include/my_global.h:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/mysqld.cc:
Auto merged
sql/opt_range.cc:
Auto merged
sql/slave.h:
Auto merged
sql/sql_acl.cc:
Auto merged
sql/sql_class.h:
Auto merged
into rama.(none):/home/jimw/my/mysql-4.1-clean
include/my_global.h:
Auto merged
sql/item_subselect.cc:
Auto merged
sql/item_timefunc.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/opt_range.cc:
Auto merged
sql/set_var.cc:
Auto merged
sql/slave.cc:
Auto merged
sql/sql_acl.cc:
Auto merged
sql/sql_class.h:
Auto merged
sql/mysqld.cc:
Resolve conflict
into rama.(none):/home/jimw/my/mysql-5.0-clean
include/m_ctype.h:
Auto merged
include/m_string.h:
Auto merged
include/my_global.h:
Auto merged
sql/item_subselect.cc:
Auto merged
sql/item_timefunc.cc:
Auto merged
sql/set_var.cc:
Auto merged
sql/slave.cc:
Auto merged
sql/slave.h:
Auto merged
sql/sql_class.h:
Auto merged
include/my_sys.h:
Resolve conflict
sql/mysql_priv.h:
Resolve conflict
sql/mysqld.cc:
Resolve conflict
sql/opt_range.cc:
Resolve conflict
sql/sql_acl.cc:
Resolve conflict
result
The IN function aggregates result types of all expressions. It uses that
type in comparison of left expression and expressions in right part.
This approach works in most cases. But let's consider the case when the
right part contains both strings and integers. In that case this approach may
cause wrong results because all strings which do not start with a digit are
evaluated as 0.
CASE uses the same approach when a CASE expression is given thus it's also
affected.
The idea behind this fix is to make IN function to compare expressions with
different result types differently. For example a string in the left
part will be compared as string with strings specified in right part and
will be converted to real for comparison to int or real items in the right
part.
A new function called collect_cmp_types() is added. It collects different
result types for comparison of first item in the provided list with each
other item in the list.
The Item_func_in class now can refer up to 5 cmp_item objects: 1 for each
result type for comparison purposes. cmp_item objects are allocated according
to found result types. The comparison of the left expression with any
right part expression is now based only on result types of these expressions.
The Item_func_case class is modified in the similar way when a CASE
expression is specified. Now it can allocate up to 5 cmp_item objects
to compare CASE expression with WHEN expressions of different types.
The comparison of the CASE expression with any WHEN expression now based only
on result types of these expressions.
sql/item.cc:
Cleaned up an outdated comment.
sql/item_cmpfunc.cc:
Fixed bug #18360: Type aggregation for IN and CASE may lead to a wrong result
A new function called collect_cmp_types() is added. It collects different
result types for comparison of first item in the provided list with each
other item in the list.
The Item_func_in class now can refer up to 5 cmp_item objects: 1 for each
result type for comparison purposes. cmp_item objects are allocated according
to found result types. The comparison of the left expression with any
right part expression is now based only on result types of these expressions.
The Item_func_case class is modified in the similar way when a CASE
expression is specified. Now it can allocate up to 5 cmp_item objects
to compare CASE expression with WHEN expressions of different types.
The comparison of the CASE expression with any WHEN expression now based only
on result types of these expressions.
sql/item_cmpfunc.h:
Fixed bug#18360: Type aggregation for IN and CASE may lead to a wrong result
The Item_func_in class now can refer up to 5 cmp_item objects.
The Item_func_case class is modified in the similar way.
sql/opt_range.cc:
Fixed bug #18360: Type aggregation for IN and CASE may lead to a wrong
resultSmall code changes due to changes in Item_func_in class.
mysql-test/t/view.test:
Added a test comment
mysql-test/t/func_in.test:
Added a test case for bug#18360: Type aggregation for IN and CASE may lead to a wrong
result
mysql-test/r/func_in.result:
Added a test case for bug#18360: Type aggregation for IN and CASE may lead to a wrong
result
result
The IN function aggregates result types of all expressions. It uses that
type in comparison of left expression and expressions in right part.
This approach works in most cases. But let's consider the case when the
right part contains both strings and integers. In that case this approach may
cause wrong results because all strings which do not start with a digit are
evaluated as 0.
CASE uses the same approach when a CASE expression is given thus it's also
affected.
The idea behind this fix is to make IN function to compare expressions with
different result types differently. For example a string in the left
part will be compared as string with strings specified in right part and
will be converted to real for comparison to int or real items in the right
part.
A new function called collect_cmp_types() is added. It collects different
result types for comparison of first item in the provided list with each
other item in the list.
The Item_func_in class now can refer up to 5 cmp_item objects: 1 for each
result type for comparison purposes. cmp_item objects are allocated according
to found result types. The comparison of the left expression with any
right part expression is now based only on result types of these expressions.
The Item_func_case class is modified in the similar way when a CASE
expression is specified. Now it can allocate up to 5 cmp_item objects
to compare CASE expression with WHEN expressions of different types.
The comparison of the CASE expression with any WHEN expression now based only
on result types of these expressions.
this key does not stop" (5.1 version).
UPDATE statement which WHERE clause used key and which invoked trigger
that modified field in this key worked indefinetely.
This problem occured because in cases when UPDATE statement was
executed in update-on-the-fly mode (in which row is updated right
during evaluation of select for WHERE clause) the new version of
the row became visible to select representing WHERE clause and was
updated again and again.
We already solve this problem for UPDATE statements which does not
invoke triggers by detecting the fact that we are going to update
field in key used for scanning and performing update in two steps,
during the first step we gather information about the rows to be
updated and then doing actual updates. We also do this for
MULTI-UPDATE and in its case we even detect situation when such
fields are updated in triggers (actually we simply assume that
we always update fields used in key if we have before update
trigger).
The fix simply extends this check which is done with help of
check_if_key_used()/QUICK_SELECT_I::check_if_keys_used()
routine/method in such way that it also detects cases when
field used in key is updated in trigger. We do this by
changing check_if_key_used() to take field bitmap instead
field list as argument and passing TABLE::write_set
to it (we also have to add info about fields used in
triggers to this bitmap a bit earlier).
As nice side-effect we have more precise and thus more optimal
perfomance-wise check for the MULTI-UPDATE.
Also check_if_key_used() routine and similar method were renamed
to is_key_used()/is_keys_used() in order to better reflect that
it is simple boolean predicate.
Finally, partition_key_modified() routine now also takes field
bitmap instead of field list as argument.
sql/key.cc:
Now check_if_key_used() takes field bitmap instead of field list as
argument (bitmaps are also used in its implementation).
It is no longer responsible for checking if key uses automatically
updated TIMESTAMP fields, instead callers should properly mark such
fields in field bitmap.
Also renamed this function to is_key_used().
sql/mysql_priv.h:
Renamed check_if_key_used() to is_key_used(), also now this routine
takes field bitmap instead of field list as argument.
sql/opt_range.cc:
QUICK_SELECT_I::check_if_keys_used() method and check_if_key_used()
routine were renamed to is_keys_used()/is_key_used(). Also now they
take bitmap instead of field list as argument.
sql/opt_range.h:
QUICK_SELECT_I::check_if_key_used() method was renamed to is_keys_used().
Now it takes field bitmap instead of field list as argument and no
longer responsible for checking if key uses automatically updated
TIMESTAMP fields. Instead callers should properly mark such fields
in field bitmap.
sql/sql_partition.cc:
partition_key_modified() now takes field bitmap instead of list
as argument.
sql/sql_partition.h:
partition_key_modified() now takes field bitmap as argument
instead of field list.
sql/sql_update.cc:
To detect situation in which trigger modifies part of key which is
going to be used for processing of where clause and thus makes
processing of this update with update-on-the-fly method unsafe
we use check_if_key_used() routine and similar method (which were
renamed to is_key_used()) plus information from TABLE::write_map
bitmap. Note that we have to call TABLE::mark_columns_needed_for_update()
method earlier now to fill this bitmap with information about fields
updated in triggers.
safe_update_on_fly() routine now uses the same approach and no
longer needs list of fields as argument.
this key does not stop" (5.1 version).
UPDATE statement which WHERE clause used key and which invoked trigger
that modified field in this key worked indefinetely.
This problem occured because in cases when UPDATE statement was
executed in update-on-the-fly mode (in which row is updated right
during evaluation of select for WHERE clause) the new version of
the row became visible to select representing WHERE clause and was
updated again and again.
We already solve this problem for UPDATE statements which does not
invoke triggers by detecting the fact that we are going to update
field in key used for scanning and performing update in two steps,
during the first step we gather information about the rows to be
updated and then doing actual updates. We also do this for
MULTI-UPDATE and in its case we even detect situation when such
fields are updated in triggers (actually we simply assume that
we always update fields used in key if we have before update
trigger).
The fix simply extends this check which is done with help of
check_if_key_used()/QUICK_SELECT_I::check_if_keys_used()
routine/method in such way that it also detects cases when
field used in key is updated in trigger. We do this by
changing check_if_key_used() to take field bitmap instead
field list as argument and passing TABLE::write_set
to it (we also have to add info about fields used in
triggers to this bitmap a bit earlier).
As nice side-effect we have more precise and thus more optimal
perfomance-wise check for the MULTI-UPDATE.
Also check_if_key_used() routine and similar method were renamed
to is_key_used()/is_keys_used() in order to better reflect that
it is simple boolean predicate.
Finally, partition_key_modified() routine now also takes field
bitmap instead of field list as argument.
this key does not stop" (version for 5.0 only).
UPDATE statement which WHERE clause used key and which invoked trigger
that modified field in this key worked indefinetely.
This problem occured because in cases when UPDATE statement was
executed in update-on-the-fly mode (in which row is updated right
during evaluation of select for WHERE clause) the new version of
the row became visible to select representing WHERE clause and was
updated again and again.
We already solve this problem for UPDATE statements which does not
invoke triggers by detecting the fact that we are going to update
field in key used for scanning and performing update in two steps,
during the first step we gather information about the rows to be
updated and then doing actual updates. We also do this for
MULTI-UPDATE and in its case we even detect situation when such
fields are updated in triggers (actually we simply assume that
we always update fields used in key if we have before update
trigger).
The fix simply extends this check which is done in check_if_key_used()/
QUICK_SELECT_I::check_if_keys_used() routine/method in such way that
it also detects cases when field used in key is updated in trigger.
As nice side-effect we have more precise and thus more optimal
perfomance-wise check for the MULTI-UPDATE.
Also check_if_key_used()/QUICK_SELECT_I::check_if_keys_used() were
renamed to is_key_used()/QUICK_SELECT_I::is_keys_used() in order to
better reflect that boolean predicate.
Note that this check is implemented in much more elegant way in 5.1
mysql-test/r/trigger.result:
Added test case for bug#20670 "UPDATE using key and invoking trigger that
modifies this key does not stop".
mysql-test/t/trigger.test:
Added test case for bug#20670 "UPDATE using key and invoking trigger that
modifies this key does not stop".
sql/key.cc:
Renamed check_if_key_used() to is_key_used(). Also this routine checks if
key uses field which can be updated by before update trigger defined on the
table. As result we avoid using update-on-the-fly method in cases when trigger
updates part of key which is used by select which filters rows to be updated
and thus avoid infinite updates. By doing such check here we cover both UPDATE
and MULTI-UPDATE cases.
sql/mysql_priv.h:
Renamed check_if_key_used() to is_key_used().
sql/opt_range.cc:
Renamed check_if_key_used()/QUICK_SELECT_I::check_if_keys_used() to
is_key_used()/QUICK_SELECT_I::is_keys_used().
sql/opt_range.h:
Renamed QUICK_SELECT_I::check_if_keys_used() method to is_keys_used(),
also updated comment describing it to reflect its extended semantics
(this change was caused by change in check_if_key_used()/is_key_used()
routine semantics).
sql/sql_trigger.cc:
Introduced Table_triggers_list::is_updated_in_before_update_triggers()
method which is needed for checking if field of subject table can be
changed in before update trigger.
sql/sql_trigger.h:
Table_triggers_list:
Removed has_before_update_triggers() method which is not used any longer.
Added declaration of is_updated_in_before_update_triggers() which is
needed for checking if field of subject table can be changed by before
update trigger.
sql/sql_update.cc:
safe_update_on_fly():
check_if_key_used() routine and check_if_keys_used() method were
renamed to is_key_used()/is_keys_used().
Now cases when trigger updates fields which are part of key used for
filtering rows for update are caught directly in is_key_used().
This also allows to cover both UPDATE and MULTI-UPDATE cases.
this key does not stop" (version for 5.0 only).
UPDATE statement which WHERE clause used key and which invoked trigger
that modified field in this key worked indefinetely.
This problem occured because in cases when UPDATE statement was
executed in update-on-the-fly mode (in which row is updated right
during evaluation of select for WHERE clause) the new version of
the row became visible to select representing WHERE clause and was
updated again and again.
We already solve this problem for UPDATE statements which does not
invoke triggers by detecting the fact that we are going to update
field in key used for scanning and performing update in two steps,
during the first step we gather information about the rows to be
updated and then doing actual updates. We also do this for
MULTI-UPDATE and in its case we even detect situation when such
fields are updated in triggers (actually we simply assume that
we always update fields used in key if we have before update
trigger).
The fix simply extends this check which is done in check_if_key_used()/
QUICK_SELECT_I::check_if_keys_used() routine/method in such way that
it also detects cases when field used in key is updated in trigger.
As nice side-effect we have more precise and thus more optimal
perfomance-wise check for the MULTI-UPDATE.
Also check_if_key_used()/QUICK_SELECT_I::check_if_keys_used() were
renamed to is_key_used()/QUICK_SELECT_I::is_keys_used() in order to
better reflect that boolean predicate.
Note that this check is implemented in much more elegant way in 5.1
into chilla.local:/home/mydev/mysql-5.1-tomain
mysql-test/t/disabled.def:
Auto merged
sql/opt_range.cc:
Auto merged
sql/sql_select.cc:
Auto merged
mysql-test/r/innodb_mysql.result:
Manual merge from 5.1-engines.
into april.(none):/home/svoj/devel/mysql/merge/mysql-5.1-engines
mysql-test/r/myisam.result:
Auto merged
mysql-test/t/myisam.test:
Auto merged
sql/handler.cc:
Auto merged
sql/opt_range.cc:
Auto merged
storage/myisam/ha_myisam.cc:
Auto merged
into april.(none):/home/svoj/devel/mysql/merge/mysql-5.0-engines
mysql-test/r/myisam.result:
Auto merged
mysql-test/t/myisam.test:
Auto merged
sql/ha_ndbcluster.cc:
Auto merged
sql/opt_range.cc:
Auto merged
sql/share/errmsg.txt:
SCCS merged
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.1
mysql-test/r/func_gconcat.result:
Auto merged
mysql-test/r/func_group.result:
Auto merged
mysql-test/r/func_str.result:
Auto merged
mysql-test/r/func_time.result:
Auto merged
mysql-test/r/group_by.result:
Auto merged
mysql-test/r/heap_hash.result:
Auto merged
mysql-test/r/information_schema.result:
Auto merged
mysql-test/r/innodb_mysql.result:
Auto merged
mysql-test/r/join_outer.result:
Auto merged
mysql-test/r/olap.result:
Auto merged
mysql-test/r/query_cache.result:
Auto merged
mysql-test/r/range.result:
Auto merged
mysql-test/r/row.result:
Auto merged
mysql-test/r/subselect.result:
Auto merged
mysql-test/r/type_date.result:
Auto merged
mysql-test/r/union.result:
Auto merged
mysql-test/r/view_grant.result:
Auto merged
mysql-test/t/func_group.test:
Auto merged
mysql-test/t/func_str.test:
Auto merged
mysql-test/t/func_time.test:
Auto merged
mysql-test/t/view.test:
Auto merged
sql/item.cc:
Auto merged
sql/item_func.cc:
Auto merged
sql/item_func.h:
Auto merged
sql/log.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/opt_range.cc:
Auto merged
sql/opt_range.h:
Auto merged
sql/opt_sum.cc:
Auto merged
sql/sql_delete.cc:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_lex.cc:
Auto merged
sql/sql_lex.h:
Auto merged
sql/sql_list.h:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_update.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
mysql-test/t/sp.test:
SCCS merged
sql/item_cmpfunc.cc:
SCCS merged
sql/sql_select.cc:
SCCS merged
