BUG#16217 forced to introduce a separate mysql client command to adopt its

internal charset to one associated with currently being handled query. 
To note such a query can come from interactive client either.

There was a discussion within replication team and Monty who's suggestion won.
It avoids straightforward parsing of all `set' queries that could affect client side 
character set. 
According to the idea, mysql client does not parse `set' queries but rather cares of
`charset new_cs_name' command.
This command is generated by mysqlbinlog in form of exclaiming comment (Lars' suggestion)
so that enlightened clients like `mysql' knows what to do with it.

Interactive human can switch between many multi-byte charsets during the session 
providing the command explicitly. 
To note that setting new internal mysql's charset does not
trigger sending any `SET' sql statement to the server. 

1 files changed, 1 insertions, 0 deletions

diff --git a/mysql-test/r/user_var-binlog.result b/mysql-test/r/user_var-binlog.result
index 700ec7b09e0..d1555bb793f 100644
--- a/mysql-test/r/user_var-binlog.result
+++ b/mysql-test/r/user_var-binlog.result
@@ -21,6 +21,7 @@ use test;
 SET TIMESTAMP=10000;
 SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=1, @@session.unique_checks=1;
 SET @@session.sql_mode=0;
+/*!\C latin1 */;
 SET @@session.character_set_client=8,@@session.collation_connection=8,@@session.collation_server=8;
 INSERT INTO t1 VALUES(@`a b`);
 SET @`var1`:=_latin1 0x273B616161 COLLATE `latin1_swedish_ci`;