-
Neeraj Bisht authored
Problem:- We have created a table with UTF8_BIN collation. In case, when in our query we have ORDER BY clause over a function call we are getting result in incorrect order. Note:the bug is not there in 5.5. Analysis: In 5.5, for UTF8_BIN, we are using my_strnxfrm_mb_bin() to transfer the locale.But from 5.6, we started using my_strnxfrm_unicode() for which we have to define MY_CS_STRNXFRM MACRO(which is set,if strnxfrm is used for sort). In 5.6: In case of UTF32_BIN, for 4 byte multi-byte character, we are getting 3 byte sorting _field_length, through my_strnxfrmlen_unicode_full_bin(). Then we are using this length as a result pointer length to store sorting weights. Which result in incorrect sorting weight,So we should give correct length that is result pointer length. So to give the correct length in the case where MY_CS_STRNXFRM MACRO is set we are not changing the length on the basis of sort_field->length.
Neeraj Bisht authoredProblem:- We have created a table with UTF8_BIN collation. In case, when in our query we have ORDER BY clause over a function call we are getting result in incorrect order. Note:the bug is not there in 5.5. Analysis: In 5.5, for UTF8_BIN, we are using my_strnxfrm_mb_bin() to transfer the locale.But from 5.6, we started using my_strnxfrm_unicode() for which we have to define MY_CS_STRNXFRM MACRO(which is set,if strnxfrm is used for sort). In 5.6: In case of UTF32_BIN, for 4 byte multi-byte character, we are getting 3 byte sorting _field_length, through my_strnxfrmlen_unicode_full_bin(). Then we are using this length as a result pointer length to store sorting weights. Which result in incorrect sorting weight,So we should give correct length that is result pointer length. So to give the correct length in the case where MY_CS_STRNXFRM MACRO is set we are not changing the length on the basis of sort_field->length.
Loading