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
into chilla.local:/home/mydev/mysql-5.1-toteam
mysql-test/t/disabled.def:
Auto merged
BitKeeper/deleted/.del-index_merge_innodb.result:
Auto merged
mysql-test/include/index_merge2.inc:
Auto merged
mysql-test/include/mix1.inc:
Auto merged
sql/handler.cc:
Auto merged
sql/handler.h:
Auto merged
sql/opt_range.cc:
Auto merged
storage/myisam/ha_myisam.cc:
Auto merged
storage/myisam/ha_myisam.h:
Auto merged
mysql-test/include/handler.inc:
Manual merge 5.1 -> 5.1-engines
mysql-test/r/innodb_mysql.result:
Manual merge 5.1 -> 5.1-engines
into april.(none):/home/svoj/devel/mysql/BUG20256/mysql-5.1-engines
sql/ha_myisam.cc:
Auto merged
sql/ha_myisam.h:
Auto merged
sql/handler.cc:
Auto merged
BitKeeper/deleted/.del-index_merge.result:
Auto merged
mysql-test/include/index_merge1.inc:
Manual merge.
sql/handler.h:
Manual merge.
sql/opt_range.cc:
Manual merge.
Only MyISAM tables locked with LOCK TABLES ... WRITE were affected.
A query that is optimized with index_merge doesn't reflect rows
inserted within LOCK TABLES.
MyISAM doesn't flush a state within LOCK TABLES. index_merge
optimization creates a copy of the handler, which thus gets
outdated MyISAM state.
New handler->clone() method is introduced to fix this problem.
For non-MyISAM storage engines it allocates a handler and opens
it with ha_open(). For MyISAM it additionally copies MyISAM state
pointer to cloned handler.
mysql-test/r/index_merge.result:
A test case for bug#20256.
mysql-test/t/index_merge.test:
A test case for bug#20256.
sql/ha_myisam.cc:
clone method added to handler class.
sql/ha_myisam.h:
clone method added to handler class.
sql/handler.cc:
clone method added to handler class.
sql/handler.h:
clone method added to handler class.
sql/opt_range.cc:
Use handler clone method.
Only MyISAM tables locked with LOCK TABLES ... WRITE were affected.
A query that is optimized with index_merge doesn't reflect rows
inserted within LOCK TABLES.
MyISAM doesn't flush a state within LOCK TABLES. index_merge
optimization creates a copy of the handler, which thus gets
outdated MyISAM state.
New handler->clone() method is introduced to fix this problem.
For non-MyISAM storage engines it allocates a handler and opens
it with ha_open(). For MyISAM it additionally copies MyISAM state
pointer to cloned handler.
when a range condition use an invalid DATETIME constant.
Now we do not use invalid DATETIME constants to form end keys for
range intervals: range analysis just ignores predicates with such
constants.
mysql-test/r/query_cache.result:
Adjusted result warnings when adding a fix for bug #16249.
mysql-test/r/range.result:
Added a test case for bug #16249.
mysql-test/t/range.test:
Added a test case for bug #16249.
when a range condition use an invalid DATETIME constant.
Now we do not use invalid DATETIME constants to form end keys for
range intervals: range analysis just ignores predicates with such
constants.
After merge changes
mysql-test/r/ndb_condition_pushdown.result:
After merge changes
sql/sql_base.cc:
After merge changes
sql/opt_range.cc:
After merge changes
into moonbone.local:/work/tmp_merge-5.1-opt-mysql
BUILD/check-cpu:
Auto merged
include/config-netware.h:
Auto merged
mysql-test/r/func_time.result:
Auto merged
mysql-test/r/group_by.result:
Auto merged
mysql-test/r/join_outer.result:
Auto merged
mysql-test/r/ndb_condition_pushdown.result:
Auto merged
mysql-test/r/range.result:
Auto merged
mysql-test/r/select.result:
Auto merged
mysql-test/r/subselect.result:
Auto merged
mysql-test/r/type_datetime.result:
Auto merged
mysql-test/r/user_var.result:
Auto merged
mysql-test/r/view.result:
Auto merged
mysql-test/t/func_time.test:
Auto merged
mysql-test/t/range.test:
Auto merged
mysql-test/t/select.test:
Auto merged
mysql-test/t/type_datetime.test:
Auto merged
mysql-test/t/view.test:
Auto merged
sql/ha_innodb.cc:
Auto merged
sql/item.cc:
Auto merged
sql/item.h:
Auto merged
sql/item_func.cc:
Auto merged
sql/item_func.h:
Auto merged
sql/item_subselect.cc:
Auto merged
sql/item_timefunc.cc:
Auto merged
sql/opt_range.h:
Auto merged
sql/set_var.cc:
Auto merged
sql/sql_acl.cc:
Auto merged
sql/sql_class.cc:
Auto merged
sql/sql_delete.cc:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_load.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_update.cc:
Auto merged
storage/innobase/btr/btr0btr.c:
Auto merged
storage/innobase/buf/buf0buf.c:
Auto merged
storage/innobase/dict/dict0dict.c:
Auto merged
storage/innobase/fil/fil0fil.c:
Auto merged
storage/innobase/fsp/fsp0fsp.c:
Auto merged
storage/innobase/include/buf0buf.ic:
Auto merged
storage/innobase/log/log0log.c:
Auto merged
storage/innobase/log/log0recv.c:
Auto merged
storage/innobase/os/os0file.c:
Auto merged
storage/innobase/row/row0sel.c:
Auto merged
storage/innobase/srv/srv0start.c:
Auto merged
storage/innobase/ut/ut0dbg.c:
Auto merged
tests/mysql_client_test.c:
Auto merged
client/mysqltest.c:
Manual merge
mysql-test/r/innodb_mysql.result:
Manual merge
mysql-test/t/innodb_mysql.test:
Manual merge
mysql-test/t/join_outer.test:
Manual merge
sql/item_cmpfunc.cc:
Manual merge
sql/mysql_priv.h:
Manual merge
sql/opt_range.cc:
Manual merge
sql/sql_base.cc:
Manual merge
storage/innobase/include/btr0cur.ic:
Manual merge
storage/innobase/row/row0mysql.c:
Manual merge
