 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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago  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;
19 years ago |
|
DROP TABLE IF EXISTS t0,t1,t2,t3,t4,t5;DROP VIEW IF EXISTS v1;show variables where variable_name like "skip_show_database";Variable_name Valueskip_show_database OFFgrant select, update, execute on test.* to mysqltest_2@localhost;grant select, update on test.* to mysqltest_1@localhost;create user mysqltest_3@localhost;create user mysqltest_3;select * from information_schema.SCHEMATA where schema_name > 'm';CATALOG_NAME SCHEMA_NAME DEFAULT_CHARACTER_SET_NAME DEFAULT_COLLATION_NAME SQL_PATHNULL mysql latin1 latin1_swedish_ci NULLNULL test latin1 latin1_swedish_ci NULLselect schema_name from information_schema.schemata;schema_nameinformation_schemamysqltestshow databases like 't%';Database (t%)testshow databases;Databaseinformation_schemamysqltestshow databases where `database` = 't%';Databasecreate database mysqltest;create table mysqltest.t1(a int, b VARCHAR(30), KEY string_data (b));create table test.t2(a int);create table t3(a int, KEY a_data (a));create table mysqltest.t4(a int);create table t5 (id int auto_increment primary key);insert into t5 values (10);create view v1 (c) as select table_name from information_schema.TABLES where table_name<>'ndb_binlog_index' AND table_name<>'ndb_apply_status';select * from v1;cCHARACTER_SETSCOLLATIONSCOLLATION_CHARACTER_SET_APPLICABILITYCOLUMNSCOLUMN_PRIVILEGESENGINESEVENTSFILESGLOBAL_STATUSGLOBAL_VARIABLESKEY_COLUMN_USAGEPARTITIONSPLUGINSPROCESSLISTPROFILINGREFERENTIAL_CONSTRAINTSROUTINESSCHEMATASCHEMA_PRIVILEGESSESSION_STATUSSESSION_VARIABLESSTATISTICSTABLESTABLE_CONSTRAINTSTABLE_PRIVILEGESTRIGGERSUSER_PRIVILEGESVIEWScolumns_privdbeventfuncgeneral_loghelp_categoryhelp_keywordhelp_relationhelp_topichostpluginprocprocs_privserversslow_logtables_privtime_zonetime_zone_leap_secondtime_zone_nametime_zone_transitiontime_zone_transition_typeusert1t4t2t3t5v1select c,table_name from v1 inner join information_schema.TABLES v2 on (v1.c=v2.table_name)where v1.c like "t%";c table_nameTABLES TABLESTABLE_CONSTRAINTS TABLE_CONSTRAINTSTABLE_PRIVILEGES TABLE_PRIVILEGESTRIGGERS TRIGGERStables_priv tables_privtime_zone time_zonetime_zone_leap_second time_zone_leap_secondtime_zone_name time_zone_nametime_zone_transition time_zone_transitiontime_zone_transition_type time_zone_transition_typet1 t1t4 t4t2 t2t3 t3t5 t5select c,table_name from v1 left join information_schema.TABLES v2 on (v1.c=v2.table_name)where v1.c like "t%";c table_nameTABLES TABLESTABLE_CONSTRAINTS TABLE_CONSTRAINTSTABLE_PRIVILEGES TABLE_PRIVILEGESTRIGGERS TRIGGERStables_priv tables_privtime_zone time_zonetime_zone_leap_second time_zone_leap_secondtime_zone_name time_zone_nametime_zone_transition time_zone_transitiontime_zone_transition_type time_zone_transition_typet1 t1t4 t4t2 t2t3 t3t5 t5select c, v2.table_name from v1right join information_schema.TABLES v2 on (v1.c=v2.table_name)where v1.c like "t%";c table_nameTABLES TABLESTABLE_CONSTRAINTS TABLE_CONSTRAINTSTABLE_PRIVILEGES TABLE_PRIVILEGESTRIGGERS TRIGGERStables_priv tables_privtime_zone time_zonetime_zone_leap_second time_zone_leap_secondtime_zone_name time_zone_nametime_zone_transition time_zone_transitiontime_zone_transition_type time_zone_transition_typet1 t1t4 t4t2 t2t3 t3t5 t5select table_name from information_schema.TABLESwhere table_schema = "mysqltest" and table_name like "t%";table_namet1t4select * from information_schema.STATISTICS where TABLE_SCHEMA = "mysqltest";TABLE_CATALOG TABLE_SCHEMA TABLE_NAME NON_UNIQUE INDEX_SCHEMA INDEX_NAME SEQ_IN_INDEX COLUMN_NAME COLLATION CARDINALITY SUB_PART PACKED NULLABLE INDEX_TYPE COMMENTNULL mysqltest t1 1 mysqltest string_data 1 b A NULL NULL NULL YES BTREE show keys from t3 where Key_name = "a_data";Table Non_unique Key_name Seq_in_index Column_name Collation Cardinality Sub_part Packed Null Index_type Commentt3 1 a_data 1 a A NULL NULL NULL YES BTREE show tables like 't%';Tables_in_test (t%)t2t3t5show table status;Name Engine Version Row_format Rows Avg_row_length Data_length Max_data_length Index_length Data_free Auto_increment Create_time Update_time Check_time Collation Checksum Create_options Commentt2 MyISAM 10 Fixed 0 0 0 # 1024 0 NULL # # NULL latin1_swedish_ci NULL t3 MyISAM 10 Fixed 0 0 0 # 1024 0 NULL # # NULL latin1_swedish_ci NULL t5 MyISAM 10 Fixed 1 7 7 # 2048 0 11 # # NULL latin1_swedish_ci NULL v1 NULL NULL NULL NULL NULL NULL # NULL NULL NULL # # NULL NULL NULL NULL VIEWshow full columns from t3 like "a%";Field Type Collation Null Key Default Extra Privileges Commenta int(11) NULL YES MUL NULL select,insert,update,references show full columns from mysql.db like "Insert%";Field Type Collation Null Key Default Extra Privileges CommentInsert_priv enum('N','Y') utf8_general_ci NO N select,insert,update,references show full columns from v1;Field Type Collation Null Key Default Extra Privileges Commentc varchar(64) utf8_general_ci NO select,insert,update,references select * from information_schema.COLUMNS where table_name="t1"and column_name= "a";TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME ORDINAL_POSITION COLUMN_DEFAULT IS_NULLABLE DATA_TYPE CHARACTER_MAXIMUM_LENGTH CHARACTER_OCTET_LENGTH NUMERIC_PRECISION NUMERIC_SCALE CHARACTER_SET_NAME COLLATION_NAME COLUMN_TYPE COLUMN_KEY EXTRA PRIVILEGES COLUMN_COMMENTNULL mysqltest t1 a 1 NULL YES int NULL NULL 10 0 NULL NULL int(11) select,insert,update,references show columns from mysqltest.t1 where field like "%a%";Field Type Null Key Default Extraa int(11) YES NULL create view mysqltest.v1 (c) as select a from mysqltest.t1;grant select (a) on mysqltest.t1 to mysqltest_2@localhost;grant select on mysqltest.v1 to mysqltest_3;select table_name, column_name, privileges from information_schema.columns where table_schema = 'mysqltest' and table_name = 't1';table_name column_name privilegest1 a selectshow columns from mysqltest.t1;Field Type Null Key Default Extraa int(11) YES NULL select table_name, column_name, privileges from information_schema.columnswhere table_schema = 'mysqltest' and table_name = 'v1';table_name column_name privilegesv1 c selectexplain select * from v1;ERROR HY000: EXPLAIN/SHOW can not be issued; lacking privileges for underlying tabledrop view v1, mysqltest.v1;drop tables mysqltest.t4, mysqltest.t1, t2, t3, t5;drop database mysqltest;select * from information_schema.CHARACTER_SETSwhere CHARACTER_SET_NAME like 'latin1%';CHARACTER_SET_NAME DEFAULT_COLLATE_NAME DESCRIPTION MAXLENlatin1 latin1_swedish_ci cp1252 West European 1SHOW CHARACTER SET LIKE 'latin1%';Charset Description Default collation Maxlenlatin1 cp1252 West European latin1_swedish_ci 1SHOW CHARACTER SET WHERE charset like 'latin1%';Charset Description Default collation Maxlenlatin1 cp1252 West European latin1_swedish_ci 1select * from information_schema.COLLATIONSwhere COLLATION_NAME like 'latin1%';COLLATION_NAME CHARACTER_SET_NAME ID IS_DEFAULT IS_COMPILED SORTLENlatin1_german1_ci latin1 5 # 1latin1_swedish_ci latin1 8 Yes # 1latin1_danish_ci latin1 15 # 1latin1_german2_ci latin1 31 # 2latin1_bin latin1 47 # 1latin1_general_ci latin1 48 # 1latin1_general_cs latin1 49 # 1latin1_spanish_ci latin1 94 # 1SHOW COLLATION LIKE 'latin1%';Collation Charset Id Default Compiled Sortlenlatin1_german1_ci latin1 5 # 1latin1_swedish_ci latin1 8 Yes # 1latin1_danish_ci latin1 15 # 1latin1_german2_ci latin1 31 # 2latin1_bin latin1 47 # 1latin1_general_ci latin1 48 # 1latin1_general_cs latin1 49 # 1latin1_spanish_ci latin1 94 # 1SHOW COLLATION WHERE collation like 'latin1%';Collation Charset Id Default Compiled Sortlenlatin1_german1_ci latin1 5 # 1latin1_swedish_ci latin1 8 Yes # 1latin1_danish_ci latin1 15 # 1latin1_german2_ci latin1 31 # 2latin1_bin latin1 47 # 1latin1_general_ci latin1 48 # 1latin1_general_cs latin1 49 # 1latin1_spanish_ci latin1 94 # 1select * from information_schema.COLLATION_CHARACTER_SET_APPLICABILITYwhere COLLATION_NAME like 'latin1%';COLLATION_NAME CHARACTER_SET_NAMElatin1_german1_ci latin1latin1_swedish_ci latin1latin1_danish_ci latin1latin1_german2_ci latin1latin1_bin latin1latin1_general_ci latin1latin1_general_cs latin1latin1_spanish_ci latin1drop procedure if exists sel2;drop function if exists sub1;drop function if exists sub2;create function sub1(i int) returns intreturn i+1;create procedure sel2()beginselect * from t1;select * from t2;end|select parameter_style, sql_data_access, dtd_identifier from information_schema.routines;parameter_style sql_data_access dtd_identifierSQL CONTAINS SQL NULLSQL CONTAINS SQL int(11)show procedure status;Db Name Type Definer Modified Created Security_type Comment character_set_client collation_connection Database Collationtest sel2 PROCEDURE root@localhost # # DEFINER latin1 latin1_swedish_ci latin1_swedish_cishow function status;Db Name Type Definer Modified Created Security_type Comment character_set_client collation_connection Database Collationtest sub1 FUNCTION root@localhost # # DEFINER latin1 latin1_swedish_ci latin1_swedish_ciselect a.ROUTINE_NAME from information_schema.ROUTINES a,information_schema.SCHEMATA b wherea.ROUTINE_SCHEMA = b.SCHEMA_NAME;ROUTINE_NAMEsel2sub1explain select a.ROUTINE_NAME from information_schema.ROUTINES a,information_schema.SCHEMATA b wherea.ROUTINE_SCHEMA = b.SCHEMA_NAME;id select_type table type possible_keys key key_len ref rows Extra1 SIMPLE # ALL NULL NULL NULL NULL NULL 1 SIMPLE # ALL NULL NULL NULL NULL NULL Using where; Using join bufferselect a.ROUTINE_NAME, b.name from information_schema.ROUTINES a,mysql.proc b where a.ROUTINE_NAME = convert(b.name using utf8) order by 1;ROUTINE_NAME namesel2 sel2sub1 sub1select count(*) from information_schema.ROUTINES;count(*)2create view v1 as select routine_schema, routine_name from information_schema.routines order by routine_schema, routine_name;select * from v1;routine_schema routine_nametest sel2test sub1drop view v1;select ROUTINE_NAME, ROUTINE_DEFINITION from information_schema.ROUTINES;ROUTINE_NAME ROUTINE_DEFINITIONshow create function sub1;ERROR 42000: FUNCTION sub1 does not existselect ROUTINE_NAME, ROUTINE_DEFINITION from information_schema.ROUTINES;ROUTINE_NAME ROUTINE_DEFINITIONsel2 NULLsub1 NULLgrant all privileges on test.* to mysqltest_1@localhost;select ROUTINE_NAME, ROUTINE_DEFINITION from information_schema.ROUTINES;ROUTINE_NAME ROUTINE_DEFINITIONsel2 NULLsub1 NULLcreate function sub2(i int) returns intreturn i+1;select ROUTINE_NAME, ROUTINE_DEFINITION from information_schema.ROUTINES;ROUTINE_NAME ROUTINE_DEFINITIONsel2 NULLsub1 NULLsub2 return i+1show create procedure sel2;Procedure sql_mode Create Procedure character_set_client collation_connection Database Collationsel2 NULL latin1 latin1_swedish_ci latin1_swedish_cishow create function sub1;Function sql_mode Create Function character_set_client collation_connection Database Collationsub1 NULL latin1 latin1_swedish_ci latin1_swedish_cishow create function sub2;Function sql_mode Create Function character_set_client collation_connection Database Collationsub2 CREATE DEFINER=`mysqltest_1`@`localhost` FUNCTION `sub2`(i int) RETURNS int(11)return i+1 latin1 latin1_swedish_ci latin1_swedish_cishow function status like "sub2";Db Name Type Definer Modified Created Security_type Comment character_set_client collation_connection Database Collationtest sub2 FUNCTION mysqltest_1@localhost # # DEFINER latin1 latin1_swedish_ci latin1_swedish_cidrop function sub2;show create procedure sel2;Procedure sql_mode Create Procedure character_set_client collation_connection Database Collationsel2 CREATE DEFINER=`root`@`localhost` PROCEDURE `sel2`()beginselect * from t1;select * from t2;end latin1 latin1_swedish_ci latin1_swedish_cicreate view v0 (c) as select schema_name from information_schema.schemata;select * from v0;cinformation_schemamysqltestexplain select * from v0;id select_type table type possible_keys key key_len ref rows Extra1 SIMPLE # ALL NULL NULL NULL NULL NULL create view v1 (c) as select table_name from information_schema.tableswhere table_name="v1";select * from v1;cv1create view v2 (c) as select column_name from information_schema.columnswhere table_name="v2";select * from v2;cccreate view v3 (c) as select CHARACTER_SET_NAME from information_schema.character_setswhere CHARACTER_SET_NAME like "latin1%";select * from v3;clatin1create view v4 (c) as select COLLATION_NAME from information_schema.collationswhere COLLATION_NAME like "latin1%";select * from v4;clatin1_german1_cilatin1_swedish_cilatin1_danish_cilatin1_german2_cilatin1_binlatin1_general_cilatin1_general_cslatin1_spanish_cishow keys from v4;Table Non_unique Key_name Seq_in_index Column_name Collation Cardinality Sub_part Packed Null Index_type Commentselect * from information_schema.views where TABLE_NAME like "v%";TABLE_CATALOG TABLE_SCHEMA TABLE_NAME VIEW_DEFINITION CHECK_OPTION IS_UPDATABLE DEFINER SECURITY_TYPE CHARACTER_SET_CLIENT COLLATION_CONNECTIONNULL test v0 select `schemata`.`SCHEMA_NAME` AS `c` from `information_schema`.`schemata` NONE NO root@localhost DEFINER latin1 latin1_swedish_ciNULL test v1 select `tables`.`TABLE_NAME` AS `c` from `information_schema`.`tables` where (`tables`.`TABLE_NAME` = 'v1') NONE NO root@localhost DEFINER latin1 latin1_swedish_ciNULL test v2 select `columns`.`COLUMN_NAME` AS `c` from `information_schema`.`columns` where (`columns`.`TABLE_NAME` = 'v2') NONE NO root@localhost DEFINER latin1 latin1_swedish_ciNULL test v3 select `character_sets`.`CHARACTER_SET_NAME` AS `c` from `information_schema`.`character_sets` where (`character_sets`.`CHARACTER_SET_NAME` like 'latin1%') NONE NO root@localhost DEFINER latin1 latin1_swedish_ciNULL test v4 select `collations`.`COLLATION_NAME` AS `c` from `information_schema`.`collations` where (`collations`.`COLLATION_NAME` like 'latin1%') NONE NO root@localhost DEFINER latin1 latin1_swedish_cidrop view v0, v1, v2, v3, v4;create table t1 (a int);grant select,update,insert on t1 to mysqltest_1@localhost;grant select (a), update (a),insert(a), references(a) on t1 to mysqltest_1@localhost;grant all on test.* to mysqltest_1@localhost with grant option;select * from information_schema.USER_PRIVILEGES where grantee like '%mysqltest_1%';GRANTEE TABLE_CATALOG PRIVILEGE_TYPE IS_GRANTABLE'mysqltest_1'@'localhost' NULL USAGE NOselect * from information_schema.SCHEMA_PRIVILEGES where grantee like '%mysqltest_1%';GRANTEE TABLE_CATALOG TABLE_SCHEMA PRIVILEGE_TYPE IS_GRANTABLE'mysqltest_1'@'localhost' NULL test SELECT YES'mysqltest_1'@'localhost' NULL test INSERT YES'mysqltest_1'@'localhost' NULL test UPDATE YES'mysqltest_1'@'localhost' NULL test DELETE YES'mysqltest_1'@'localhost' NULL test CREATE YES'mysqltest_1'@'localhost' NULL test DROP YES'mysqltest_1'@'localhost' NULL test REFERENCES YES'mysqltest_1'@'localhost' NULL test INDEX YES'mysqltest_1'@'localhost' NULL test ALTER YES'mysqltest_1'@'localhost' NULL test CREATE TEMPORARY TABLES YES'mysqltest_1'@'localhost' NULL test LOCK TABLES YES'mysqltest_1'@'localhost' NULL test EXECUTE YES'mysqltest_1'@'localhost' NULL test CREATE VIEW YES'mysqltest_1'@'localhost' NULL test SHOW VIEW YES'mysqltest_1'@'localhost' NULL test CREATE ROUTINE YES'mysqltest_1'@'localhost' NULL test ALTER ROUTINE YES'mysqltest_1'@'localhost' NULL test EVENT YES'mysqltest_1'@'localhost' NULL test TRIGGER YESselect * from information_schema.TABLE_PRIVILEGES where grantee like '%mysqltest_1%';GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME PRIVILEGE_TYPE IS_GRANTABLE'mysqltest_1'@'localhost' NULL test t1 SELECT NO'mysqltest_1'@'localhost' NULL test t1 INSERT NO'mysqltest_1'@'localhost' NULL test t1 UPDATE NOselect * from information_schema.COLUMN_PRIVILEGES where grantee like '%mysqltest_1%';GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME PRIVILEGE_TYPE IS_GRANTABLE'mysqltest_1'@'localhost' NULL test t1 a SELECT NO'mysqltest_1'@'localhost' NULL test t1 a INSERT NO'mysqltest_1'@'localhost' NULL test t1 a UPDATE NO'mysqltest_1'@'localhost' NULL test t1 a REFERENCES NOdelete from mysql.user where user like 'mysqltest%';delete from mysql.db where user like 'mysqltest%';delete from mysql.tables_priv where user like 'mysqltest%';delete from mysql.columns_priv where user like 'mysqltest%';flush privileges;drop table t1;create table t1 (a int null, primary key(a));alter table t1 add constraint constraint_1 unique (a);alter table t1 add constraint unique key_1(a);alter table t1 add constraint constraint_2 unique key_2(a);show create table t1;Table Create Tablet1 CREATE TABLE `t1` ( `a` int(11) NOT NULL DEFAULT '0', PRIMARY KEY (`a`), UNIQUE KEY `constraint_1` (`a`), UNIQUE KEY `key_1` (`a`), UNIQUE KEY `key_2` (`a`)) ENGINE=MyISAM DEFAULT CHARSET=latin1select * from information_schema.TABLE_CONSTRAINTS whereTABLE_SCHEMA= "test";CONSTRAINT_CATALOG CONSTRAINT_SCHEMA CONSTRAINT_NAME TABLE_SCHEMA TABLE_NAME CONSTRAINT_TYPENULL test PRIMARY test t1 PRIMARY KEYNULL test constraint_1 test t1 UNIQUENULL test key_1 test t1 UNIQUENULL test key_2 test t1 UNIQUEselect * from information_schema.KEY_COLUMN_USAGE whereTABLE_SCHEMA= "test";CONSTRAINT_CATALOG CONSTRAINT_SCHEMA CONSTRAINT_NAME TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME ORDINAL_POSITION POSITION_IN_UNIQUE_CONSTRAINT REFERENCED_TABLE_SCHEMA REFERENCED_TABLE_NAME REFERENCED_COLUMN_NAMENULL test PRIMARY NULL test t1 a 1 NULL NULL NULL NULLNULL test constraint_1 NULL test t1 a 1 NULL NULL NULL NULLNULL test key_1 NULL test t1 a 1 NULL NULL NULL NULLNULL test key_2 NULL test t1 a 1 NULL NULL NULL NULLselect table_name from information_schema.TABLES where table_schema like "test%";table_namet1select table_name,column_name from information_schema.COLUMNS where table_schema like "test%";table_name column_namet1 aselect ROUTINE_NAME from information_schema.ROUTINES;ROUTINE_NAMEsel2sub1delete from mysql.user where user='mysqltest_1';drop table t1;drop procedure sel2;drop function sub1;create table t1(a int);create view v1 (c) as select a from t1 with check option;create view v2 (c) as select a from t1 WITH LOCAL CHECK OPTION;create view v3 (c) as select a from t1 WITH CASCADED CHECK OPTION;select * from information_schema.views;TABLE_CATALOG TABLE_SCHEMA TABLE_NAME VIEW_DEFINITION CHECK_OPTION IS_UPDATABLE DEFINER SECURITY_TYPE CHARACTER_SET_CLIENT COLLATION_CONNECTIONNULL test v1 select `test`.`t1`.`a` AS `c` from `test`.`t1` CASCADED YES root@localhost DEFINER latin1 latin1_swedish_ciNULL test v2 select `test`.`t1`.`a` AS `c` from `test`.`t1` LOCAL YES root@localhost DEFINER latin1 latin1_swedish_ciNULL test v3 select `test`.`t1`.`a` AS `c` from `test`.`t1` CASCADED YES root@localhost DEFINER latin1 latin1_swedish_cigrant select (a) on test.t1 to joe@localhost with grant option;select * from INFORMATION_SCHEMA.COLUMN_PRIVILEGES;GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME PRIVILEGE_TYPE IS_GRANTABLE'joe'@'localhost' NULL test t1 a SELECT YESselect * from INFORMATION_SCHEMA.TABLE_PRIVILEGES;GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME PRIVILEGE_TYPE IS_GRANTABLEdrop view v1, v2, v3;drop table t1;delete from mysql.user where user='joe';delete from mysql.db where user='joe';delete from mysql.tables_priv where user='joe';delete from mysql.columns_priv where user='joe';flush privileges;create table t1 (a int not null auto_increment,b int, primary key (a));insert into t1 values (1,1),(NULL,3),(NULL,4);select AUTO_INCREMENT from information_schema.tables where table_name = 't1';AUTO_INCREMENT4drop table t1;create table t1 (s1 int);insert into t1 values (0),(9),(0);select s1 from t1 where s1 in (select version frominformation_schema.tables) union select version frominformation_schema.tables;s110drop table t1;SHOW CREATE TABLE INFORMATION_SCHEMA.character_sets;Table Create TableCHARACTER_SETS CREATE TEMPORARY TABLE `CHARACTER_SETS` ( `CHARACTER_SET_NAME` varchar(32) NOT NULL DEFAULT '', `DEFAULT_COLLATE_NAME` varchar(32) NOT NULL DEFAULT '', `DESCRIPTION` varchar(60) NOT NULL DEFAULT '', `MAXLEN` bigint(3) NOT NULL DEFAULT '0') ENGINE=MEMORY DEFAULT CHARSET=utf8set names latin2;SHOW CREATE TABLE INFORMATION_SCHEMA.character_sets;Table Create TableCHARACTER_SETS CREATE TEMPORARY TABLE `CHARACTER_SETS` ( `CHARACTER_SET_NAME` varchar(32) NOT NULL DEFAULT '', `DEFAULT_COLLATE_NAME` varchar(32) NOT NULL DEFAULT '', `DESCRIPTION` varchar(60) NOT NULL DEFAULT '', `MAXLEN` bigint(3) NOT NULL DEFAULT '0') ENGINE=MEMORY DEFAULT CHARSET=utf8set names latin1;create table t1 select * from information_schema.CHARACTER_SETSwhere CHARACTER_SET_NAME like "latin1";select * from t1;CHARACTER_SET_NAME DEFAULT_COLLATE_NAME DESCRIPTION MAXLENlatin1 latin1_swedish_ci cp1252 West European 1alter table t1 default character set utf8;show create table t1;Table Create Tablet1 CREATE TABLE `t1` ( `CHARACTER_SET_NAME` varchar(32) NOT NULL DEFAULT '', `DEFAULT_COLLATE_NAME` varchar(32) NOT NULL DEFAULT '', `DESCRIPTION` varchar(60) NOT NULL DEFAULT '', `MAXLEN` bigint(3) NOT NULL DEFAULT '0') ENGINE=MyISAM DEFAULT CHARSET=utf8drop table t1;create view v1 as select * from information_schema.TABLES;drop view v1;create table t1(a NUMERIC(5,3), b NUMERIC(5,1), c float(5,2),d NUMERIC(6,4), e float, f DECIMAL(6,3), g int(11), h DOUBLE(10,3),i DOUBLE);select COLUMN_NAME,COLUMN_TYPE, CHARACTER_MAXIMUM_LENGTH, CHARACTER_OCTET_LENGTH, NUMERIC_PRECISION, NUMERIC_SCALEfrom information_schema.columns where table_name= 't1';COLUMN_NAME COLUMN_TYPE CHARACTER_MAXIMUM_LENGTH CHARACTER_OCTET_LENGTH NUMERIC_PRECISION NUMERIC_SCALEa decimal(5,3) NULL NULL 5 3b decimal(5,1) NULL NULL 5 1c float(5,2) NULL NULL 5 2d decimal(6,4) NULL NULL 6 4e float NULL NULL 12 NULLf decimal(6,3) NULL NULL 6 3g int(11) NULL NULL 10 0h double(10,3) NULL NULL 10 3i double NULL NULL 22 NULLdrop table t1;create table t115 as select table_name, column_name, column_typefrom information_schema.columns where table_name = 'proc';select * from t115;table_name column_name column_typeproc db char(64)proc name char(64)proc type enum('FUNCTION','PROCEDURE')proc specific_name char(64)proc language enum('SQL')proc sql_data_access enum('CONTAINS_SQL','NO_SQL','READS_SQL_DATA','MODIFIES_SQL_DATA')proc is_deterministic enum('YES','NO')proc security_type enum('INVOKER','DEFINER')proc param_list blobproc returns longblobproc body longblobproc definer char(77)proc created timestampproc modified timestampproc sql_mode set('REAL_AS_FLOAT','PIPES_AS_CONCAT','ANSI_QUOTES','IGNORE_SPACE','NOT_USED','ONLY_FULL_GROUP_BY','NO_UNSIGNED_SUBTRACTION','NO_DIR_IN_CREATE','POSTGRESQL','ORACLE','MSSQL','DB2','MAXDB','NO_KEY_OPTIONS','NO_TABLE_OPTIONS','NO_FIELD_OPTIONS','MYSQL323','MYSQL40','ANSI','NO_AUTO_VALUE_ON_ZERO','NO_BACKSLASH_ESCAPES','STRICT_TRANS_TABLES','STRICT_ALL_TABLES','NO_ZERO_IN_DATE','NO_ZERO_DATE','INVALID_DATES','ERROR_FOR_DIVISION_BY_ZERO','TRADITIONAL','NO_AUTO_CREATE_USER','HIGH_NOT_PRECEDENCE','NO_ENGINE_SUBSTITUTION','PAD_CHAR_TO_FULL_LENGTH')proc comment char(64)proc character_set_client char(32)proc collation_connection char(32)proc db_collation char(32)proc body_utf8 longblobdrop table t115;create procedure p108 () begin declare c cursor for select data_typefrom information_schema.columns; open c; open c; end;//call p108()//ERROR 24000: Cursor is already opendrop procedure p108;create view v1 as select A1.table_name from information_schema.TABLES A1where table_name= "user";select * from v1;table_nameuserdrop view v1;create view vo as select 'a' union select 'a';show index from vo;Table Non_unique Key_name Seq_in_index Column_name Collation Cardinality Sub_part Packed Null Index_type Commentselect * from information_schema.TABLE_CONSTRAINTS whereTABLE_NAME= "vo";CONSTRAINT_CATALOG CONSTRAINT_SCHEMA CONSTRAINT_NAME TABLE_SCHEMA TABLE_NAME CONSTRAINT_TYPEselect * from information_schema.KEY_COLUMN_USAGE whereTABLE_NAME= "vo";CONSTRAINT_CATALOG CONSTRAINT_SCHEMA CONSTRAINT_NAME TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME ORDINAL_POSITION POSITION_IN_UNIQUE_CONSTRAINT REFERENCED_TABLE_SCHEMA REFERENCED_TABLE_NAME REFERENCED_COLUMN_NAMEdrop view vo;select TABLE_NAME,TABLE_TYPE,ENGINEfrom information_schema.tables where table_schema='information_schema' limit 2;TABLE_NAME TABLE_TYPE ENGINECHARACTER_SETS SYSTEM VIEW MEMORYCOLLATIONS SYSTEM VIEW MEMORYshow tables from information_schema like "T%";Tables_in_information_schema (T%)TABLESTABLE_CONSTRAINTSTABLE_PRIVILEGESTRIGGERScreate database information_schema;ERROR 42000: Access denied for user 'root'@'localhost' to database 'information_schema'use information_schema;show full tables like "T%";Tables_in_information_schema (T%) Table_typeTABLES SYSTEM VIEWTABLE_CONSTRAINTS SYSTEM VIEWTABLE_PRIVILEGES SYSTEM VIEWTRIGGERS SYSTEM VIEWcreate table t1(a int);ERROR 42S02: Unknown table 't1' in information_schemause test;show tables;Tables_in_testuse information_schema;show tables like "T%";Tables_in_information_schema (T%)TABLESTABLE_CONSTRAINTSTABLE_PRIVILEGESTRIGGERSselect table_name from tables where table_name='user';table_nameuserselect column_name, privileges from columnswhere table_name='user' and column_name like '%o%';column_name privilegesHost select,insert,update,referencesPassword select,insert,update,referencesDrop_priv select,insert,update,referencesReload_priv select,insert,update,referencesShutdown_priv select,insert,update,referencesProcess_priv select,insert,update,referencesShow_db_priv select,insert,update,referencesLock_tables_priv select,insert,update,referencesShow_view_priv select,insert,update,referencesCreate_routine_priv select,insert,update,referencesAlter_routine_priv select,insert,update,referencesmax_questions select,insert,update,referencesmax_connections select,insert,update,referencesmax_user_connections select,insert,update,referencesuse test;create function sub1(i int) returns intreturn i+1;create table t1(f1 int);create view v2 (c) as select f1 from t1;create view v3 (c) as select sub1(1);create table t4(f1 int, KEY f1_key (f1));drop table t1;drop function sub1;select table_name from information_schema.viewswhere table_schema='test';table_namev2v3select table_name from information_schema.viewswhere table_schema='test';table_namev2v3select column_name from information_schema.columnswhere table_schema='test';column_namef1Warnings:Warning 1356 View 'test.v2' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use themWarning 1356 View 'test.v3' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use themselect index_name from information_schema.statistics where table_schema='test';index_namef1_keyselect constraint_name from information_schema.table_constraintswhere table_schema='test';constraint_nameshow create view v2;View Create View character_set_client collation_connectionv2 CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER VIEW `v2` AS select `test`.`t1`.`f1` AS `c` from `t1` latin1 latin1_swedish_ciWarnings:Warning 1356 View 'test.v2' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use themshow create table v3;View Create View character_set_client collation_connectionv3 CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER VIEW `v3` AS select `sub1`(1) AS `c` latin1 latin1_swedish_ciWarnings:Warning 1356 View 'test.v3' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use themdrop view v2;drop view v3;drop table t4;select * from information_schema.table_names;ERROR 42S02: Unknown table 'table_names' in information_schemaselect column_type from information_schema.columnswhere table_schema="information_schema" and table_name="COLUMNS" and(column_name="character_set_name" or column_name="collation_name");column_typevarchar(32)varchar(32)select TABLE_ROWS from information_schema.tables where table_schema="information_schema" and table_name="COLUMNS";TABLE_ROWSNULLselect table_type from information_schema.tableswhere table_schema="mysql" and table_name="user";table_typeBASE TABLEshow open tables where `table` like "user";Database Table In_use Name_lockedmysql user 0 0show status where variable_name like "%database%";Variable_name ValueCom_show_databases 3show variables where variable_name like "skip_show_databas";Variable_name Valueshow global status like "Threads_running";Variable_name ValueThreads_running #create table t1(f1 int);create table t2(f2 int);create view v1 as select * from t1, t2;set @got_val= (select count(*) from information_schema.columns);drop view v1;drop table t1, t2;use test;CREATE TABLE t_crashme ( f1 BIGINT);CREATE VIEW a1 (t_CRASHME) AS SELECT f1 FROM t_crashme GROUP BY f1;CREATE VIEW a2 AS SELECT t_CRASHME FROM a1;count(*)68drop view a2, a1;drop table t_crashme;select table_schema,table_name, column_name frominformation_schema.columns where data_type = 'longtext';table_schema table_name column_nameinformation_schema COLUMNS COLUMN_DEFAULTinformation_schema COLUMNS COLUMN_TYPEinformation_schema EVENTS EVENT_DEFINITIONinformation_schema PARTITIONS PARTITION_EXPRESSIONinformation_schema PARTITIONS SUBPARTITION_EXPRESSIONinformation_schema PARTITIONS PARTITION_DESCRIPTIONinformation_schema PLUGINS PLUGIN_DESCRIPTIONinformation_schema PROCESSLIST INFOinformation_schema ROUTINES ROUTINE_DEFINITIONinformation_schema TRIGGERS ACTION_CONDITIONinformation_schema TRIGGERS ACTION_STATEMENTinformation_schema VIEWS VIEW_DEFINITIONselect table_name, column_name, data_type from information_schema.columnswhere data_type = 'datetime';table_name column_name data_typeEVENTS EXECUTE_AT datetimeEVENTS STARTS datetimeEVENTS ENDS datetimeEVENTS CREATED datetimeEVENTS LAST_ALTERED datetimeEVENTS LAST_EXECUTED datetimeFILES CREATION_TIME datetimeFILES LAST_UPDATE_TIME datetimeFILES LAST_ACCESS_TIME datetimeFILES CREATE_TIME datetimeFILES UPDATE_TIME datetimeFILES CHECK_TIME datetimePARTITIONS CREATE_TIME datetimePARTITIONS UPDATE_TIME datetimePARTITIONS CHECK_TIME datetimeROUTINES CREATED datetimeROUTINES LAST_ALTERED datetimeTABLES CREATE_TIME datetimeTABLES UPDATE_TIME datetimeTABLES CHECK_TIME datetimeTRIGGERS CREATED datetimeevent execute_at datetimeevent last_executed datetimeevent starts datetimeevent ends datetimeSELECT COUNT(*) FROM INFORMATION_SCHEMA.TABLES AWHERE NOT EXISTS (SELECT * FROM INFORMATION_SCHEMA.COLUMNS BWHERE A.TABLE_SCHEMA = B.TABLE_SCHEMAAND A.TABLE_NAME = B.TABLE_NAME);COUNT(*)0create table t1( x_bigint BIGINT,x_integer INTEGER,x_smallint SMALLINT,x_decimal DECIMAL(5,3),x_numeric NUMERIC(5,3),x_real REAL,x_float FLOAT,x_double_precision DOUBLE PRECISION );SELECT COLUMN_NAME, CHARACTER_MAXIMUM_LENGTH, CHARACTER_OCTET_LENGTHFROM INFORMATION_SCHEMA.COLUMNSWHERE TABLE_NAME= 't1';COLUMN_NAME CHARACTER_MAXIMUM_LENGTH CHARACTER_OCTET_LENGTHx_bigint NULL NULLx_integer NULL NULLx_smallint NULL NULLx_decimal NULL NULLx_numeric NULL NULLx_real NULL NULLx_float NULL NULLx_double_precision NULL NULLdrop table t1;grant select on test.* to mysqltest_4@localhost;SELECT TABLE_NAME, COLUMN_NAME, PRIVILEGES FROM INFORMATION_SCHEMA.COLUMNS where COLUMN_NAME='TABLE_NAME';TABLE_NAME COLUMN_NAME PRIVILEGESCOLUMNS TABLE_NAME selectCOLUMN_PRIVILEGES TABLE_NAME selectFILES TABLE_NAME selectKEY_COLUMN_USAGE TABLE_NAME selectPARTITIONS TABLE_NAME selectREFERENTIAL_CONSTRAINTS TABLE_NAME selectSTATISTICS TABLE_NAME selectTABLES TABLE_NAME selectTABLE_CONSTRAINTS TABLE_NAME selectTABLE_PRIVILEGES TABLE_NAME selectVIEWS TABLE_NAME selectdelete from mysql.user where user='mysqltest_4';delete from mysql.db where user='mysqltest_4';flush privileges;SELECT table_schema, count(*) FROM information_schema.TABLES where table_name<>'ndb_binlog_index' AND table_name<>'ndb_apply_status' GROUP BY TABLE_SCHEMA;table_schema count(*)information_schema 28mysql 22create table t1 (i int, j int);create trigger trg1 before insert on t1 for each rowbeginif new.j > 10 thenset new.j := 10;end if;end|create trigger trg2 before update on t1 for each rowbeginif old.i % 2 = 0 thenset new.j := -1;end if;end|create trigger trg3 after update on t1 for each rowbeginif new.j = -1 thenset @fired:= "Yes";end if;end|show triggers;Trigger Event Table Statement Timing Created sql_mode Definer character_set_client collation_connection Database Collationtrg1 INSERT t1 beginif new.j > 10 thenset new.j := 10;end if;end BEFORE NULL root@localhost latin1 latin1_swedish_ci latin1_swedish_citrg2 UPDATE t1 beginif old.i % 2 = 0 thenset new.j := -1;end if;end BEFORE NULL root@localhost latin1 latin1_swedish_ci latin1_swedish_citrg3 UPDATE t1 beginif new.j = -1 thenset @fired:= "Yes";end if;end AFTER NULL root@localhost latin1 latin1_swedish_ci latin1_swedish_ciselect * from information_schema.triggers;TRIGGER_CATALOG TRIGGER_SCHEMA TRIGGER_NAME EVENT_MANIPULATION EVENT_OBJECT_CATALOG EVENT_OBJECT_SCHEMA EVENT_OBJECT_TABLE ACTION_ORDER ACTION_CONDITION ACTION_STATEMENT ACTION_ORIENTATION ACTION_TIMING ACTION_REFERENCE_OLD_TABLE ACTION_REFERENCE_NEW_TABLE ACTION_REFERENCE_OLD_ROW ACTION_REFERENCE_NEW_ROW CREATED SQL_MODE DEFINER CHARACTER_SET_CLIENT COLLATION_CONNECTION DATABASE_COLLATIONNULL test trg1 INSERT NULL test t1 0 NULL beginif new.j > 10 thenset new.j := 10;end if;end ROW BEFORE NULL NULL OLD NEW NULL root@localhost latin1 latin1_swedish_ci latin1_swedish_ciNULL test trg2 UPDATE NULL test t1 0 NULL beginif old.i % 2 = 0 thenset new.j := -1;end if;end ROW BEFORE NULL NULL OLD NEW NULL root@localhost latin1 latin1_swedish_ci latin1_swedish_ciNULL test trg3 UPDATE NULL test t1 0 NULL beginif new.j = -1 thenset @fired:= "Yes";end if;end ROW AFTER NULL NULL OLD NEW NULL root@localhost latin1 latin1_swedish_ci latin1_swedish_cidrop trigger trg1;drop trigger trg2;drop trigger trg3;drop table t1;create database mysqltest;create table mysqltest.t1 (f1 int, f2 int);create table mysqltest.t2 (f1 int);grant select (f1) on mysqltest.t1 to user1@localhost;grant select on mysqltest.t2 to user2@localhost;grant select on mysqltest.* to user3@localhost;grant select on *.* to user4@localhost;select * from information_schema.column_privileges order by grantee;GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME PRIVILEGE_TYPE IS_GRANTABLE'user1'@'localhost' NULL mysqltest t1 f1 SELECT NOselect * from information_schema.table_privileges order by grantee;GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME PRIVILEGE_TYPE IS_GRANTABLEselect * from information_schema.schema_privileges order by grantee;GRANTEE TABLE_CATALOG TABLE_SCHEMA PRIVILEGE_TYPE IS_GRANTABLEselect * from information_schema.user_privileges order by grantee;GRANTEE TABLE_CATALOG PRIVILEGE_TYPE IS_GRANTABLE'user1'@'localhost' NULL USAGE NOshow grants;Grants for user1@localhostGRANT USAGE ON *.* TO 'user1'@'localhost'GRANT SELECT (f1) ON `mysqltest`.`t1` TO 'user1'@'localhost'select * from information_schema.column_privileges order by grantee;GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME PRIVILEGE_TYPE IS_GRANTABLEselect * from information_schema.table_privileges order by grantee;GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME PRIVILEGE_TYPE IS_GRANTABLE'user2'@'localhost' NULL mysqltest t2 SELECT NOselect * from information_schema.schema_privileges order by grantee;GRANTEE TABLE_CATALOG TABLE_SCHEMA PRIVILEGE_TYPE IS_GRANTABLEselect * from information_schema.user_privileges order by grantee;GRANTEE TABLE_CATALOG PRIVILEGE_TYPE IS_GRANTABLE'user2'@'localhost' NULL USAGE NOshow grants;Grants for user2@localhostGRANT USAGE ON *.* TO 'user2'@'localhost'GRANT SELECT ON `mysqltest`.`t2` TO 'user2'@'localhost'select * from information_schema.column_privileges order by grantee;GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME PRIVILEGE_TYPE IS_GRANTABLEselect * from information_schema.table_privileges order by grantee;GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME PRIVILEGE_TYPE IS_GRANTABLEselect * from information_schema.schema_privileges order by grantee;GRANTEE TABLE_CATALOG TABLE_SCHEMA PRIVILEGE_TYPE IS_GRANTABLE'user3'@'localhost' NULL mysqltest SELECT NOselect * from information_schema.user_privileges order by grantee;GRANTEE TABLE_CATALOG PRIVILEGE_TYPE IS_GRANTABLE'user3'@'localhost' NULL USAGE NOshow grants;Grants for user3@localhostGRANT USAGE ON *.* TO 'user3'@'localhost'GRANT SELECT ON `mysqltest`.* TO 'user3'@'localhost'select * from information_schema.column_privileges where grantee like '%user%'order by grantee;GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME PRIVILEGE_TYPE IS_GRANTABLE'user1'@'localhost' NULL mysqltest t1 f1 SELECT NOselect * from information_schema.table_privileges where grantee like '%user%'order by grantee;GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME PRIVILEGE_TYPE IS_GRANTABLE'user2'@'localhost' NULL mysqltest t2 SELECT NOselect * from information_schema.schema_privileges where grantee like '%user%'order by grantee;GRANTEE TABLE_CATALOG TABLE_SCHEMA PRIVILEGE_TYPE IS_GRANTABLE'user3'@'localhost' NULL mysqltest SELECT NOselect * from information_schema.user_privileges where grantee like '%user%'order by grantee;GRANTEE TABLE_CATALOG PRIVILEGE_TYPE IS_GRANTABLE'user1'@'localhost' NULL USAGE NO'user2'@'localhost' NULL USAGE NO'user3'@'localhost' NULL USAGE NO'user4'@'localhost' NULL SELECT NOshow grants;Grants for user4@localhostGRANT SELECT ON *.* TO 'user4'@'localhost'drop user user1@localhost, user2@localhost, user3@localhost, user4@localhost;use test;drop database mysqltest;drop procedure if exists p1;drop procedure if exists p2;create procedure p1 () modifies sql data set @a = 5;create procedure p2 () set @a = 5;select sql_data_access from information_schema.routineswhere specific_name like 'p%';sql_data_accessMODIFIES SQL DATACONTAINS SQLdrop procedure p1;drop procedure p2;show create database information_schema;Database Create Databaseinformation_schema CREATE DATABASE `information_schema` /*!40100 DEFAULT CHARACTER SET utf8 */create table t1(f1 LONGBLOB, f2 LONGTEXT);select column_name,data_type,CHARACTER_OCTET_LENGTH,CHARACTER_MAXIMUM_LENGTHfrom information_schema.columnswhere table_name='t1';column_name data_type CHARACTER_OCTET_LENGTH CHARACTER_MAXIMUM_LENGTHf1 longblob 4294967295 4294967295f2 longtext 4294967295 4294967295drop table t1;create table t1(f1 tinyint, f2 SMALLINT, f3 mediumint, f4 int,f5 BIGINT, f6 BIT, f7 bit(64));select column_name, NUMERIC_PRECISION, NUMERIC_SCALEfrom information_schema.columnswhere table_name='t1';column_name NUMERIC_PRECISION NUMERIC_SCALEf1 3 0f2 5 0f3 7 0f4 10 0f5 19 0f6 1 NULLf7 64 NULLdrop table t1;create table t1 (f1 integer);create trigger tr1 after insert on t1 for each row set @test_var=42;use information_schema;select trigger_schema, trigger_name from triggers wheretrigger_name='tr1';trigger_schema trigger_nametest tr1use test;drop table t1;create table t1 (a int not null, b int);use information_schema;select column_name, column_default from columnswhere table_schema='test' and table_name='t1';column_name column_defaulta NULLb NULLuse test;show columns from t1;Field Type Null Key Default Extraa int(11) NO NULL b int(11) YES NULL drop table t1;CREATE TABLE t1 (a int);CREATE TABLE t2 (b int);SHOW TABLE STATUS FROM testWHERE name IN ( SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLESWHERE TABLE_SCHEMA='test' AND TABLE_TYPE='BASE TABLE');Name Engine Version Row_format Rows Avg_row_length Data_length Max_data_length Index_length Data_free Auto_increment Create_time Update_time Check_time Collation Checksum Create_options Commentt1 MyISAM 10 Fixed 0 0 0 # 1024 0 NULL # # NULL latin1_swedish_ci NULL t2 MyISAM 10 Fixed 0 0 0 # 1024 0 NULL # # NULL latin1_swedish_ci NULL DROP TABLE t1,t2;create table t1(f1 int);create view v1 (c) as select f1 from t1;select database();database()NULLshow fields from test.v1;Field Type Null Key Default Extrac int(11) YES NULL drop view v1;drop table t1;alter database information_schema;ERROR 42000: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1drop database information_schema;ERROR 42000: Access denied for user 'root'@'localhost' to database 'information_schema'drop table information_schema.tables;ERROR 42000: Access denied for user 'root'@'localhost' to database 'information_schema'alter table information_schema.tables;ERROR 42000: Access denied for user 'root'@'localhost' to database 'information_schema'use information_schema;create temporary table schemata(f1 char(10));ERROR 42000: Access denied for user 'root'@'localhost' to database 'information_schema'CREATE PROCEDURE p1 ()BEGINSELECT 'foo' FROM DUAL;END |ERROR 42000: Unknown database 'information_schema'select ROUTINE_NAME from routines;ROUTINE_NAMEgrant all on information_schema.* to 'user1'@'localhost';ERROR 42000: Access denied for user 'root'@'localhost' to database 'information_schema'grant select on information_schema.* to 'user1'@'localhost';ERROR 42000: Access denied for user 'root'@'localhost' to database 'information_schema'use test;create table t1(id int);insert into t1(id) values (1);select 1 from (select 1 from test.t1) a;11use information_schema;select 1 from (select 1 from test.t1) a;11use test;drop table t1;create table t1 (f1 int(11));create view v1 as select * from t1;drop table t1;select table_type from information_schema.tableswhere table_name="v1";table_typeVIEWdrop view v1;create temporary table t1(f1 int, index(f1));show columns from t1;Field Type Null Key Default Extraf1 int(11) YES MUL NULL describe t1;Field Type Null Key Default Extraf1 int(11) YES MUL NULL show indexes from t1;Table Non_unique Key_name Seq_in_index Column_name Collation Cardinality Sub_part Packed Null Index_type Commentt1 1 f1 1 f1 A NULL NULL NULL YES BTREE drop table t1;create table t1(f1 binary(32), f2 varbinary(64));select character_maximum_length, character_octet_lengthfrom information_schema.columns where table_name='t1';character_maximum_length character_octet_length32 3264 64drop table t1;CREATE TABLE t1 (f1 BIGINT, f2 VARCHAR(20), f3 BIGINT);INSERT INTO t1 SET f1 = 1, f2 = 'Schoenenbourg', f3 = 1;CREATE FUNCTION func2() RETURNS BIGINT RETURN 1;CREATE FUNCTION func1() RETURNS BIGINTBEGINRETURN ( SELECT COUNT(*) FROM INFORMATION_SCHEMA.VIEWS);END//CREATE VIEW v1 AS SELECT 1 FROM t1WHERE f3 = (SELECT func2 ());SELECT func1();func1()1DROP TABLE t1;DROP VIEW v1;DROP FUNCTION func1;DROP FUNCTION func2;select column_type, group_concat(table_schema, '.', table_name), count(*) as numfrom information_schema.columns wheretable_schema='information_schema' and(column_type = 'varchar(7)' or column_type = 'varchar(20)' or column_type = 'varchar(27)')group by column_type order by num;column_type group_concat(table_schema, '.', table_name) numvarchar(27) information_schema.COLUMNS 1varchar(7) information_schema.ROUTINES,information_schema.VIEWS 2varchar(20) information_schema.FILES,information_schema.FILES,information_schema.PLUGINS,information_schema.PLUGINS,information_schema.PLUGINS,information_schema.PROFILING 6create table t1(f1 char(1) not null, f2 char(9) not null)default character set utf8;select CHARACTER_MAXIMUM_LENGTH, CHARACTER_OCTET_LENGTH frominformation_schema.columns where table_schema='test' and table_name = 't1';CHARACTER_MAXIMUM_LENGTH CHARACTER_OCTET_LENGTH1 39 27drop table t1;use mysql;INSERT INTO `proc` VALUES ('test','','PROCEDURE','','SQL','CONTAINS_SQL','NO','DEFINER','','','BEGIN\r\n \r\nEND','root@%','2006-03-02 18:40:03','2006-03-02 18:40:03','','','utf8','utf8_general_ci','utf8_general_ci','n/a');select routine_name from information_schema.routines;routine_name
delete from proc where name='';use test;grant select on test.* to mysqltest_1@localhost;create table t1 (id int);create view v1 as select * from t1;create definer = mysqltest_1@localhostsql security definer view v2 as select 1;select * from information_schema.viewswhere table_name='v1' or table_name='v2';TABLE_CATALOG TABLE_SCHEMA TABLE_NAME VIEW_DEFINITION CHECK_OPTION IS_UPDATABLE DEFINER SECURITY_TYPE CHARACTER_SET_CLIENT COLLATION_CONNECTIONNULL test v1 NONE YES root@localhost DEFINER latin1 latin1_swedish_ciNULL test v2 select 1 AS `1` NONE NO mysqltest_1@localhost DEFINER latin1 latin1_swedish_cidrop view v1, v2;drop table t1;drop user mysqltest_1@localhost;set @a:= '.';create table t1(f1 char(5));create table t2(f1 char(5));select concat(@a, table_name), @a, table_namefrom information_schema.tables where table_schema = 'test';concat(@a, table_name) @a table_name.t1 . t1.t2 . t2drop table t1,t2;DROP PROCEDURE IF EXISTS p1;DROP FUNCTION IF EXISTS f1;CREATE PROCEDURE p1() SET @a= 1;CREATE FUNCTION f1() RETURNS INT RETURN @a + 1;CREATE USER mysql_bug20230@localhost;GRANT EXECUTE ON PROCEDURE p1 TO mysql_bug20230@localhost;GRANT EXECUTE ON FUNCTION f1 TO mysql_bug20230@localhost;SELECT ROUTINE_NAME, ROUTINE_DEFINITION FROM INFORMATION_SCHEMA.ROUTINES;ROUTINE_NAME ROUTINE_DEFINITIONf1 RETURN @a + 1p1 SET @a= 1SHOW CREATE PROCEDURE p1;Procedure sql_mode Create Procedure character_set_client collation_connection Database Collationp1 CREATE DEFINER=`root`@`localhost` PROCEDURE `p1`()SET @a= 1 latin1 latin1_swedish_ci latin1_swedish_ciSHOW CREATE FUNCTION f1;Function sql_mode Create Function character_set_client collation_connection Database Collationf1 CREATE DEFINER=`root`@`localhost` FUNCTION `f1`() RETURNS int(11)RETURN @a + 1 latin1 latin1_swedish_ci latin1_swedish_ciSELECT ROUTINE_NAME, ROUTINE_DEFINITION FROM INFORMATION_SCHEMA.ROUTINES;ROUTINE_NAME ROUTINE_DEFINITIONf1 NULLp1 NULLSHOW CREATE PROCEDURE p1;Procedure sql_mode Create Procedure character_set_client collation_connection Database Collationp1 NULL latin1 latin1_swedish_ci latin1_swedish_ciSHOW CREATE FUNCTION f1;Function sql_mode Create Function character_set_client collation_connection Database Collationf1 NULL latin1 latin1_swedish_ci latin1_swedish_ciCALL p1();SELECT f1();f1()2DROP FUNCTION f1;DROP PROCEDURE p1;DROP USER mysql_bug20230@localhost;SELECT t.table_name, c1.column_nameFROM information_schema.tables tINNER JOINinformation_schema.columns c1ON t.table_schema = c1.table_schema ANDt.table_name = c1.table_nameWHERE t.table_schema = 'information_schema' ANDc1.ordinal_position =( SELECT COALESCE(MIN(c2.ordinal_position),1)FROM information_schema.columns c2WHERE c2.table_schema = t.table_schema ANDc2.table_name = t.table_name ANDc2.column_name LIKE '%SCHEMA%' );table_name column_nameCHARACTER_SETS CHARACTER_SET_NAMECOLLATIONS COLLATION_NAMECOLLATION_CHARACTER_SET_APPLICABILITY COLLATION_NAMECOLUMNS TABLE_SCHEMACOLUMN_PRIVILEGES TABLE_SCHEMAENGINES ENGINEEVENTS EVENT_SCHEMAFILES TABLE_SCHEMAGLOBAL_STATUS VARIABLE_NAMEGLOBAL_VARIABLES VARIABLE_NAMEKEY_COLUMN_USAGE CONSTRAINT_SCHEMAPARTITIONS TABLE_SCHEMAPLUGINS PLUGIN_NAMEPROCESSLIST IDPROFILING QUERY_IDREFERENTIAL_CONSTRAINTS CONSTRAINT_SCHEMAROUTINES ROUTINE_SCHEMASCHEMATA SCHEMA_NAMESCHEMA_PRIVILEGES TABLE_SCHEMASESSION_STATUS VARIABLE_NAMESESSION_VARIABLES VARIABLE_NAMESTATISTICS TABLE_SCHEMATABLES TABLE_SCHEMATABLE_CONSTRAINTS CONSTRAINT_SCHEMATABLE_PRIVILEGES TABLE_SCHEMATRIGGERS TRIGGER_SCHEMAUSER_PRIVILEGES GRANTEEVIEWS TABLE_SCHEMASELECT t.table_name, c1.column_nameFROM information_schema.tables tINNER JOINinformation_schema.columns c1ON t.table_schema = c1.table_schema ANDt.table_name = c1.table_nameWHERE t.table_schema = 'information_schema' ANDc1.ordinal_position =( SELECT COALESCE(MIN(c2.ordinal_position),1)FROM information_schema.columns c2WHERE c2.table_schema = 'information_schema' ANDc2.table_name = t.table_name ANDc2.column_name LIKE '%SCHEMA%' );table_name column_nameCHARACTER_SETS CHARACTER_SET_NAMECOLLATIONS COLLATION_NAMECOLLATION_CHARACTER_SET_APPLICABILITY COLLATION_NAMECOLUMNS TABLE_SCHEMACOLUMN_PRIVILEGES TABLE_SCHEMAENGINES ENGINEEVENTS EVENT_SCHEMAFILES TABLE_SCHEMAGLOBAL_STATUS VARIABLE_NAMEGLOBAL_VARIABLES VARIABLE_NAMEKEY_COLUMN_USAGE CONSTRAINT_SCHEMAPARTITIONS TABLE_SCHEMAPLUGINS PLUGIN_NAMEPROCESSLIST IDPROFILING QUERY_IDREFERENTIAL_CONSTRAINTS CONSTRAINT_SCHEMAROUTINES ROUTINE_SCHEMASCHEMATA SCHEMA_NAMESCHEMA_PRIVILEGES TABLE_SCHEMASESSION_STATUS VARIABLE_NAMESESSION_VARIABLES VARIABLE_NAMESTATISTICS TABLE_SCHEMATABLES TABLE_SCHEMATABLE_CONSTRAINTS CONSTRAINT_SCHEMATABLE_PRIVILEGES TABLE_SCHEMATRIGGERS TRIGGER_SCHEMAUSER_PRIVILEGES GRANTEEVIEWS TABLE_SCHEMASELECT MAX(table_name) FROM information_schema.tables;MAX(table_name)VIEWSSELECT table_name from information_schema.tablesWHERE table_name=(SELECT MAX(table_name)FROM information_schema.tables);table_nameVIEWSDROP TABLE IF EXISTS bug23037;DROP FUNCTION IF EXISTS get_value;SELECT COLUMN_NAME, MD5(COLUMN_DEFAULT), LENGTH(COLUMN_DEFAULT) FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='bug23037';COLUMN_NAME MD5(COLUMN_DEFAULT) LENGTH(COLUMN_DEFAULT)fld1 7cf7a6782be951a1f2464a350da926a5 65532SELECT MD5(get_value());MD5(get_value())7cf7a6782be951a1f2464a350da926a5SELECT COLUMN_NAME, MD5(COLUMN_DEFAULT), LENGTH(COLUMN_DEFAULT), COLUMN_DEFAULT=get_value() FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='bug23037';COLUMN_NAME MD5(COLUMN_DEFAULT) LENGTH(COLUMN_DEFAULT) COLUMN_DEFAULT=get_value()fld1 7cf7a6782be951a1f2464a350da926a5 65532 1DROP TABLE bug23037;DROP FUNCTION get_value;create view v1 asselect table_schema as object_schema,table_name as object_name,table_type as object_typefrom information_schema.tablesorder by object_schema;explain select * from v1;id select_type table type possible_keys key key_len ref rows Extra1 SIMPLE tables ALL NULL NULL NULL NULL NULL Open_frm_only; Scanned all databases; Using filesortexplain select * from (select table_name from information_schema.tables) as a;id select_type table type possible_keys key key_len ref rows Extra1 PRIMARY <derived2> system NULL NULL NULL NULL 0 const row not found2 DERIVED tables ALL NULL NULL NULL NULL NULL Skip_open_table; Scanned all databasesdrop view v1;create table t1 (f1 int(11));create table t2 (f1 int(11), f2 int(11));select table_name from information_schema.tableswhere table_schema = 'test' and table_name not in(select table_name from information_schema.columnswhere table_schema = 'test' and column_name = 'f3');table_namet1t2drop table t1,t2;select 1 as f1 from information_schema.tables where "CHARACTER_SETS"=(select cast(table_name as char) from information_schema.tablesorder by table_name limit 1) limit 1;f11select t.table_name, group_concat(t.table_schema, '.', t.table_name),count(*) as num1from information_schema.tables tinner join information_schema.columns c1on t.table_schema = c1.table_schema AND t.table_name = c1.table_namewhere t.table_schema = 'information_schema' andc1.ordinal_position =(select isnull(c2.column_type) -isnull(group_concat(c2.table_schema, '.', c2.table_name)) +count(*) as numfrom information_schema.columns c2 wherec2.table_schema='information_schema' and(c2.column_type = 'varchar(7)' or c2.column_type = 'varchar(20)')group by c2.column_type order by num limit 1)group by t.table_name order by num1, t.table_name;table_name group_concat(t.table_schema, '.', t.table_name) num1CHARACTER_SETS information_schema.CHARACTER_SETS 1COLLATIONS information_schema.COLLATIONS 1COLLATION_CHARACTER_SET_APPLICABILITY information_schema.COLLATION_CHARACTER_SET_APPLICABILITY 1COLUMNS information_schema.COLUMNS 1COLUMN_PRIVILEGES information_schema.COLUMN_PRIVILEGES 1ENGINES information_schema.ENGINES 1EVENTS information_schema.EVENTS 1FILES information_schema.FILES 1GLOBAL_STATUS information_schema.GLOBAL_STATUS 1GLOBAL_VARIABLES information_schema.GLOBAL_VARIABLES 1KEY_COLUMN_USAGE information_schema.KEY_COLUMN_USAGE 1PARTITIONS information_schema.PARTITIONS 1PLUGINS information_schema.PLUGINS 1PROCESSLIST information_schema.PROCESSLIST 1PROFILING information_schema.PROFILING 1REFERENTIAL_CONSTRAINTS information_schema.REFERENTIAL_CONSTRAINTS 1ROUTINES information_schema.ROUTINES 1SCHEMATA information_schema.SCHEMATA 1SCHEMA_PRIVILEGES information_schema.SCHEMA_PRIVILEGES 1SESSION_STATUS information_schema.SESSION_STATUS 1SESSION_VARIABLES information_schema.SESSION_VARIABLES 1STATISTICS information_schema.STATISTICS 1TABLES information_schema.TABLES 1TABLE_CONSTRAINTS information_schema.TABLE_CONSTRAINTS 1TABLE_PRIVILEGES information_schema.TABLE_PRIVILEGES 1TRIGGERS information_schema.TRIGGERS 1USER_PRIVILEGES information_schema.USER_PRIVILEGES 1VIEWS information_schema.VIEWS 1create table t1(f1 int);create view v1 as select f1+1 as a from t1;create table t2 (f1 int, f2 int);create view v2 as select f1+1 as a, f2 as b from t2;select table_name, is_updatable from information_schema.views;table_name is_updatablev1 NOv2 YESdelete from v1;drop view v1,v2;drop table t1,t2;alter database;ERROR 42000: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1alter database test;ERROR 42000: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1create database mysqltest;create table mysqltest.t1(a int, b int, c int);create trigger mysqltest.t1_ai after insert on mysqltest.t1for each row set @a = new.a + new.b + new.c;grant select(b) on mysqltest.t1 to mysqltest_1@localhost;select trigger_name from information_schema.triggerswhere event_object_table='t1';trigger_namet1_aishow triggers from mysqltest;Trigger Event Table Statement Timing Created sql_mode Definer character_set_client collation_connection Database Collationt1_ai INSERT t1 set @a = new.a + new.b + new.c AFTER NULL root@localhost latin1 latin1_swedish_ci latin1_swedish_cishow columns from t1;Field Type Null Key Default Extrab int(11) YES NULL select column_name from information_schema.columns where table_name='t1';column_namebshow triggers;Trigger Event Table Statement Timing Created sql_mode Definer character_set_client collation_connection Database Collationselect trigger_name from information_schema.triggerswhere event_object_table='t1';trigger_namedrop user mysqltest_1@localhost;drop database mysqltest;create table t1 (f1 varchar(50),f2 varchar(50) not null,f3 varchar(50) default '',f4 varchar(50) default NULL,f5 bigint not null,f6 bigint not null default 10,f7 datetime not null,f8 datetime default '2006-01-01');select column_default from information_schema.columns where table_name= 't1';column_defaultNULLNULL
NULLNULL10NULL2006-01-01 00:00:00show columns from t1;Field Type Null Key Default Extraf1 varchar(50) YES NULL f2 varchar(50) NO NULL f3 varchar(50) YES f4 varchar(50) YES NULL f5 bigint(20) NO NULL f6 bigint(20) NO 10 f7 datetime NO NULL f8 datetime YES 2006-01-01 00:00:00 drop table t1;show fields from information_schema.table_names;ERROR 42S02: Unknown table 'table_names' in information_schemashow keys from information_schema.table_names;ERROR 42S02: Unknown table 'table_names' in information_schemaUSE information_schema;SET max_heap_table_size = 16384;CREATE TABLE test.t1( a INT );SELECT *FROM tables taJOIN collations co ON ( co.collation_name = ta.table_catalog )JOIN character_sets cs ON ( cs.character_set_name = ta.table_catalog );TABLE_CATALOG TABLE_SCHEMA TABLE_NAME TABLE_TYPE ENGINE VERSION ROW_FORMAT TABLE_ROWS AVG_ROW_LENGTH DATA_LENGTH MAX_DATA_LENGTH INDEX_LENGTH DATA_FREE AUTO_INCREMENT CREATE_TIME UPDATE_TIME CHECK_TIME TABLE_COLLATION CHECKSUM CREATE_OPTIONS TABLE_COMMENT COLLATION_NAME CHARACTER_SET_NAME ID IS_DEFAULT IS_COMPILED SORTLEN CHARACTER_SET_NAME DEFAULT_COLLATE_NAME DESCRIPTION MAXLENDROP TABLE test.t1;SET max_heap_table_size = DEFAULT;USE test;End of 5.0 tests.select * from information_schema.engines WHERE ENGINE="MyISAM";ENGINE SUPPORT COMMENT TRANSACTIONS XA SAVEPOINTSMyISAM DEFAULT Default engine as of MySQL 3.23 with great performance NO NO NOgrant select on *.* to user3148@localhost;select user,db from information_schema.processlist;user dbuser3148 testdrop user user3148@localhost;DROP TABLE IF EXISTS server_status;DROP EVENT IF EXISTS event_status;SET GLOBAL event_scheduler=1;CREATE EVENT event_statusON SCHEDULE AT NOW()ON COMPLETION NOT PRESERVEDOBEGINCREATE TABLE server_statusSELECT variable_nameFROM information_schema.global_statusWHERE variable_name LIKE 'ABORTED_CONNECTS' ORvariable_name LIKE 'BINLOG_CACHE_DISK_USE';END$$SELECT variable_name FROM server_status;variable_nameABORTED_CONNECTSBINLOG_CACHE_DISK_USEDROP TABLE server_status;SET GLOBAL event_scheduler=0;explain select table_name from information_schema.views wheretable_schema='test' and table_name='v1';id select_type table type possible_keys key key_len ref rows Extra1 SIMPLE views ALL NULL TABLE_SCHEMA,TABLE_NAME NULL NULL NULL Using where; Open_frm_only; Scanned 0 databasesexplain select * from information_schema.tables;id select_type table type possible_keys key key_len ref rows Extra1 SIMPLE tables ALL NULL NULL NULL NULL NULL Open_full_table; Scanned all databasesexplain select * from information_schema.collations;id select_type table type possible_keys key key_len ref rows Extra1 SIMPLE collations ALL NULL NULL NULL NULL NULL explain select * from information_schema.tables wheretable_schema='test' and table_name= 't1';id select_type table type possible_keys key key_len ref rows Extra1 SIMPLE tables ALL NULL TABLE_SCHEMA,TABLE_NAME NULL NULL NULL Using where; Open_full_table; Scanned 0 databasesexplain select table_name, table_type from information_schema.tableswhere table_schema='test';id select_type table type possible_keys key key_len ref rows Extra1 SIMPLE tables ALL NULL TABLE_SCHEMA NULL NULL NULL Using where; Open_frm_only; Scanned 1 databaseexplain select b.table_namefrom information_schema.tables a, information_schema.columns bwhere a.table_name='t1' and a.table_schema='test' and b.table_name=a.table_name;id select_type table type possible_keys key key_len ref rows Extra1 SIMPLE a ALL NULL TABLE_SCHEMA,TABLE_NAME NULL NULL NULL Using where; Skip_open_table; Scanned 0 databases1 SIMPLE b ALL NULL NULL NULL NULL NULL Using where; Open_frm_only; Scanned all databases; Using join bufferSELECT * FROM INFORMATION_SCHEMA.SCHEMATAWHERE SCHEMA_NAME = 'mysqltest';CATALOG_NAME SCHEMA_NAME DEFAULT_CHARACTER_SET_NAME DEFAULT_COLLATION_NAME SQL_PATHSELECT * FROM INFORMATION_SCHEMA.SCHEMATAWHERE SCHEMA_NAME = '';CATALOG_NAME SCHEMA_NAME DEFAULT_CHARACTER_SET_NAME DEFAULT_COLLATION_NAME SQL_PATHSELECT * FROM INFORMATION_SCHEMA.SCHEMATAWHERE SCHEMA_NAME = 'test';CATALOG_NAME SCHEMA_NAME DEFAULT_CHARACTER_SET_NAME DEFAULT_COLLATION_NAME SQL_PATHNULL test latin1 latin1_swedish_ci NULLselect count(*) from INFORMATION_SCHEMA.TABLES where TABLE_SCHEMA='mysql' AND TABLE_NAME='nonexisting';count(*)0select count(*) from INFORMATION_SCHEMA.TABLES where TABLE_SCHEMA='mysql' AND TABLE_NAME='';count(*)0select count(*) from INFORMATION_SCHEMA.TABLES where TABLE_SCHEMA='' AND TABLE_NAME='';count(*)0select count(*) from INFORMATION_SCHEMA.TABLES where TABLE_SCHEMA='' AND TABLE_NAME='nonexisting';count(*)0CREATE VIEW v1AS SELECT *FROM information_schema.tables;SELECT VIEW_DEFINITION FROM INFORMATION_SCHEMA.VIEWS where TABLE_NAME = 'v1';VIEW_DEFINITIONselect `tables`.`TABLE_CATALOG` AS `TABLE_CATALOG`,`tables`.`TABLE_SCHEMA` AS `TABLE_SCHEMA`,`tables`.`TABLE_NAME` AS `TABLE_NAME`,`tables`.`TABLE_TYPE` AS `TABLE_TYPE`,`tables`.`ENGINE` AS `ENGINE`,`tables`.`VERSION` AS `VERSION`,`tables`.`ROW_FORMAT` AS `ROW_FORMAT`,`tables`.`TABLE_ROWS` AS `TABLE_ROWS`,`tables`.`AVG_ROW_LENGTH` AS `AVG_ROW_LENGTH`,`tables`.`DATA_LENGTH` AS `DATA_LENGTH`,`tables`.`MAX_DATA_LENGTH` AS `MAX_DATA_LENGTH`,`tables`.`INDEX_LENGTH` AS `INDEX_LENGTH`,`tables`.`DATA_FREE` AS `DATA_FREE`,`tables`.`AUTO_INCREMENT` AS `AUTO_INCREMENT`,`tables`.`CREATE_TIME` AS `CREATE_TIME`,`tables`.`UPDATE_TIME` AS `UPDATE_TIME`,`tables`.`CHECK_TIME` AS `CHECK_TIME`,`tables`.`TABLE_COLLATION` AS `TABLE_COLLATION`,`tables`.`CHECKSUM` AS `CHECKSUM`,`tables`.`CREATE_OPTIONS` AS `CREATE_OPTIONS`,`tables`.`TABLE_COMMENT` AS `TABLE_COMMENT` from `information_schema`.`tables`DROP VIEW v1;SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATAWHERE SCHEMA_NAME ='information_schema';SCHEMA_NAMEinformation_schemaSELECT TABLE_COLLATION FROM INFORMATION_SCHEMA.TABLESWHERE TABLE_SCHEMA='mysql' and TABLE_NAME= 'db';TABLE_COLLATIONutf8_binselect * from information_schema.columns where table_schema = NULL;TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME ORDINAL_POSITION COLUMN_DEFAULT IS_NULLABLE DATA_TYPE CHARACTER_MAXIMUM_LENGTH CHARACTER_OCTET_LENGTH NUMERIC_PRECISION NUMERIC_SCALE CHARACTER_SET_NAME COLLATION_NAME COLUMN_TYPE COLUMN_KEY EXTRA PRIVILEGES COLUMN_COMMENTselect * from `information_schema`.`COLUMNS` where `TABLE_NAME` = NULL;TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME ORDINAL_POSITION COLUMN_DEFAULT IS_NULLABLE DATA_TYPE CHARACTER_MAXIMUM_LENGTH CHARACTER_OCTET_LENGTH NUMERIC_PRECISION NUMERIC_SCALE CHARACTER_SET_NAME COLLATION_NAME COLUMN_TYPE COLUMN_KEY EXTRA PRIVILEGES COLUMN_COMMENTselect * from `information_schema`.`KEY_COLUMN_USAGE` where `TABLE_SCHEMA` = NULL;CONSTRAINT_CATALOG CONSTRAINT_SCHEMA CONSTRAINT_NAME TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME ORDINAL_POSITION POSITION_IN_UNIQUE_CONSTRAINT REFERENCED_TABLE_SCHEMA REFERENCED_TABLE_NAME REFERENCED_COLUMN_NAMEselect * from `information_schema`.`KEY_COLUMN_USAGE` where `TABLE_NAME` = NULL;CONSTRAINT_CATALOG CONSTRAINT_SCHEMA CONSTRAINT_NAME TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME ORDINAL_POSITION POSITION_IN_UNIQUE_CONSTRAINT REFERENCED_TABLE_SCHEMA REFERENCED_TABLE_NAME REFERENCED_COLUMN_NAMEselect * from `information_schema`.`PARTITIONS` where `TABLE_SCHEMA` = NULL;TABLE_CATALOG TABLE_SCHEMA TABLE_NAME PARTITION_NAME SUBPARTITION_NAME PARTITION_ORDINAL_POSITION SUBPARTITION_ORDINAL_POSITION PARTITION_METHOD SUBPARTITION_METHOD PARTITION_EXPRESSION SUBPARTITION_EXPRESSION PARTITION_DESCRIPTION TABLE_ROWS AVG_ROW_LENGTH DATA_LENGTH MAX_DATA_LENGTH INDEX_LENGTH DATA_FREE CREATE_TIME UPDATE_TIME CHECK_TIME CHECKSUM PARTITION_COMMENT NODEGROUP TABLESPACE_NAMEselect * from `information_schema`.`PARTITIONS` where `TABLE_NAME` = NULL;TABLE_CATALOG TABLE_SCHEMA TABLE_NAME PARTITION_NAME SUBPARTITION_NAME PARTITION_ORDINAL_POSITION SUBPARTITION_ORDINAL_POSITION PARTITION_METHOD SUBPARTITION_METHOD PARTITION_EXPRESSION SUBPARTITION_EXPRESSION PARTITION_DESCRIPTION TABLE_ROWS AVG_ROW_LENGTH DATA_LENGTH MAX_DATA_LENGTH INDEX_LENGTH DATA_FREE CREATE_TIME UPDATE_TIME CHECK_TIME CHECKSUM PARTITION_COMMENT NODEGROUP TABLESPACE_NAMEselect * from `information_schema`.`REFERENTIAL_CONSTRAINTS` where `CONSTRAINT_SCHEMA` = NULL;CONSTRAINT_CATALOG CONSTRAINT_SCHEMA CONSTRAINT_NAME UNIQUE_CONSTRAINT_CATALOG UNIQUE_CONSTRAINT_SCHEMA UNIQUE_CONSTRAINT_NAME MATCH_OPTION UPDATE_RULE DELETE_RULE TABLE_NAME REFERENCED_TABLE_NAMEselect * from `information_schema`.`REFERENTIAL_CONSTRAINTS` where `TABLE_NAME` = NULL;CONSTRAINT_CATALOG CONSTRAINT_SCHEMA CONSTRAINT_NAME UNIQUE_CONSTRAINT_CATALOG UNIQUE_CONSTRAINT_SCHEMA UNIQUE_CONSTRAINT_NAME MATCH_OPTION UPDATE_RULE DELETE_RULE TABLE_NAME REFERENCED_TABLE_NAMEselect * from information_schema.schemata where schema_name = NULL;CATALOG_NAME SCHEMA_NAME DEFAULT_CHARACTER_SET_NAME DEFAULT_COLLATION_NAME SQL_PATHselect * from `information_schema`.`STATISTICS` where `TABLE_SCHEMA` = NULL;TABLE_CATALOG TABLE_SCHEMA TABLE_NAME NON_UNIQUE INDEX_SCHEMA INDEX_NAME SEQ_IN_INDEX COLUMN_NAME COLLATION CARDINALITY SUB_PART PACKED NULLABLE INDEX_TYPE COMMENTselect * from `information_schema`.`STATISTICS` where `TABLE_NAME` = NULL;TABLE_CATALOG TABLE_SCHEMA TABLE_NAME NON_UNIQUE INDEX_SCHEMA INDEX_NAME SEQ_IN_INDEX COLUMN_NAME COLLATION CARDINALITY SUB_PART PACKED NULLABLE INDEX_TYPE COMMENTselect * from information_schema.tables where table_schema = NULL;TABLE_CATALOG TABLE_SCHEMA TABLE_NAME TABLE_TYPE ENGINE VERSION ROW_FORMAT TABLE_ROWS AVG_ROW_LENGTH DATA_LENGTH MAX_DATA_LENGTH INDEX_LENGTH DATA_FREE AUTO_INCREMENT CREATE_TIME UPDATE_TIME CHECK_TIME TABLE_COLLATION CHECKSUM CREATE_OPTIONS TABLE_COMMENTselect * from information_schema.tables where table_catalog = NULL;TABLE_CATALOG TABLE_SCHEMA TABLE_NAME TABLE_TYPE ENGINE VERSION ROW_FORMAT TABLE_ROWS AVG_ROW_LENGTH DATA_LENGTH MAX_DATA_LENGTH INDEX_LENGTH DATA_FREE AUTO_INCREMENT CREATE_TIME UPDATE_TIME CHECK_TIME TABLE_COLLATION CHECKSUM CREATE_OPTIONS TABLE_COMMENTselect * from information_schema.tables where table_name = NULL;TABLE_CATALOG TABLE_SCHEMA TABLE_NAME TABLE_TYPE ENGINE VERSION ROW_FORMAT TABLE_ROWS AVG_ROW_LENGTH DATA_LENGTH MAX_DATA_LENGTH INDEX_LENGTH DATA_FREE AUTO_INCREMENT CREATE_TIME UPDATE_TIME CHECK_TIME TABLE_COLLATION CHECKSUM CREATE_OPTIONS TABLE_COMMENTselect * from `information_schema`.`TABLE_CONSTRAINTS` where `TABLE_SCHEMA` = NULL;CONSTRAINT_CATALOG CONSTRAINT_SCHEMA CONSTRAINT_NAME TABLE_SCHEMA TABLE_NAME CONSTRAINT_TYPEselect * from `information_schema`.`TABLE_CONSTRAINTS` where `TABLE_NAME` = NULL;CONSTRAINT_CATALOG CONSTRAINT_SCHEMA CONSTRAINT_NAME TABLE_SCHEMA TABLE_NAME CONSTRAINT_TYPEselect * from `information_schema`.`TRIGGERS` where `EVENT_OBJECT_SCHEMA` = NULL;TRIGGER_CATALOG TRIGGER_SCHEMA TRIGGER_NAME EVENT_MANIPULATION EVENT_OBJECT_CATALOG EVENT_OBJECT_SCHEMA EVENT_OBJECT_TABLE ACTION_ORDER ACTION_CONDITION ACTION_STATEMENT ACTION_ORIENTATION ACTION_TIMING ACTION_REFERENCE_OLD_TABLE ACTION_REFERENCE_NEW_TABLE ACTION_REFERENCE_OLD_ROW ACTION_REFERENCE_NEW_ROW CREATED SQL_MODE DEFINER CHARACTER_SET_CLIENT COLLATION_CONNECTION DATABASE_COLLATIONselect * from `information_schema`.`TRIGGERS` where `EVENT_OBJECT_TABLE` = NULL;TRIGGER_CATALOG TRIGGER_SCHEMA TRIGGER_NAME EVENT_MANIPULATION EVENT_OBJECT_CATALOG EVENT_OBJECT_SCHEMA EVENT_OBJECT_TABLE ACTION_ORDER ACTION_CONDITION ACTION_STATEMENT ACTION_ORIENTATION ACTION_TIMING ACTION_REFERENCE_OLD_TABLE ACTION_REFERENCE_NEW_TABLE ACTION_REFERENCE_OLD_ROW ACTION_REFERENCE_NEW_ROW CREATED SQL_MODE DEFINER CHARACTER_SET_CLIENT COLLATION_CONNECTION DATABASE_COLLATIONselect * from `information_schema`.`VIEWS` where `TABLE_SCHEMA` = NULL;TABLE_CATALOG TABLE_SCHEMA TABLE_NAME VIEW_DEFINITION CHECK_OPTION IS_UPDATABLE DEFINER SECURITY_TYPE CHARACTER_SET_CLIENT COLLATION_CONNECTIONselect * from `information_schema`.`VIEWS` where `TABLE_NAME` = NULL;TABLE_CATALOG TABLE_SCHEMA TABLE_NAME VIEW_DEFINITION CHECK_OPTION IS_UPDATABLE DEFINER SECURITY_TYPE CHARACTER_SET_CLIENT COLLATION_CONNECTIONexplain extended select 1 from information_schema.tables;id select_type table type possible_keys key key_len ref rows filtered Extra1 SIMPLE tables ALL NULL NULL NULL NULL NULL NULL Skip_open_table; Scanned all databasesWarnings:Note 1003 select 1 AS `1` from `information_schema`.`tables`use information_schema;show events;Db Name Definer Time zone Type Execute at Interval value Interval field Starts Ends Status Originator character_set_client collation_connection Database Collationshow events from information_schema;Db Name Definer Time zone Type Execute at Interval value Interval field Starts Ends Status Originator character_set_client collation_connection Database Collationshow events where Db= 'information_schema';Db Name Definer Time zone Type Execute at Interval value Interval field Starts Ends Status Originator character_set_client collation_connection Database Collationuse test;## Bug#34166: Server crash in SHOW OPEN TABLES and prelocking#drop table if exists t1;drop function if exists f1;create table t1 (a int);create function f1() returns intbegininsert into t1 (a) values (1);return 0;end|show open tables where f1()=0;show open tables where f1()=0;drop table t1;drop function f1;select * from information_schema.tables where 1=sleep(100000);select * from information_schema.columns where 1=sleep(100000);explain select count(*) from information_schema.tables;id select_type table type possible_keys key key_len ref rows Extra1 SIMPLE tables ALL NULL NULL NULL NULL NULL Skip_open_table; Scanned all databasesexplain select count(*) from information_schema.columns;id select_type table type possible_keys key key_len ref rows Extra1 SIMPLE columns ALL NULL NULL NULL NULL NULL Open_frm_only; Scanned all databasesexplain select count(*) from information_schema.views;id select_type table type possible_keys key key_len ref rows Extra1 SIMPLE views ALL NULL NULL NULL NULL NULL Open_frm_only; Scanned all databasesEnd of 5.1 tests.
|