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/rpl_timezone.result b/mysql-test/r/rpl_timezone.result
index e1e6fa36be9..96a892f00fc 100644
--- a/mysql-test/r/rpl_timezone.result
+++ b/mysql-test/r/rpl_timezone.result
@@ -48,6 +48,7 @@ use test;
 SET TIMESTAMP=100000000;
 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;
 create table t1 (t timestamp);
 SET TIMESTAMP=100000000;