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

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

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.

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

  After merge fix

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().

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

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

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

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

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.

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.

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.

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.

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.

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().

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

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.

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

        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.

  After merge fix