schemas
The function check_one_table_access() called to check access to tables in 
SELECT/INSERT/UPDATE was doing additional checks/modifications that don't hold
in the context of setup_tables_and_check_access().
That's why the check_one_table() was split into two : the functionality needed by
setup_tables_and_check_access() into check_single_table_access() and the rest of 
the functionality stays in check_one_table_access() that is made to call the new
check_single_table_access() function.


mysql-test/r/view_grant.result:
  Bug #20482: failure on Create join view with sources views/tables in different 
              schemas
  - test suite for the bug
mysql-test/t/view_grant.test:
  Bug #20482: failure on Create join view with sources views/tables in different 
              schemas
  - test suite for the bug
sql/mysql_priv.h:
  Bug #20482: failure on Create join view with sources views/tables in different 
              schemas
  - check_one_table_access split into 2
sql/sql_base.cc:
  Bug #20482: failure on Create join view with sources views/tables in different 
              schemas
  - the new sub-function called
sql/sql_parse.cc:
  Bug #20482: failure on Create join view with sources views/tables in different 
              schemas
  - check_one_table_access() split into two : check_single_table_access() to 
    actually check access to the table(ro) and check_one_table_access() that calls
    check_single_table_access() and checks also the tables belonging to sub selects
    or implicitly opened tables.

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


mysql-test/t/func_group.test:
  Auto merged
sql/field.cc:
  Auto merged
sql/opt_sum.cc:
  Auto merged
mysql-test/r/func_group.result:
  SCCS merged

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


sql/field.cc:
  Auto merged
sql/opt_sum.cc:
  Auto merged

into moonbone.local:/work/18175-bug-5.0-opt

resulted in a wrong error message.

The nest_level counter indicates the depth of nesting for a subselect. It is
needed to properly resolve aggregate functions in nested subselects. Obviously 
it shouldn't be incremented for UNION parts because they have the same level of
nesting. This counter was incremented by 1 in the mysql_new_select() function
for any new select and wasn't decremented for UNION parts. This resulted in
wrongly reported error messages.

Now the nest_level counter is decremented by 1 for any union part.


mysql-test/t/union.test:
  Added test case for the bug#18175: The nest_level counter wasn't decremented for union parts which
  resulted in a wrong error message.
mysql-test/r/union.result:
  Added test case for the bug#18175: The nest_level counter wasn't decremented for union parts which
  resulted in a wrong error message.
sql/sql_yacc.yy:
  Fixed bug#18175: The nest_level counter wasn't decremented for union parts which
  resulted in a wrong error message.
  Now the nest_level counter is decremented by 1 for any union part.

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

  After merge fix


mysql-test/r/func_time.result:
  After merge fix
mysql-test/r/func_concat.result:
  After merge fix
mysql-test/r/cast.result:
  After merge fix
sql/item_cmpfunc.h:
  After merge fix
sql/item_cmpfunc.cc:
  After merge fix
sql/field.cc:
  After merge fix

mysql-test/r/cast.result:
  Auto merged
mysql-test/t/func_time.test:
  Auto merged
sql/item_cmpfunc.h:
  Auto merged
sql/item_strfunc.cc:
  Auto merged
sql/item_timefunc.cc:
  Auto merged
sql/item_timefunc.h:
  Auto merged
sql/opt_sum.cc:
  Auto merged
sql/structs.h:
  Auto merged

into moonbone.local:/home/evgen/bk-trees/mysql-4.1-opt

into  mysql.com:/home/kgeorge/mysql/5.0/B18895

into  mysql.com:/home/kgeorge/mysql/5.0/B18895

into moonbone.local:/home/evgen/bk-trees/mysql-5.0-opt

The Field::eq() considered instances of Field_bit that differ only in 
bit_ptr/bit_ofs equal. This caused equality conditions optimization 
(build_equal_items_for_cond()) to make bad field substitutions that result
in wrong predicates. 
Field_bit requires an overloaded eq() function that checks the bit_ptr/bit_ofs
in addition to Field::eq().


mysql-test/r/select.result:
  Bug #18895: BIT values cause joins to fail
  
  - test case
mysql-test/t/select.test:
  Bug #18895: BIT values cause joins to fail
  
  - test case
sql/field.h:
  Bug #18895: BIT values cause joins to fail
  
  - eq() method overloaded for Field_bit

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

into  mysql.com:/home/kgeorge/mysql/5.0/B20195

mysql-test/r/func_group.result:
  Added another test case for bug #18206.
mysql-test/t/func_group.test:
  Added another test case for bug #18206.

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


sql/field.cc:
  Auto merged

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


mysql-test/t/ctype_utf8.test:
  Auto merged
sql/opt_sum.cc:
  Auto merged
mysql-test/r/ctype_utf8.result:
  Manual merge
sql/field.cc:
  Manual merge

This bug in Field_string::cmp resulted in a wrong comparison 
with keys in partial indexes over multi-byte character fields.
Given field a is declared as 
  a varchar(16) collate utf8_unicode_ci
INDEX(a(4)) gives us an example of such an index.

Wrong key comparisons could lead to wrong result sets if 
the selected query execution plan used a range scan by 
a partial index over a utf8 character field.
This also caused wrong results in many other cases.


mysql-test/r/ctype_utf8.result:
  Added test cases for bug #14896.
mysql-test/t/ctype_utf8.test:
  Added test cases for bug #14896.

into moonbone.local:/home/evgen/bk-trees/mysql-4.1-opt

The INSERT DELAYED should not maintain its own private auto-increment
counter, because this is assuming that other threads cannot insert
into the table while the INSERT DELAYED thread is inserting, which is
a wrong assumption.

So the start of processing of a batch of INSERT rows in the 
INSERT DELAYED thread must be treated as a start of a new statement
and cached next_insert_id must be cleared.


mysql-test/r/delayed.result:
  test suite for the bug
mysql-test/t/delayed.test:
  test suite for the bug
sql/sql_insert.cc:
  Reset auto-increment cacheing before processing
  the next batch of inserts in the handler thread

into moonbone.local:/work/16377-bug-4.1-opt-mysql

can lead to a wrong result.

All date/time functions has the STRING result type thus their results are
compared as strings. The string date representation allows a user to skip 
some of leading zeros. This can lead to wrong comparison result if a date/time 
function result is compared to such a string constant.

The idea behind this bug fix is to compare results of date/time functions
and data/time constants as ints, because that date/time representation is 
more exact. To achieve this the agg_cmp_type() is changed to take in the
account that a date/time field or an date/time item should be compared 
as ints.

This bug fix is partially back ported from 5.0.

The agg_cmp_type() function now accepts THD as one of parameters. 
In addition, it now checks if a date/time field/function is present in the
list. If so, it tries to coerce all constants to INT to make date/time
comparison return correct result. The field for the constant coercion is
taken from the Item_field or constructed from the Item_func. In latter case
the constructed field will be freed after conversion of all constant items.
Otherwise the result is same as before - aggregated with help of the
item_cmp_type() function.

From the Item_func_between::fix_length_and_dec() function removed the part
which was converting date/time constants to int if possible. Now this is 
done by the agg_cmp_type() function.

The new function result_as_longlong() is added to the Item class. 
It indicates that the item is a date/time item and result of it can be
compared as int. Such items are date/time fields/functions.

Correct val_int() methods are implemented for classes Item_date_typecast, 
Item_func_makedate, Item_time_typecast, Item_datetime_typecast. All these
classes are derived from Item_str_func and Item_str_func::val_int() converts
its string value to int without regard to the date/time type of these items.

Arg_comparator::set_compare_func() and Arg_comparator::set_cmp_func()
functions are changed to substitute result type of an item with the INT_RESULT
if the item is a date/time item and another item is a constant. This is done
to get a correct result of comparisons like date_time_function() = string_constant.


mysql-test/r/cast.result:
  Fixed wrong test case result after bug fix#16377.
sql/item_timefunc.h:
  Fixed bug#16377: result of DATE/TIME functions were compared as strings which
  can lead to a wrong result.
  The result_as_longlong() function is set to return TRUE for these classes:
  Item_date, Item_date_func, Item_func_curtime, Item_func_sec_to_time,
  Item_date_typecast, Item_time_typecast, Item_datetime_typecast,
  Item_func_makedate.
sql/item_timefunc.cc:
  Fixed bug#16377: result of DATE/TIME functions were compared as strings which
  can lead to a wrong result.Correct val_int() methods are implemented for classes Item_date_typecast, 
  Item_func_makedate, Item_time_typecast, Item_datetime_typecast.
sql/item_cmpfunc.h:
  Fixed bug#16377: result of DATE/TIME functions were compared as strings which
  can lead to a wrong result.
  Arg_comparator::set_compare_func() and Arg_comparator::set_cmp_func()
  functions are changed to substitute result type of an item with the INT_RESULT
  if the item is a date/time item and another item is a constant.
sql/field.cc:
  Fixed bug#16377: result of DATE/TIME functions were compared as strings which
  can lead to a wrong result.
  Field::set_warning(), Field::set_datetime_warning() now use current_thd to get thd if table isn't set.
sql/item_cmpfunc.cc:
  Fixed bug#16377: result of DATE/TIME functions were compared as strings which
  can lead to a wrong result.
  The agg_cmp_type() function now accepts THD as one of parameters. 
  In addition, it now checks if a date/time field/function is present in the
  list. If so, it tries to coerce all constants to INT to make date/time
  comparison return correct result. The field for the constant coercion is
  taken from the Item_field or constructed from the Item_func. In latter case
  the constructed field will be freed after conversion of all constant items.
  Otherwise the result is same as before - aggregated with help of the
  item_cmp_type() function.
sql/item.h:
  The new function result_as_longlong() is added to the Item class. 
  It indicates that the item is a date/time item and result of it can be
  compared as int. Such items are date/time fields/functions.
mysql-test/t/func_time.test:
  Added test case fot bug#16377: result of DATE/TIME functions were compared as strings which
  can lead to a wrong result.
mysql-test/r/func_time.result:
  Added test case fot bug#16377: result of DATE/TIME functions were compared as strings which
  can lead to a wrong result.

into moonbone.local:/home/evgen/bk-trees/mysql-4.1-opt

into moonbone.local:/work/16716-bug-4.1-opt-mysql

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

into  mysql.com:/home/kgeorge/mysql/5.0/B15355

  query
Problem:
There was a wrong context assigned to the columns that were added in insert_fields()
when expanding a '*'. When this is done in a prepared statement it causes 
fix_fields() to fail to find the table that these columns reference.
Actually the right context is set in setup_natural_join_row_types() called at the 
end of setup_tables(). However when executed in a context of a prepared statement
setup_tables() resets the context, but setup_natural_join_row_types() was not
setting it to the correct value assuming it has already done so.

Solution:
The top-most, left-most NATURAL/USING join must be set as a 
first_name_resolution_table in context even when operating on prepared statements.


mysql-test/r/join.result:
  testsuite for the bug
mysql-test/t/join.test:
  testsuite for the bug
sql/sql_base.cc:
  The context must be set even when executed as prepared statement.

The st_lex::which_check_option_applicable() function controls for which 
statements WITH CHECK OPTION clause should be taken into account. REPLACE and
REPLACE_SELECT wasn't in the list which results in allowing REPLACE to insert
wrong rows in a such view.

The st_lex::which_check_option_applicable() now includes REPLACE and 
REPLACE_SELECT in the list of statements for which WITH CHECK OPTION clause is
applicable.


mysql-test/t/replace.test:
  Added test case for bug#19789: REPLACE was allowed for a VIEW with CHECK OPTION enabled.
mysql-test/r/replace.result:
  Added test case for bug#19789: REPLACE was allowed for a VIEW with CHECK OPTION enabled.
sql/sql_lex.h:
  Fixed bug#19789: REPLACE was allowed for a VIEW with CHECK OPTION enabled.
  The st_lex::which_check_option_applicable() now includes REPLACE and 
  REPLACE_SELECT in the list of statements for which WITH CHECK OPTION clause is
  applicable.

To calculate its max_length the CONCAT() function is simply sums max_lengths
of its arguments but when the collation of an argument differs from the 
collation of the CONCAT() max_length will be wrong. This may lead to a data
truncation when a tmp table is used, in UNIONS for example.

The Item_func_concat::fix_length_and_dec() function now recalculates the 
max_length of an argument when the mbmaxlen of the argument differs from the
mbmaxlen of the CONCAT().


mysql-test/t/func_concat.test:
  Added test case for bug#15962:CONCAT() in UNION may lead to a data trucation.
mysql-test/r/func_concat.result:
  Added test case for bug#15962:CONCAT() in UNION may lead to a data trucation.
sql/item_strfunc.cc:
  Fixed bug#15962: CONCAT() in UNION may lead to a data trucation.
  The Item_func_concat::fix_length_and_dec() function now recalculates the 
  max_length of an argument when the mbmaxlen of the argument differs from the
  mbmaxlen of the CONCAT().

sql/opt_sum.cc:
  Cleanup

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


sql/opt_sum.cc:
  Auto merged
sql/sql_select.cc:
  Auto merged
sql/sql_select.h:
  Auto merged
mysql-test/r/func_group.result:
  SCCS merged
mysql-test/t/func_group.test:
  SCCS merged

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

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.

into  mysql.com:/home/kgeorge/mysql/5.0/B4981


mysql-test/t/select.test:
  Auto merged
sql/opt_range.cc:
  Auto merged
mysql-test/r/select.result:
  merged

        3.23 regression test failure

The member SEL_ARG::min_flag was not initialized, 
due to which the condition for no GEOM_FLAG in function 
key_or did not choose "Range checked for each record" as 
the correct access method.


mysql-test/r/select.result:
  testcase for 'Range checked' access method
mysql-test/t/select.test:
  testcase for 'Range checked' access method
sql/opt_range.cc:
  All of the class members initialized