Sergei Golubchik added a comment - 2021-10-09 14:06 - edited please, take a look at the commit commit e800625d80c Author: Sergei Golubchik <serg@mariadb.org> Date: Sat Oct 9 16:00:13 2021 +0200   MDEV-26646 SFORMAT Does not allow @variable use If charset aggregation decides to convert arguments to some specific charset and some arguments are numbers, they'll be wrapped into a Item_func_conv_charset(), that changes result_type() to STRING_RESULT. Fix: don't convert numbers, sformat needs their numerical value only. I'm particularly interested in alternative approaches, e.g. pass a flag MY_COLL_SKIP_NUMBERS. Or just always skip numbers everywhere unconditionally.

Alexander Barkov added a comment - 2021-10-12 08:24 - edited We cannot always skip numbers unconditionally inside all Item_func_xxx. The following examples won't work: CONCAT(ucs2arg,1) SET collation_connection=ucs2_general_ci; SELECT CONCAT(1); SELECT LEFT (123,1); I think your patch is good. Alternatively, we could try to do the following for Item_func_sformat: Don't call Type_std_attributes::agg_item_set_converter() in fix_length_and_dec(). This won't wrap arguments into Item_func_conv_charset. Instead, perform the conversion using this method for the string arguments: /* Returns the val_str() value converted to the given character set. */ String *val_str(String *str, String *converter, CHARSET_INFO *to); However, there will be a difference comparing to other functions, e.g. CONCAT(): 1. It won't return "Illegal mix of collations" for potentially lossy charset combinations during fix_fields(). It will just replace non-convertable characters to question marks during val_str() without warnings. 2. Item_func_conv_charset implements some caching functionality for constant expressions. Caching will disappear. I'm slightly inclined to your solution for now.