The bug

MDEV-4489 "Replication of big5, cp932, gbk, sjis strings makes wrong values on slave"
has been fixed.

Problem:
String constants of some Asian charsets (big5,cp932,gbk,sjis)
can have backslash '\' (0x5C) in the second byte of multi-byte characters.
Replicating of such constants using the standard '\'-escaping is dangerous.
Therefore, constants of these charsets are replicated using hex notation:
INSERT INTO t1 (a) VALUES (0x815C);

However, 0xHHHH constants do not work well in some cases,
because they can behave as strings and as numbers, depending on context
(for example, depending on the data type of the column in an INSERT statement).

This SQL script was not replicated correctly with statement-based replication:

SET NAMES gbk;
PREPARE STMT FROM 'INSERT INTO t1 (a) VALUES (?)';
SET @a = '1';
EXECUTE STMT USING @a;

The INSERT statement was replicated as:
INSERT INTO t1 (a) VALUES (0x31);

'1' was correctly converted to the number 1 on master.
But the 0x31 constant was treated as number 49 on slave.

Fix:

1. Binary log now uses X'HHHH' instead of 0xHHHH constants.
2. The X'HHHH' constants now work always as strings, in all contexts.
This is the SQL standard compliant behaviour.

After the fix, the above statement is replicated as:
INSERT INTO t1 (a) VALUES (X'31');
X'31' is treated as string '1' on slave, and is correctly converted to 1.


modified:
  @ mysql-test/r/ctype_cp932_binlog_stm.result
  @ mysql-test/r/select.result
  @ mysql-test/r/select_jcl6.result
  @ mysql-test/r/select_pkeycache.result
  @ mysql-test/r/user_var-binlog.result
  @ mysql-test/r/varbinary.result
  @ mysql-test/suite/binlog/r/binlog_stm_ctype_ucs.result
  @ mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result
  @ mysql-test/suite/rpl/r/rpl_charset_sjis.result
  @ mysql-test/suite/rpl/r/rpl_mdev382.result
  @ mysql-test/suite/rpl/t/rpl_charset_sjis.test
  @ mysql-test/t/ctype_cp932_binlog_stm.test
  @ mysql-test/t/select.test
  @ mysql-test/t/varbinary.test
    Adding and updating tests

  @ sql/item.cc
  @ sql/item.h
  @ sql/sql_yacc.yy
  @ sql/sql_lex.cc
    Splitting the implementations of X'HH' and 0xHH constants into two
    separate classes. Fixing the parser to distinguish the two syntaxes.

  @ sql/log_event.cc
    Using X'HH' instead of 0xHH for binary logging for string constants
    of the "dangerous" charsets.

  @ sql/sql_string.h
    Adding a helped method String::append_hex().

1 files changed, 2 insertions, 2 deletions

diff --git a/mysql-test/r/select_jcl6.result b/mysql-test/r/select_jcl6.result
index 8fa4f27b4b8..00b356fc1c0 100644
--- a/mysql-test/r/select_jcl6.result
+++ b/mysql-test/r/select_jcl6.result
@@ -2932,8 +2932,8 @@ id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
 1	SIMPLE	t2	ALL	NULL	NULL	NULL	NULL	3	Using where
 1	SIMPLE	t1	hash_ALL	NULL	#hash#$hj	5	test.t2.a	5	Using where; Using join buffer (flat, BNLH join)
 DROP TABLE t1,t2;
-select x'10' + 0, X'10' + 0, b'10' + 0, B'10' + 0;
-x'10' + 0	X'10' + 0	b'10' + 0	B'10' + 0
+select x'3136' + 0, X'3136' + 0, b'10' + 0, B'10' + 0;
+x'3136' + 0	X'3136' + 0	b'10' + 0	B'10' + 0
 16	16	2	2
 create table t1 (f1 varchar(6) default NULL, f2 int(6) primary key not null);
 create table t2 (f3 varchar(5) not null, f4 varchar(5) not null, UNIQUE KEY UKEY (f3,f4));