The IN() function uses agg_cmp_type() to aggregate all types of its arguments
to find out some common type for comparisons. In this particular case the
char() and the int was aggregated to double because char() can contain values
like '1.5'. But all strings which do not start from a digit are converted to
0. thus 'a' and 'z' become equal.
This behaviour is reasonable when all function arguments are constants. But
when there is a field or an expression this can lead to false comparisons. In
this case it makes more sense to coerce constants to the type of the field
argument.
The agg_cmp_type() function now aggregates types of constant and non-constant
items separately. If some non-constant items will be found then their
aggregated type will be returned. Thus after the aggregation constants will be
coerced to the aggregated type.
Bug#7834 Illegal mix of collations in IN operator
IN was the first function supporting
character set convertion.
agg_arg_charsets() was written afterwards,
which is more flexible.
Now IN just reuses this function.
Added a case for bug #6365.
item_cmpfunc.cc:
Fixed bug #6365 : Server crashed when list of values
in IN predicate contains NULL while the tested field is
of the character type and not of the default set;
e.g. when f in 'f IN (NULL,'aa') belongs to binary
character set, while the default character set is latin1.
Added more DBUG statements
Ensure that we are comparing end space with BINARY strings
Use 'any_db' instead of '' to mean any database. (For HANDLER command)
Only strip ' ' when comparing CHAR, not other space-like characters (like \t)
