Bug#45263 utf32_general_ci, bad effects around CREATE TABLE AS SELECT

Problem: Item_func_hex::val_str() returned data in ASCII format,
which did not match collation.collation pointing to my_charset_utf32_general_ci.
Fix: changing parent class of Item_func_hex to Item_str_ascii_func,
as val_str() implementation is heavily ASCII-oriented.

  mysql-test/r/ctype_utf32.result
  mysql-test/t/ctype_utf32.test
  Adding test case


  sql/item_strfunc.cc
  sql/item_strfunc.h
  - Changing parent class to Item_str_ascii_func
  - Clean-up in Item_func_hex::fix_length_and_dec()
    Using fix_char_length() instead of setting max_length directly.
This commit is contained in:
Alexander Barkov 2010-08-18 16:08:59 +04:00
commit 9452dd1122
4 changed files with 24 additions and 5 deletions

View file

@ -3081,7 +3081,7 @@ String *Item_func_collation::val_str(String *str)
}
String *Item_func_hex::val_str(String *str)
String *Item_func_hex::val_str_ascii(String *str)
{
String *res;
DBUG_ASSERT(fixed == 1);
@ -3120,6 +3120,7 @@ String *Item_func_hex::val_str(String *str)
}
null_value=0;
tmp_value.length(res->length()*2);
tmp_value.set_charset(&my_charset_latin1);
octet2hex((char*) tmp_value.ptr(), res->ptr(), res->length());
return &tmp_value;