into  magare.gmz:/home/kgeorge/mysql/work/B28476-5.1-opt

Zero merge all except the new test

When processing the USE/FORCE index hints
the optimizer was not checking if the indexes 
specified are enabled (see ALTER TABLE).
Fixed by:
 Backporting the fix for bug 20604 to 5.0

into  dl145s.mysql.com:/users/mhansson/mysql/push/bug23856/mysql-5.1o-pushee

into  mysql.com:/home/hf/work/27984/my51-27984

into  mysql.com:/home/hf/work/27984/my51-27984

into  mysql.com:/home/hf/work/27984/my50-27984

into  mysql.com:/home/hf/work/27984/my50-27984

into  mysql.com:/home/hf/work/27984/my51-27984

into  mysql.com:/home/hf/work/27984/my51-27984

decimal_round failed to perform a correct rounding 
of a decimal number if its first nine digits were '9'.
It just sets those digits to 0.

into  mysql.com:/home/hf/work/28361/my50-28361

into  mysql.com:/home/hf/work/28361/my51-28361

into  dl145s.mysql.com:/users/mhansson/mysql/push/bug23856/my51-bug23856

into  mysql.com:/home/hf/work/27894/my50-27894

into  mysql.com:/home/hf/work/27894/my51-27894

into  mysql.com:/home/hf/work/27894/my51-27894

result max length changed for the 'decimal' fields
so test results have to be fixed

into  magare.gmz:/home/kgeorge/mysql/work/B22855-5.1-opt

into  magare.gmz:/home/kgeorge/mysql/work/B22855-5.0-opt

into  mysql.com:/home/hf/work/28361/my51-28361

my_decimal in some cases can contain more decimal digits than
is officially supported (DECIMAL_MAX_PRECISION), so we need to
prepare bigger buffer for the resulting string.

into  mysql.com:/d2/hf/mrg/mysql-5.1-opt

into  mysql.com:/d2/hf/mrg/mysql-5.0-opt

into  sergbook.mysql.com:/usr/home/serg/Abk/mysql-5.0

into  mysql.com:/d2/hf/mrg/mysql-5.1-opt

into  mysql.com:/d2/hf/mrg/mysql-5.1-opt

into  mysql.com:/d2/hf/mrg/mysql-5.0-opt

into  mysql.com:/d2/hf/mrg/mysql-5.0-opt

into  mysql.com:/d2/hf/mrg/mysql-4.1-opt

into  mysql.com:/d2/hf/mrg/mysql-5.1-opt

into  moonbone.local:/mnt/gentoo64/work/28261-bug-5.0-opt-mysql

into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug28337

is involved.

The Arg_comparator::compare_datetime() comparator caches its arguments if
they are constants i.e. const_item() returns true. The
Item_func_get_user_var::const_item() returns true or false based on
the current query_id and the query_id where the variable was created.
Thus even if a query can change its value its const_item() still will return
true. All this leads to a wrong comparison result when an object of the
Item_func_get_user_var class is involved.

Now the Arg_comparator::can_compare_as_dates() and the
get_datetime_value() functions never cache result of the GET_USER_VAR()
function (the Item_func_get_user_var class).

Conversion errors when constructing the condition for an
IN predicates were treated as if the affected column contains
NULL. If such a IN predicate is inside NOT we get wrong 
results.
Corrected the handling of conversion errors in an IN predicate 
that is resolved by unique_subquery (through 
subselect_uniquesubquery_engine).

into  mysql.com:/home/gluh/MySQL/Merge/5.1-opt