diff options
| author | aelkin@mysql.com <> | 2006-02-09 16:23:09 +0200 |
|---|---|---|
| committer | aelkin@mysql.com <> | 2006-02-09 16:23:09 +0200 |
| commit | dd2a44c497b5fe24a4f2744d5f2b6fafd1cebbfd (patch) | |
| tree | 62a885bef438849f6bce8103b589c4944703fe7e /sql/log_event.cc | |
| parent | 3b0dcb08a4130052857ed9dceb47307c57be7733 (diff) | |
| download | mariadb-git-dd2a44c497b5fe24a4f2744d5f2b6fafd1cebbfd.tar.gz | |
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.
Diffstat (limited to 'sql/log_event.cc')
| -rw-r--r-- | sql/log_event.cc | 5 |
1 files changed, 5 insertions, 0 deletions
diff --git a/sql/log_event.cc b/sql/log_event.cc index a07411971ce..5ca7c00ee8f 100644 --- a/sql/log_event.cc +++ b/sql/log_event.cc @@ -1551,6 +1551,11 @@ void Query_log_event::print_query_header(FILE* file, } if (unlikely(bcmp(print_event_info->charset, charset, 6))) { + CHARSET_INFO *cs_info= get_charset(uint2korr(charset), MYF(MY_WME)); + if (cs_info) + { + fprintf(file, "/*!\\C %s */;\n", cs_info->csname); /* for mysql client */ + } fprintf(file,"SET " "@@session.character_set_client=%d," "@@session.collation_connection=%d," |