into  moonbone.local:/work/21475-fix-5.0-opt-mysql

  Additional fix for bug #21475
item_func.h, item_func.cc:
  Additional fix for bug#16861


sql/item_func.h:
  Additional fix for bug#16861
sql/item_func.cc:
  Additional fix for bug#16861
sql/item_cmpfunc.cc:
  Additional fix for bug #21475
sql/item.cc:
  Additional fix for bug #21475

into  rurik.mysql.com:/home/igor/mysql-5.0-opt

into  sunlight.local:/local_work/16861-bug-5.0-mysql


sql/sql_select.cc:
  Auto merged

used.

Sorting by RAND() uses a temporary table in order to get a correct results.
User defined variable was set during filling the temporary table and later
on it is substituted for its value from the temporary table. Due to this
it contains the last value stored in the temporary table.

Now if the result_field is set for the Item_func_set_user_var object it 
updates variable from the result_field value when being sent to a client.

The Item_func_set_user_var::check() now accepts a use_result_field
parameter. Depending on its value the result_field or the args[0] is used
to get current value.


mysql-test/r/user_var.result:
  Added a test case for bug#16861: User defined variable can have a wrong value if a tmp table was used.
mysql-test/t/user_var.test:
  Added a test case for bug#16861: User defined variable can have a wrong value if a tmp table was used.
sql/item_func.cc:
  Fixed bug#16861: User defined variable can have a wrong value if a tmp table was used.
  Now if the result_field is set for the Item_func_set_user_var object it 
  updates variable from the result_field value when being sent to a client.
  
  The Item_func_set_user_var::check() now accepts a use_result_field
  parameter. Depending on its value the result_field or the args[0] is used
  to get current value.
sql/item_func.h:
  Fixed bug#16861: User defined variable can have a wrong value if a tmp table was used.
  Added a new SUSERVAR_FUNC function type.
  Updated the Item_func_set_user_var::check() function declaration.
  Added the Item_func_set_user_var::send() member function.
sql/set_var.cc:
  Fixed bug#16861: User defined variable can have a wrong value if a tmp table was used.
  Modified to use updated Item_func_set_user_var::check() function.
sql/sql_class.cc:
  Fixed bug#16861: User defined variable can have a wrong value if a tmp table was used.
  Modified to use updated Item_func_set_user_var::check() function.
sql/sql_select.cc:
  Fixed bug#16861: User defined variable can have a wrong value if a tmp table was used.
  Now an Item_func_set_user_var object isn't substituted for an Item_field object after filling a temporary table.

into  moonbone.local:/work/21475-bug-5.0-opt-mysql

buffer for a MY_BITMAP temporary buffer allocated on stack in the
function get_best_covering_ror_intersect().
Now the buffer of a proper size is allocated by a request from this
function in mem_root.

We succeeded to demonstrate the bug only on Windows with a very large
database. That's why no test case is provided for in the patch.


sql/opt_range.cc:
  Fixed bug 16201: a memory corruption causing crashes due to a too small 
  buffer for a MY_BITMAP temporary buffer allocated on stack in the
  function get_best_covering_ror_intersect().
  Now the buffer of a proper size is allocated by a request from this
  function in mem_root.

Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0
 - moved an InnoDB dependent test to the appropriate file


mysql-test/r/innodb_mysql.result:
  Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0
   - moved an InnoDB dependent test to the appropriate file
mysql-test/r/join_outer.result:
  Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0
   - moved an InnoDB dependent test to the appropriate file
mysql-test/t/innodb_mysql.test:
  Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0
   - moved an InnoDB dependent test to the appropriate file
mysql-test/t/join_outer.test:
  Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0
   - moved an InnoDB dependent test to the appropriate file

A date can be represented as an int (like 20060101) and as a string (like
"2006.01.01"). When a DATE/TIME field is compared in one SELECT against both
representations the constant propagation mechanism leads to comparison
of DATE as a string and DATE as an int. In this example it compares 2006 and
20060101 integers. Obviously it fails comparison although they represents the
same date.


Now the Item_bool_func2::fix_length_and_dec() function sets the comparison
context for items being compared. I.e. if items compared as strings the
comparison context is STRING.
The constant propagation mechanism now doesn't mix items used in different
comparison contexts. The context check is done in the
Item_field::equal_fields_propagator() and in the change_cond_ref_to_const() 
functions.

Also the better fix for bug 21159 is introduced.


mysql-test/t/type_datetime.test:
  Added a test case for bug#21475: Wrongly applied constant propagation leads to a false comparison.
mysql-test/r/type_datetime.result:
  Added a test case for bug#21475: Wrongly applied constant propagation leads to a false comparison.
sql/sql_select.cc:
  Fixed bug#21475: Wrongly applied constant propagation leads to a false comparison.
  The constant propagation mechanism now doesn't mix items used in different
  comparison contexts. The check is done in the change_cond_ref_to_const() function.
sql/item_cmpfunc.cc:
  Fixed bug#21475: Wrongly applied constant propagation leads to a false comparison.
  Now the Item_bool_func2::fix_length_and_dec() function sets the comparison
  context for items being compared.
sql/item.h:
  Fixed bug#21475: Wrongly applied constant propagation leads to a false comparison.
  To the Item class a new field called cmp_context is added.
  It represents the comparison context of an item.
sql/item.cc:
  Fixed bug#21475: Wrongly applied constant propagation leads to a false comparison.
  The constant propagation mechanism now doesn't mix items used in different
  comparison contexts. The context check is done in the
  Item_field::equal_fields_propagator() function.

  Corrected test case result after fix for bug#18165
view.result, view.test:
  Corrected test case for bug#21261


mysql-test/t/view.test:
  Corrected test case for bug#21261
mysql-test/r/view.result:
  Corrected test case for bug#21261
mysql-test/r/ndb_condition_pushdown.result:
  Corrected test case result after fix for bug#18165

into  rurik.mysql.com:/home/igor/mysql-5.0-opt


sql/sql_select.cc:
  Auto merged

Made [NOT]BETWEEN predicates SARGable in respect to the second and 
the third arguments.


mysql-test/r/range.result:
  Added a test case to bug #18165.
mysql-test/t/range.test:
  Added a test case to bug #18165.
sql/opt_range.cc:
  Fixed bug #18165.
  Made [NOT]BETWEEN predicates SARGable in respect to the second and 
  the third arguments.
  Put in a separate function called get_full_func_mm_tree the functionality
  that builds a conjunction of all SEL_TREEs for a simple predicate of the
  form (f op c), where f was a field and c was a constant, applying different
  equalities f=f' with f' being another field.

into  sunlight.local:/local_work/21261-bug-5.0-mysql


sql/sql_select.cc:
  Auto merged
sql/sql_update.cc:
  Auto merged
mysql-test/r/view.result:
  SCCS merged
mysql-test/t/view.test:
  SCCS merged

into  moonbone.local:/work/15950-bug-5.0-opt-mysql

SELECT right instead of INSERT right was required for an insert into to a view.
This wrong behaviour appeared after the fix for bug #20989. Its intention was
to ask only SELECT right for all tables except the very first for a complex
INSERT query. But that patch has done it in a wrong way and lead to asking 
a wrong access right for an insert into a view.

The setup_tables_and_check_access() function now accepts two want_access
parameters. One will be used for the first table and the second for other
tables.


mysql-test/t/view.test:
  Added a test case for bug#21261: Wrong access rights was required for an insert into a view
mysql-test/r/view.result:
  Added a test case for bug#21261: Wrong access rights was required for an insert into a view
sql/sql_update.cc:
  Fixed bug#21261: Wrong access rights was required for an insert into a view
  Modified to use updated setup_tables_and_check_access() function.
sql/sql_select.cc:
  Fixed bug#21261: Wrong access rights was required for an insert into a view
  Modified to use updated setup_tables_and_check_access() function.
sql/sql_load.cc:
  Fixed bug#21261: Wrong access rights was required for an insert into a view
  Modified to use updated setup_tables_and_check_access() function.
sql/sql_insert.cc:
  Fixed bug#21261: Wrong access rights was required for an insert into a view
  Modified to use updated setup_tables_and_check_access() function.
sql/sql_delete.cc:
  Fixed bug#21261: Wrong access rights was required for an insert into a view
  Modified to use updated setup_tables_and_check_access() function.
sql/sql_base.cc:
  Fixed bug#21261: Wrong access rights was required for an insert into a view
  The setup_tables_and_check_access() function now accepts two want_access
  parameters. One will be used for the first table and the second for other
  tables.
sql/mysql_priv.h:
  Fixed bug#21261: Wrong access rights was required for an insert into a view
  The setup_tables_and_check_access() function now accepts two want_access
  parameters.

into  mysql.com:/home/psergey/mysql-5.0-opt-bug21282-r2

In fix for BUG#15872, a condition of type "t.key NOT IN (c1, .... cN)"
where N>1000, was incorrectly converted to
  (-inf < X < c_min) OR (c_max < X)
Now this conversion is removed, we dont produce any range lists for such
conditions.


mysql-test/r/range.result:
  BUG#21282: Testcase
mysql-test/t/range.test:
  BUG#21282: Testcase
sql/opt_range.cc:
  BUG#21282: Incorrect query results for "t.key NOT IN (<big const list>) 
  In fix for BUG#15872, a condition of type "t.key NOT IN (c1, .... cN)"
  where N>1000, was incorrectly converted to 
    (-inf < X < c_min) OR (c_max < X)
  Now this conversion is removed, we dont produce any range lists for such
  conditions.

This bug is a side-effect of bug fix #16377. NOW() is optimized in
BETWEEN to integer constants to speed up query execution. When view is being
created it saves already modified query and thus becomes wrong.

The agg_cmp_type() function now substitutes constant result DATE/TIME functions 
for their results only if the current query isn't CREATE VIEW or SHOW CREATE
VIEW.


mysql-test/t/view.test:
  Added a test case for bug#15950: NOW() optimized away in VIEWs
mysql-test/r/view.result:
  Added a test case for bug#15950: NOW() optimized away in VIEWs
sql/item_cmpfunc.cc:
  Fixed bug#15950: NOW() optimized away in VIEWs
  The agg_cmp_type() function now substitutes constant result DATE/TIME functions 
  for their results only if the current query isn't CREATE VIEW or SHOW CREATE
  VIEW.

BUG#21077: Possible crash caused by invalid sequence of handler::* calls:                                                
The crash was caused by invalid sequence of handler::** calls:                                                           
  ha_smth->index_init();                                                                                                 
  ha_smth->index_next_same(); (2)                                                                                        
(2) is an invalid call as it was not preceeded by any 'scan setup' call
like index_first() or index_read(). The cause was that QUICK_SELECT::reset()
didn't "fully reset" the quick select- current QUICK_RANGE wasn't forgotten,
and quick select might attempt to continue reading the range, which would
result in the above mentioned invalid sequence of handler calls.

5.x versions are not affected by the bug - they already have the missing
"range=NULL" clause.                                                    
                                                       


mysql-test/r/innodb_mysql.result:
  Testcase for BUG#21077
mysql-test/t/innodb_mysql.test:
  Testcase for BUG#21077
sql/opt_range.h:
  BUG#21077: Possible crash caused by invalid sequence of handler::* calls:                                              
   - Make QUICK_SELECT::reset() really reset the quick select

 - undeterminstic tests fixed


mysql-test/r/order_by.result:
  Bug #21302: Result not properly sorted when using an ORDER BY on a second table in a join
   - more undeterminstic tests fixed
mysql-test/t/order_by.test:
  Bug #21302: Result not properly sorted when using an ORDER BY on a second table in a join
   - more undeterminstic tests fixed

            on a second table in a join
- undeterministic output of the test case removed.

into  rakia.(none):/home/kgeorge/mysql/autopush/B21159-5.0-opt


sql/sql_select.cc:
  Auto merged

into  rakia.(none):/home/kgeorge/mysql/autopush/B21174-5.0-opt


sql/sql_select.cc:
  Auto merged

into  rakia.(none):/home/kgeorge/mysql/autopush/B21159-5.0-opt


sql/sql_select.cc:
  Auto merged

Disable const propagation for Item_hex_string.
This must be done because Item_hex_string->val_int() is not
the same as (Item_hex_string->val_str() in BINARY column)->val_int().
We cannot simply disable the replacement in a particular context (
e.g. <bin_col> = <int_col> AND <bin_col> = <hex_string>) since
Items don't know the context they are in and there are functions like 
IF (<hex_string>, 'yes', 'no').
Note that this will disable some valid cases as well 
(e.g. : <bin_col> = <hex_string> AND <bin_col2> = <bin_col>) but 
there's no way to distinguish the valid cases without having the
Item's parent say something like : Item->set_context(Item::STRING_RESULT)
and have all the Items that contain other Items do that consistently.


mysql-test/r/compare.result:
  Bug #21159: Optimizer: wrong result after AND with different data types
   - test case
mysql-test/t/compare.test:
  Bug #21159: Optimizer: wrong result after AND with different data types
   - test case
sql/sql_select.cc:
  Bug #21159: Optimizer: wrong result after AND with different data types
   - disable const propagation for Item_hex_string.

             optimizer does not honor IGNORE INDEX
 - Allow an index to be used for sorting the table 
   instead of filesort only if it is not disabled by
   IGNORE INDEX.


mysql-test/r/group_by.result:
  Bug #21174: Index degrades sort performance and 
               optimizer does not honor IGNORE INDEX
   - test case
mysql-test/t/group_by.test:
  Bug #21174: Index degrades sort performance and 
               optimizer does not honor IGNORE INDEX
   - test case

into  rakia.(none):/home/kgeorge/mysql/autopush/B21302-5.0-opt


mysql-test/r/join_outer.result:
  Auto merged
mysql-test/r/order_by.result:
  Auto merged

             table in a join
 The optimizer removes redundant columns in ORDER BY. It is considering 
redundant every reference to const table column, e.g b in :
create table t1 (a int, b int, primary key(a)); 
select 1 from t1 order by b where a = 1

But it must not remove references to const table columns if the 
const table is an outer table because there still can be 2 values :
the const value and NULL. e.g.:
create table t1 (a int, b int, primary key(a));
select t2.b c from t1 left join t1 t2 on (t1.a = t2.a and t2.a = 5) 
  order by c;


mysql-test/r/join_outer.result:
  Bug #21302: Result not properly sorted when using an ORDER BY on a second 
              table in a join
   - don't remove columns of const tables in ORDER BY if the const table 
     is an outer table.
mysql-test/r/order_by.result:
  Bug #21302: Result not properly sorted when using an ORDER BY on a second 
              table in a join
   - test case
mysql-test/t/order_by.test:
  Bug #21302: Result not properly sorted when using an ORDER BY on a second 
              table in a join
   - test case
sql/sql_select.cc:
  Bug #21302: Result not properly sorted when using an ORDER BY on a second 
              table in a join
   - don't remove columns of const tables in ORDER BY if the const table 
     is an outer table.

into  moonbone.local:/work/tmp_merge-5.0-opt-mysql

into  may.pils.ru:/home/svoj/devel/mysql/BUG7391/mysql-5.0


mysql-test/r/grant.result:
  Manual merge: use local.
mysql-test/t/grant.test:
  Manual merge: use local.
sql/sql_update.cc:
  Manual merge: use local.

mysql-test/r/grant2.result:
  Merge update:  Change between versions, it appears.
mysql-test/r/heap_btree.result:
  Merge update:  Add deterministic ordering of data, as the order is different 
  between versions.
mysql-test/r/mysql_client.result:
  Merge update: Help options changed between versions.
mysql-test/t/heap_btree.test:
  Merge update:  Add deterministic ordering of data, as the order is different 
  between versions.
BitKeeper/deleted/.del-bug20328.test~c76d766fe3e1eb5:
  Delete: mysql-test/t/bug20328.test
BitKeeper/deleted/.del-bug20328.result~4fee68989442c2a3:
  Delete: mysql-test/r/bug20328.result

into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0


client/mysql.cc:
  Auto merged
heap/hp_delete.c:
  Auto merged
mysql-test/t/mysqlbinlog.test:
  Auto merged
scripts/fill_func_tables.sh:
  Auto merged
scripts/mysql_install_db.sh:
  Auto merged
sql/mysqld.cc:
  Auto merged
sql/set_var.cc:
  Auto merged
mysql-test/r/grant2.result:
  Manual merge
mysql-test/r/heap_btree.result:
  Manual merge
mysql-test/r/mysql_client.result:
  Manual merge
mysql-test/t/grant2.test:
  Manual merge
mysql-test/t/heap_btree.test:
  Manual merge
mysql-test/t/mysql_client.test:
  Manual merge

into  may.pils.ru:/home/svoj/devel/mysql/BUG20060/mysql-5.0


myisam/mi_update.c:
  Auto merged

Problem described in this bug report affects MyISAM tables only.

Running mysqld --flush instructs mysqld to sync all changes to disk
after each SQL statement. It worked well for INSERT and DELETE
statements, but it did sync for UPDATE only in case if there was
index change (change of colum that has an index). If no updated column
has an index, data wasn't synced to disk.

This fix makes UPDATE statement to sync data to disk even if there is
no index change (that is only data change) and mysqld is run with
--flush option.


myisam/mi_update.c:
  Every myisam function that updates myisam table must end with
  call to _mi_writeinfo(). If operation (second param of
  _mi_writeinfo()) is not 0 it sets share->changed to 1, that is
  flags that data has changed. If operation is 0, this function
  equals to no-op in this case.
  
  mi_update() must always pass !0 value as operation, since even if
  there is no index change there could be data change.