The crash happened when ExtractValue() returning an empty string
as a result was passed to LCASE() or UCASE().
Item_func_xml_extractvalue::val_str() could return a String
{Ptr=0,str_value=0} in some cases, to mean an empty retult.
But virtual my_charset_handler_st functions caseup() and casedn()
do not expect {src=nullptr,srclen=0} as input and:
- raise a DBUG_ASSERT() in debug builds, or
- raise a "applying zero offset to null pointer" warning in UBSAN builds
Fixing Item_func_xml_extractvalue::val_str() to return
a String {Ptr="",str_length=0} instead of {Ptr=0,str_value=0}.
A similar fix was done earlier in Field_set::val_str(). See c69fb1a627.
Field_string::val_int(), Field_string::val_real(), Field_string::val_decimal()
passed the whole buffer of field_length bytes to data type conversion routines.
This made conversion routines to print redundant trailing spaces in case of warnings.
Adding a method Field_string::to_lex_cstring() and using it inside
val_int(), val_real(), val_decimal(), val_str().
After this change conversion routines get the same value with what val_str() returns,
and no redundant trailing spaces are displayed.
The patch for `MDEV-20795 CAST(inet6 AS BINARY) returns wrong result`
unintentionally changed what Item_char_typecast::type_handler()
returns. This broke UNIONs with the BINARY() function, as the Aria
engine started to get columns of unexpected data types.
Restoring previous behaviour, to return
Type_handler::string_type_handler(max_length).
The prototype for Item_handed_func::return_type_handler() has changed
from:
const Type_handler *return_type_handler() const
to:
const Type_handler *return_type_handler(const Item_handled_func *) const
