Hi Sergei, On 05/01/2013 01:27 PM, Sergei Golubchik wrote:
Hi, Alexander!
Could you report this bug and fix it, please?
The report is here: https://mariadb.atlassian.net/browse/MDEV-4489 Please review a patch fixing this problem (attached). Note, while working on the patch I noticed one suspicious thing, in the old implementation of Item_hex_string::print(). Always doing this "min" to calculate the string length to print looked strange: min(str_value.length(), sizeof(longlong)) I fixed this behaviour in the class implementing X'HHHH', it now prints the full length. But I preserved the old behaviour in the class implementing 0xHHHH. Perhaps it should also be fixed somehow. What do you think? Thanks.
On Apr 30, Alexander Barkov wrote:
Hello,
This is definitely a bug.
0xHHHH is a MySQL extension, and it's a hybrid thing. It can behave as a number and a string depending on context.
Binary log could use the X'HHHH' notation instead:
INSERT INTO t1 VALUES (a) VALUES (X'31');
which is an SQL standard, and which must always be a string.
However, it seems the behaviour of X'HHHH' and of 0xHHHH is exactly the same, and X'HHHH' can also act as a number. ... I'd propose the following as a quick fix: 1. Fix X'HHHH' to work always as string. 2. Fix binlog to use X'HHHH'
Regards, Sergei