2002-11-21 15:56:48 +02:00
|
|
|
stop slave;
|
2002-11-16 20:19:10 +02:00
|
|
|
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;
|
2002-11-21 15:56:48 +02:00
|
|
|
start slave;
|
2002-11-16 20:19:10 +02:00
|
|
|
drop table if exists t11;
|
|
|
|
|
drop table if exists t11;
|
|
|
|
|
create table t2 (n int);
|
|
|
|
|
insert into t2 values(4);
|
|
|
|
|
create table t2 (s char(20));
|
2007-12-12 18:19:24 +01:00
|
|
|
load data infile '../../std_data/words.dat' into table t2;
|
2002-11-16 20:19:10 +02:00
|
|
|
insert into t2 values('five');
|
|
|
|
|
create table t1 (m int);
|
|
|
|
|
insert into t1 values(15),(16),(17);
|
|
|
|
|
update t1 set m=20 where m=16;
|
|
|
|
|
delete from t1 where m=17;
|
|
|
|
|
create table t11 select * from t1;
|
2006-02-07 00:18:10 +01:00
|
|
|
select * from t1 ORDER BY m;
|
2002-11-16 20:19:10 +02:00
|
|
|
m
|
|
|
|
|
15
|
|
|
|
|
20
|
|
|
|
|
select * from t2;
|
|
|
|
|
n
|
|
|
|
|
4
|
|
|
|
|
select * from t11;
|
2003-06-04 18:28:51 +03:00
|
|
|
ERROR 42S02: Table 'test.t11' doesn't exist
|
2003-01-06 01:48:59 +02:00
|
|
|
drop table if exists t1,t2,t11;
|
2007-06-11 22:15:39 +02:00
|
|
|
SHOW SLAVE STATUS;
|
|
|
|
|
Slave_IO_State #
|
|
|
|
|
Master_Host 127.0.0.1
|
|
|
|
|
Master_User root
|
|
|
|
|
Master_Port MASTER_PORT
|
|
|
|
|
Connect_Retry 1
|
|
|
|
|
Master_Log_File master-bin.000001
|
|
|
|
|
Read_Master_Log_Pos #
|
|
|
|
|
Relay_Log_File #
|
|
|
|
|
Relay_Log_Pos #
|
|
|
|
|
Relay_Master_Log_File master-bin.000001
|
|
|
|
|
Slave_IO_Running Yes
|
|
|
|
|
Slave_SQL_Running Yes
|
|
|
|
|
Replicate_Do_DB
|
|
|
|
|
Replicate_Ignore_DB
|
|
|
|
|
Replicate_Do_Table test.t1
|
|
|
|
|
Replicate_Ignore_Table
|
|
|
|
|
Replicate_Wild_Do_Table
|
|
|
|
|
Replicate_Wild_Ignore_Table
|
|
|
|
|
Last_Errno 0
|
|
|
|
|
Last_Error
|
|
|
|
|
Skip_Counter 0
|
|
|
|
|
Exec_Master_Log_Pos #
|
|
|
|
|
Relay_Log_Space #
|
|
|
|
|
Until_Condition None
|
|
|
|
|
Until_Log_File
|
|
|
|
|
Until_Log_Pos 0
|
|
|
|
|
Master_SSL_Allowed No
|
|
|
|
|
Master_SSL_CA_File
|
|
|
|
|
Master_SSL_CA_Path
|
|
|
|
|
Master_SSL_Cert
|
|
|
|
|
Master_SSL_Cipher
|
|
|
|
|
Master_SSL_Key
|
|
|
|
|
Seconds_Behind_Master #
|
|
|
|
|
Master_SSL_Verify_Server_Cert No
|
|
|
|
|
Last_IO_Errno #
|
|
|
|
|
Last_IO_Error #
|
|
|
|
|
Last_SQL_Errno 0
|
|
|
|
|
Last_SQL_Error
|
2005-08-31 18:08:45 +02:00
|
|
|
create table t1 (ts timestamp);
|
|
|
|
|
set one_shot time_zone='met';
|
|
|
|
|
insert into t1 values('2005-08-12 00:00:00');
|
|
|
|
|
set one_shot time_zone='met';
|
|
|
|
|
select * from t1;
|
|
|
|
|
ts
|
|
|
|
|
2005-08-12 00:00:00
|
|
|
|
|
set one_shot time_zone='met';
|
|
|
|
|
select * from t1;
|
|
|
|
|
ts
|
|
|
|
|
2005-08-12 00:00:00
|
2006-01-26 17:54:34 +01:00
|
|
|
drop table t1;
|
2007-02-26 15:25:43 +04:00
|
|
|
*** master ***
|
|
|
|
|
create table t1 (a int, b int);
|
|
|
|
|
create trigger trg1 before insert on t1 for each row set new.b=2;
|
|
|
|
|
create table t2 (a int, b int);
|
|
|
|
|
create trigger trg2 before insert on t2 for each row set new.b=2;
|
|
|
|
|
show tables;
|
|
|
|
|
Tables_in_test
|
|
|
|
|
t1
|
|
|
|
|
t2
|
|
|
|
|
show triggers;
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 21:34:54 +04:00
|
|
|
Trigger Event Table Statement Timing Created sql_mode Definer character_set_client collation_connection Database Collation
|
|
|
|
|
trg1 INSERT t1 set new.b=2 BEFORE NULL root@localhost latin1 latin1_swedish_ci latin1_swedish_ci
|
|
|
|
|
trg2 INSERT t2 set new.b=2 BEFORE NULL root@localhost latin1 latin1_swedish_ci latin1_swedish_ci
|
2007-02-26 15:25:43 +04:00
|
|
|
*** slave ***
|
|
|
|
|
show tables;
|
|
|
|
|
Tables_in_test
|
|
|
|
|
t1
|
|
|
|
|
show triggers;
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 21:34:54 +04:00
|
|
|
Trigger Event Table Statement Timing Created sql_mode Definer character_set_client collation_connection Database Collation
|
|
|
|
|
trg1 INSERT t1 set new.b=2 BEFORE NULL root@localhost latin1 latin1_swedish_ci latin1_swedish_ci
|
2007-02-26 15:25:43 +04:00
|
|
|
*** master ***
|
|
|
|
|
drop trigger trg1;
|
|
|
|
|
drop trigger trg2;
|
|
|
|
|
show triggers;
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 21:34:54 +04:00
|
|
|
Trigger Event Table Statement Timing Created sql_mode Definer character_set_client collation_connection Database Collation
|
2007-02-26 15:25:43 +04:00
|
|
|
*** slave ***
|
|
|
|
|
show tables;
|
|
|
|
|
Tables_in_test
|
|
|
|
|
t1
|
|
|
|
|
show triggers;
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 21:34:54 +04:00
|
|
|
Trigger Event Table Statement Timing Created sql_mode Definer character_set_client collation_connection Database Collation
|
2007-02-26 15:25:43 +04:00
|
|
|
*** master ***
|
|
|
|
|
drop table t1;
|
|
|
|
|
drop table t2;
|