mirror of
https://github.com/MariaDB/server.git
synced 2025-01-19 13:32:33 +01:00
e025e47a76
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. client/mysql.cc: BUG#16217 revealed the problem of switching between charsets in mysql client. Such switching is necessary in a case when being scanned query consists of multi-byte chars and internal charset was initialized differently. mysql finds `/' escape and misiterprete it while in fact one could be a part of a multi-byte symbol like the bug page reported. This patch extends mysql `charset' command, '\C' shortcut. mysql-test/r/ctype_ucs_binlog.result: comment line generated by mysqlbinlog for processing of logs with multi-byte chars. mysql-test/r/mysql.result: results are altered due to #16217 mysql-test/r/mysqlbinlog.result: Results are altered due to #16217 mysql-test/r/mysqlbinlog2.result: commeted command for mysql client due to multi-byte binlog mysql-test/r/rpl_charset.result: commented command for mysql due to multi-byte binlogs mysql-test/r/rpl_timezone.result: commented command for mysql client due to multi-byte binlogs mysql-test/r/user_var-binlog.result: commented command for mysql client due to multi-byte binlogs mysql-test/t/mysql.test: Main test for mysql client is extended to check `charset' command. mysql-test/t/mysqlbinlog.test: Checking how /*! \C cs_name */ are added to the output of mysqlbinlog. The exclaiming comment is for further processing by mysql client. The added part mimics the failure to recover tables from binlog - see BUG#16217. sql/log_event.cc: Sending into output instructions for mysql client to switch internally to appropriate charset. mysql client is supposed to be invoked with --default-character-set= "to default character set of the server created the binlog".
105 lines
2.8 KiB
Text
105 lines
2.8 KiB
Text
stop slave;
|
|
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
|
|
reset master;
|
|
reset slave;
|
|
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
|
|
start slave;
|
|
set timestamp=100000000;
|
|
create table t1 (t timestamp, n int not null auto_increment, PRIMARY KEY(n));
|
|
create table t2 (t char(32), n int not null auto_increment, PRIMARY KEY(n));
|
|
select @@time_zone;
|
|
@@time_zone
|
|
Japan
|
|
select @@time_zone;
|
|
@@time_zone
|
|
Europe/Moscow
|
|
insert into t1 values ('20050101000000', NULL), ('20050611093902',NULL);
|
|
insert into t1 values ('20040101000000',NULL), ('20040611093902',NULL);
|
|
SELECT * FROM t1 ORDER BY n;
|
|
t n
|
|
2005-01-01 00:00:00 1
|
|
2005-06-11 09:39:02 2
|
|
2004-01-01 00:00:00 3
|
|
2004-06-11 09:39:02 4
|
|
SELECT * FROM t1 ORDER BY n;
|
|
t n
|
|
2005-01-01 06:00:00 1
|
|
2005-06-11 14:39:02 2
|
|
2004-01-01 06:00:00 3
|
|
2004-06-11 14:39:02 4
|
|
delete from t1;
|
|
set time_zone='Europe/Moscow';
|
|
insert into t1 values ('20040101000000',NULL), ('20040611093902',NULL);
|
|
SELECT * FROM t1 ORDER BY n;
|
|
t n
|
|
2004-01-01 00:00:00 5
|
|
2004-06-11 09:39:02 6
|
|
set time_zone='Europe/Moscow';
|
|
SELECT * FROM t1 ORDER BY n;
|
|
t n
|
|
2004-01-01 00:00:00 5
|
|
2004-06-11 09:39:02 6
|
|
delete from t1;
|
|
set time_zone='UTC';
|
|
load data infile '../std_data_ln/rpl_timezone2.dat' into table t1;
|
|
Warnings:
|
|
Warning 1265 Data truncated for column 't' at row 1
|
|
Warning 1261 Row 1 doesn't contain data for all columns
|
|
Warning 1265 Data truncated for column 't' at row 2
|
|
Warning 1261 Row 2 doesn't contain data for all columns
|
|
SELECT * FROM t1 ORDER BY n;
|
|
t n
|
|
0000-00-00 00:00:00 7
|
|
0000-00-00 00:00:00 8
|
|
set time_zone='UTC';
|
|
SELECT * FROM t1 ORDER BY n;
|
|
t n
|
|
0000-00-00 00:00:00 7
|
|
0000-00-00 00:00:00 8
|
|
set time_zone='Europe/Moscow';
|
|
set time_zone='Europe/Moscow';
|
|
delete from t1;
|
|
insert into t1 values ('20040101000000',NULL), ('20040611093902',NULL);
|
|
set time_zone='MET';
|
|
insert into t2 (select * from t1);
|
|
SELECT * FROM t1 ORDER BY n;
|
|
t n
|
|
2003-12-31 22:00:00 9
|
|
2004-06-11 07:39:02 10
|
|
SELECT * FROM t2 ORDER BY n;
|
|
t n
|
|
2003-12-31 22:00:00 9
|
|
2004-06-11 07:39:02 10
|
|
delete from t2;
|
|
set timestamp=1000072000;
|
|
insert into t2 values (current_timestamp,NULL), (current_date,NULL), (current_time,NULL);
|
|
SELECT * FROM t2 ORDER BY n;
|
|
t n
|
|
2001-09-09 23:46:40 11
|
|
2001-09-09 12
|
|
23:46:40 13
|
|
delete from t2;
|
|
insert into t2 values (from_unixtime(1000000000),NULL),
|
|
(unix_timestamp('2001-09-09 03:46:40'),NULL);
|
|
SELECT * FROM t2 ORDER BY n;
|
|
t n
|
|
2001-09-09 03:46:40 14
|
|
1000000000 15
|
|
SELECT * FROM t2 ORDER BY n;
|
|
t n
|
|
2001-09-09 03:46:40 14
|
|
1000000000 15
|
|
set global time_zone='MET';
|
|
delete from t2;
|
|
set time_zone='UTC';
|
|
insert into t2 values(convert_tz('2004-01-01 00:00:00','MET',@@time_zone),NULL);
|
|
insert into t2 values(convert_tz('2005-01-01 00:00:00','MET','Japan'),NULL);
|
|
SELECT * FROM t2 ORDER BY n;
|
|
t n
|
|
2003-12-31 23:00:00 16
|
|
2005-01-01 08:00:00 17
|
|
SELECT * FROM t2 ORDER BY n;
|
|
t n
|
|
2003-12-31 23:00:00 16
|
|
2005-01-01 08:00:00 17
|
|
drop table t1, t2;
|