Fixed bug #18360: Type aggregation for IN and CASE may lead to a wrong
result The IN function aggregates result types of all expressions. It uses that type in comparison of left expression and expressions in right part. This approach works in most cases. But let's consider the case when the right part contains both strings and integers. In that case this approach may cause wrong results because all strings which do not start with a digit are evaluated as 0. CASE uses the same approach when a CASE expression is given thus it's also affected. The idea behind this fix is to make IN function to compare expressions with different result types differently. For example a string in the left part will be compared as string with strings specified in right part and will be converted to real for comparison to int or real items in the right part. A new function called collect_cmp_types() is added. It collects different result types for comparison of first item in the provided list with each other item in the list. The Item_func_in class now can refer up to 5 cmp_item objects: 1 for each result type for comparison purposes. cmp_item objects are allocated according to found result types. The comparison of the left expression with any right part expression is now based only on result types of these expressions. The Item_func_case class is modified in the similar way when a CASE expression is specified. Now it can allocate up to 5 cmp_item objects to compare CASE expression with WHEN expressions of different types. The comparison of the CASE expression with any WHEN expression now based only on result types of these expressions.
Showing
Please register or sign in to comment