mariadb/mysql-test/r/rpl_timezone.result
unknown e025e47a76 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. 


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".
2006-02-09 16:23:09 +02:00

128 lines
3.2 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);
create table t2 (t char(32));
select @@time_zone;
@@time_zone
Japan
select @@time_zone;
@@time_zone
Europe/Moscow
insert into t1 values ('20050101000000'), ('20050611093902');
set time_zone='UTC';
insert into t1 values ('20040101000000'), ('20040611093902');
select * from t1;
t
2004-12-31 21:00:00
2005-06-11 05:39:02
2004-01-01 00:00:00
2004-06-11 09:39:02
set time_zone='UTC';
select * from t1;
t
2004-12-31 21:00:00
2005-06-11 05:39:02
2004-01-01 00:00:00
2004-06-11 09:39:02
delete from t1;
set time_zone='Europe/Moscow';
insert into t1 values ('20040101000000'), ('20040611093902');
select * from t1;
t
2004-01-01 00:00:00
2004-06-11 09:39:02
set time_zone='Europe/Moscow';
select * from t1;
t
2004-01-01 00:00:00
2004-06-11 09:39:02
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
ROLLBACK;
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;
create table t2 (t char(32));
SET TIMESTAMP=100000000;
SET @@session.time_zone='Europe/Moscow';
insert into t1 values ('20050101000000'), ('20050611093902');
SET TIMESTAMP=100000000;
SET @@session.time_zone='UTC';
insert into t1 values ('20040101000000'), ('20040611093902');
SET TIMESTAMP=100000000;
delete from t1;
SET TIMESTAMP=100000000;
SET @@session.time_zone='Europe/Moscow';
insert into t1 values ('20040101000000'), ('20040611093902');
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
delete from t1;
set time_zone='UTC';
load data infile '../std_data_ln/rpl_timezone.dat' into table t1;
select * from t1;
t
2004-01-01 00:00:00
2004-06-11 09:39:02
set time_zone='UTC';
select * from t1;
t
2004-01-01 00:00:00
2004-06-11 09:39:02
set time_zone='Europe/Moscow';
set time_zone='Europe/Moscow';
delete from t1;
insert into t1 values ('20040101000000'), ('20040611093902');
set time_zone='MET';
insert into t2 (select t from t1);
select * from t1;
t
2003-12-31 22:00:00
2004-06-11 07:39:02
select * from t2;
t
2003-12-31 22:00:00
2004-06-11 07:39:02
delete from t2;
set timestamp=1000072000;
insert into t2 values (current_timestamp), (current_date), (current_time);
select * from t2;
t
2001-09-09 23:46:40
2001-09-09
23:46:40
delete from t2;
insert into t2 values (from_unixtime(1000000000)),
(unix_timestamp('2001-09-09 03:46:40'));
select * from t2;
t
2001-09-09 03:46:40
1000000000
select * from t2;
t
2001-09-09 03:46:40
1000000000
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));
insert into t2 values(convert_tz('2005-01-01 00:00:00','MET','Japan'));
select * from t2;
t
2003-12-31 23:00:00
2005-01-01 08:00:00
select * from t2;
t
2003-12-31 23:00:00
2005-01-01 08:00:00
drop table t1, t2;