Fix for bug #14183 (ctype_cp983.test fails with the embedded server)

mysql-test/r/ctype_cp932.result:
  result fixed
mysql-test/t/ctype_cp932.test:
  these lines don't work in embedded-server

4 files changed, 54 insertions, 39 deletions

diff --git a/mysql-test/r/ctype_cp932.result b/mysql-test/r/ctype_cp932.result
index 8763055647c..b384eaa144d 100644
--- a/mysql-test/r/ctype_cp932.result
+++ b/mysql-test/r/ctype_cp932.result
@@ -8576,22 +8576,6 @@ FC4B
 DROP TABLE t1;
 DROP TABLE t2;
 DROP TABLE t3;
-RESET MASTER;
-CREATE TABLE t1(f1 blob);
-PREPARE stmt1 FROM 'INSERT INTO t1 VALUES(?)';
-SET @var1= x'8300';
-EXECUTE stmt1 USING @var1;
-SHOW BINLOG EVENTS FROM 79;
-Log_name	Pos	Event_type	Server_id	Orig_log_pos	Info
-master-bin.000001	#	Query	1	#	use `test`; SET ONE_SHOT CHARACTER_SET_CLIENT=95,COLLATION_CONNECTION=95,COLLATION_DATABASE=95,COLLATION_SERVER=8
-master-bin.000001	#	Query	1	#	use `test`; CREATE TABLE t1(f1 blob)
-master-bin.000001	#	Query	1	#	use `test`; SET ONE_SHOT CHARACTER_SET_CLIENT=95,COLLATION_CONNECTION=95,COLLATION_DATABASE=95,COLLATION_SERVER=8
-master-bin.000001	#	User var	1	#	@`var1`=_binary 0x8300 COLLATE binary
-master-bin.000001	#	Query	1	#	use `test`; INSERT INTO t1 VALUES(@'var1')
-SELECT HEX(f1) FROM t1;
-HEX(f1)
-8300
-DROP table t1;
 SET collation_connection='cp932_japanese_ci';
 create table t1 select repeat('a',4000) a;
 delete from t1;
diff --git a/mysql-test/r/ctype_cp932_binlog.result b/mysql-test/r/ctype_cp932_binlog.result
new file mode 100644
index 00000000000..89f0ae71f4f
--- /dev/null
+++ b/mysql-test/r/ctype_cp932_binlog.result
@@ -0,0 +1,19 @@
+drop table if exists t1;
+set names cp932;
+set character_set_database = cp932;
+RESET MASTER;
+CREATE TABLE t1(f1 blob);
+PREPARE stmt1 FROM 'INSERT INTO t1 VALUES(?)';
+SET @var1= x'8300';
+EXECUTE stmt1 USING @var1;
+SHOW BINLOG EVENTS FROM 79;
+Log_name	Pos	Event_type	Server_id	Orig_log_pos	Info
+master-bin.000001	#	Query	1	#	use `test`; SET ONE_SHOT CHARACTER_SET_CLIENT=95,COLLATION_CONNECTION=95,COLLATION_DATABASE=95,COLLATION_SERVER=8
+master-bin.000001	#	Query	1	#	use `test`; CREATE TABLE t1(f1 blob)
+master-bin.000001	#	Query	1	#	use `test`; SET ONE_SHOT CHARACTER_SET_CLIENT=95,COLLATION_CONNECTION=95,COLLATION_DATABASE=95,COLLATION_SERVER=8
+master-bin.000001	#	User var	1	#	@`var1`=_binary 0x8300 COLLATE binary
+master-bin.000001	#	Query	1	#	use `test`; INSERT INTO t1 VALUES(@'var1')
+SELECT HEX(f1) FROM t1;
+HEX(f1)
+8300
+DROP table t1;
diff --git a/mysql-test/t/ctype_cp932.test b/mysql-test/t/ctype_cp932.test
index d6c3c226140..3ea8be211df 100644
--- a/mysql-test/t/ctype_cp932.test
+++ b/mysql-test/t/ctype_cp932.test
@@ -401,29 +401,6 @@ DROP TABLE t2;
 DROP TABLE t3;
 #DROP TABLE t4;
 
-# 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;
---replace_column 2 # 5 #
-SHOW BINLOG EVENTS FROM 79;
-SELECT HEX(f1) FROM t1;
-DROP table t1;
-# end test for bug#11338
-
 SET collation_connection='cp932_japanese_ci';
 -- source include/ctype_filesort.inc
 -- source include/ctype_innodb_like.inc
diff --git a/mysql-test/t/ctype_cp932_binlog.test b/mysql-test/t/ctype_cp932_binlog.test
new file mode 100644
index 00000000000..e8ec0d46caf
--- /dev/null
+++ b/mysql-test/t/ctype_cp932_binlog.test
@@ -0,0 +1,35 @@
+-- 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;
+--replace_column 2 # 5 #
+SHOW BINLOG EVENTS FROM 79;
+SELECT HEX(f1) FROM t1;
+DROP table t1;
+# end test for bug#11338
+
+# End of 4.1 tests