1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
|
-- source include/not_embedded.inc
-- source include/have_cp932.inc
--character_set cp932
--disable_warnings
drop table if exists t1;
--enable_warnings
set names cp932;
set character_set_database = cp932;
# Test prepared statement with 0x8300 sequence in parameter while
# running with cp932 client character set.
RESET MASTER;
CREATE TABLE t1(f1 blob);
PREPARE stmt1 FROM 'INSERT INTO t1 VALUES(?)';
SET @var1= x'8300';
# TODO: Note that this doesn't actually test the code which was added for
# bug#11338 because this syntax for prepared statements causes the PS to
# be replicated differently than if we executed the PS from C or Java.
# Using this syntax, variable names are inserted into the binlog instead
# of values. The real goal of this test is to check the code that was
# added to Item_param::query_val_str() in order to do hex encoding of
# PS parameters when the client character set is cp932;
# Bug#11338 has an example java program which can be used to verify this
# code (and I have used it to test the fix) until there is some way to
# exercise this code from mysql-test-run.
EXECUTE stmt1 USING @var1;
SHOW BINLOG EVENTS FROM 98;
SELECT HEX(f1) FROM t1;
DROP table t1;
# end test for bug#11338
# End of 4.1 tests
#
# Bug#18293: Values in stored procedure written to binlog unescaped
#
delimiter |;
CREATE TABLE t4 (s1 CHAR(50) CHARACTER SET latin1,
s2 CHAR(50) CHARACTER SET cp932,
d DECIMAL(10,2))|
CREATE PROCEDURE bug18293 (IN ins1 CHAR(50),
IN ins2 CHAR(50) CHARACTER SET cp932,
IN ind DECIMAL(10,2))
BEGIN
INSERT INTO t4 VALUES (ins1, ins2, ind);
END|
CALL bug18293("Foo's a Bar", _cp932 0xED40ED41ED42, 47.93)|
SELECT HEX(s1),HEX(s2),d FROM t4|
DROP PROCEDURE bug18293|
DROP TABLE t4|
SHOW BINLOG EVENTS FROM 393|
delimiter ;|
# End of 5.0 tests
|
