You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bug#37285902: Illegal mix of collations NONE vs. COERCIBLE
The problem is that an unexpected error message is reported from a
SELECT statement that involves multiple functions and columns and
strings with multiple collations. For details, see the analysis in
the bug report.
In essence, an IFNULL function returns a binary collation and collation
derivation NONE. The result of IFNULL is used in a LIKE clause.
Derivation NONE is disallowed in this context, thus an error is
reported.
This is behaviour according to documentation.
However, we can change the semantics slightly and thus accept the
problematic query.
The change is to lower the strength of collation derivation NONE to be
less than the strength of any other collation derivation. This means
that when an expression with derivation NONE is used e.g. in a LIKE
expression, then the other operand will determine the comparison
collation to be used by LIKE. The change can be used with minimal impact
on existing functionality, in fact it causes no changes in existing
test suite.
In addition, we simplify the collation determination slightly and
provide more comprehensive documentation.
We also change collation aggregation as implemented in
agg_item_collations() to only consider collations with the same (and
highest) strength when determining the result collation. This might
seem dangerous since it means that operands with possibly incompatible
character sets but lesser strength are now allowed. However we have
already implemented code that converts operands with different
character sets into the character set determined for the operation,
and report errors if strings are actually invalid, thus pushing some
error rejection from the resolver stage into the execution stage.
We also rename the previous IGNORABLE derivation to NULL, since it is
only used for NULL values, and since it is no longer ignorable given
that NONE now has lesser strength.
We leave a hole in the "strength" values for the former NONE strength,
in order that as few COERCIBILITY() calls as possible return values
that are incompatible with the previous implementation.
A special problem was hit with resolving of aggregated types for the
result columns of set operations. The new way of determining character
set and collation works fine when all aggregated items are processed
in one operation, but an anomaly was discovered for set operations,
since type aggregation is handled for pairs of items. We have therefore
implemented a new function Item_aggregate_type::unify_types() that
unifies the types from a set of items.
Query_term_set_op::prepare_query_term() has been refactored so that it
may call the new unify_types() function. It has also been changed so
that the type holder objects are created and finalized in one place,
which is just after all query term children have been resolved in a
non-recursive set operation, and just before resolving the first
recursive query term in a recursive set operation.
The actual preparation of type holder objects is performed in a new
function Query_term_set_op::prepare_type_holders().
Finally, an earlier mistake was discovered and corrected. The call to
report_conversion_error() inside Item::convert_charset() had
collation arguments reversed. Fixing this caused a few minor changes
in result test files.
Change-Id: Ie30906758078559fcba8ae881125e039bab9298a
Warning 3778 'utf8mb3_general_ci' is a collation of the deprecated character set UTF8MB3. Please consider using UTF8MB4 with an appropriate collation instead.
0 commit comments