You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

1654 lines
68 KiB

fix for bug#16642 (Events: No INFORMATION_SCHEMA.EVENTS table) post-review change - use pointer instead of copy on the stack. WL#1034 (Internal CRON) This patch adds INFORMATION_SCHEMA.EVENTS table with the following format: EVENT_CATALOG - MYSQL_TYPE_STRING (Always NULL) EVENT_SCHEMA - MYSQL_TYPE_STRING (the database) EVENT_NAME - MYSQL_TYPE_STRING (the name) DEFINER - MYSQL_TYPE_STRING (user@host) EVENT_BODY - MYSQL_TYPE_STRING (the body from mysql.event) EVENT_TYPE - MYSQL_TYPE_STRING ("ONE TIME" | "RECURRING") EXECUTE_AT - MYSQL_TYPE_TIMESTAMP (set for "ONE TIME" otherwise NULL) INTERVAL_VALUE - MYSQL_TYPE_LONG (set for RECURRING otherwise NULL) INTERVAL_FIELD - MYSQL_TYPE_STRING (set for RECURRING otherwise NULL) SQL_MODE - MYSQL_TYPE_STRING (for now NULL) STARTS - MYSQL_TYPE_TIMESTAMP (starts from mysql.event) ENDS - MYSQL_TYPE_TIMESTAMP (ends from mysql.event) STATUS - MYSQL_TYPE_STRING (ENABLED | DISABLED) ON_COMPLETION - MYSQL_TYPE_STRING (NOT PRESERVE | PRESERVE) CREATED - MYSQL_TYPE_TIMESTAMP LAST_ALTERED - MYSQL_TYPE_TIMESTAMP LAST_EXECUTED - MYSQL_TYPE_TIMESTAMP EVENT_COMMENT - MYSQL_TYPE_STRING SQL_MODE is NULL for now, because the value is still not stored in mysql.event . Support will be added as a fix for another bug. This patch also adds SHOW [FULL] EVENTS [FROM db] [LIKE pattern] 1. SHOW EVENTS shows always only the events on the same user, because the PK of mysql.event is (definer, db, name) several users may have event with the same name -> no information disclosure. 2. SHOW FULL EVENTS - shows the events (in the current db as SHOW EVENTS) of all users. The user has to have PROCESS privilege, if not then SHOW FULL EVENTS behave like SHOW EVENTS. 3. If [FROM db] is specified then this db is considered. 4. Event names can be filtered with LIKE pattern. SHOW EVENTS returns table with the following columns, which are subset of the data which is returned by SELECT * FROM I_S.EVENTS Db Name Definer Type Execute at Interval value Interval field Starts Ends Status
20 years ago
Prevent bugs by making DBUG_* expressions syntactically equivalent to a single statement. --- Bug#24795: SHOW PROFILE Profiling is only partially functional on some architectures. Where there is no getrusage() system call, presently Null values are returned where it would be required. Notably, Windows needs some love applied to make it as useful. Syntax this adds: SHOW PROFILES SHOW PROFILE [types] [FOR QUERY n] [OFFSET n] [LIMIT n] where "n" is an integer and "types" is zero or many (comma-separated) of "CPU" "MEMORY" (not presently supported) "BLOCK IO" "CONTEXT SWITCHES" "PAGE FAULTS" "IPC" "SWAPS" "SOURCE" "ALL" It also adds a session variable (boolean) "profiling", set to "no" by default, and (integer) profiling_history_size, set to 15 by default. This patch abstracts setting THDs' "proc_info" behind a macro that can be used as a hook into the profiling code when profiling support is compiled in. All future code in this line should use that mechanism for setting thd->proc_info. --- Tests are now set to omit the statistics. --- Adds an Information_schema table, "profiling" for access to "show profile" data. --- Merge zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-community-3--bug24795 into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-community --- Fix merge problems. --- Fixed one bug in the query_source being NULL. Updated test results. --- Include more thorough profiling tests. Improve support for prepared statements. Use session-specific query IDs, starting at zero. --- Selecting from I_S.profiling is no longer quashed in profiling, as requested by Giuseppe. Limit the size of captured query text. No longer log queries that are zero length.
19 years ago
21 years ago
21 years ago
21 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
21 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
19 years ago
fix for bug#16642 (Events: No INFORMATION_SCHEMA.EVENTS table) post-review change - use pointer instead of copy on the stack. WL#1034 (Internal CRON) This patch adds INFORMATION_SCHEMA.EVENTS table with the following format: EVENT_CATALOG - MYSQL_TYPE_STRING (Always NULL) EVENT_SCHEMA - MYSQL_TYPE_STRING (the database) EVENT_NAME - MYSQL_TYPE_STRING (the name) DEFINER - MYSQL_TYPE_STRING (user@host) EVENT_BODY - MYSQL_TYPE_STRING (the body from mysql.event) EVENT_TYPE - MYSQL_TYPE_STRING ("ONE TIME" | "RECURRING") EXECUTE_AT - MYSQL_TYPE_TIMESTAMP (set for "ONE TIME" otherwise NULL) INTERVAL_VALUE - MYSQL_TYPE_LONG (set for RECURRING otherwise NULL) INTERVAL_FIELD - MYSQL_TYPE_STRING (set for RECURRING otherwise NULL) SQL_MODE - MYSQL_TYPE_STRING (for now NULL) STARTS - MYSQL_TYPE_TIMESTAMP (starts from mysql.event) ENDS - MYSQL_TYPE_TIMESTAMP (ends from mysql.event) STATUS - MYSQL_TYPE_STRING (ENABLED | DISABLED) ON_COMPLETION - MYSQL_TYPE_STRING (NOT PRESERVE | PRESERVE) CREATED - MYSQL_TYPE_TIMESTAMP LAST_ALTERED - MYSQL_TYPE_TIMESTAMP LAST_EXECUTED - MYSQL_TYPE_TIMESTAMP EVENT_COMMENT - MYSQL_TYPE_STRING SQL_MODE is NULL for now, because the value is still not stored in mysql.event . Support will be added as a fix for another bug. This patch also adds SHOW [FULL] EVENTS [FROM db] [LIKE pattern] 1. SHOW EVENTS shows always only the events on the same user, because the PK of mysql.event is (definer, db, name) several users may have event with the same name -> no information disclosure. 2. SHOW FULL EVENTS - shows the events (in the current db as SHOW EVENTS) of all users. The user has to have PROCESS privilege, if not then SHOW FULL EVENTS behave like SHOW EVENTS. 3. If [FROM db] is specified then this db is considered. 4. Event names can be filtered with LIKE pattern. SHOW EVENTS returns table with the following columns, which are subset of the data which is returned by SELECT * FROM I_S.EVENTS Db Name Definer Type Execute at Interval value Interval field Starts Ends Status
20 years ago
21 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
20 years ago
20 years ago
20 years ago
20 years ago
20 years ago
20 years ago
19 years ago
19 years ago
19 years ago
19 years ago
20 years ago
20 years ago
18 years ago
  1. DROP TABLE IF EXISTS t0,t1,t2,t3,t4,t5;
  2. DROP VIEW IF EXISTS v1;
  3. show variables where variable_name like "skip_show_database";
  4. Variable_name Value
  5. skip_show_database OFF
  6. grant select, update, execute on test.* to mysqltest_2@localhost;
  7. grant select, update on test.* to mysqltest_1@localhost;
  8. create user mysqltest_3@localhost;
  9. create user mysqltest_3;
  10. select * from information_schema.SCHEMATA where schema_name > 'm';
  11. CATALOG_NAME SCHEMA_NAME DEFAULT_CHARACTER_SET_NAME DEFAULT_COLLATION_NAME SQL_PATH
  12. NULL mysql latin1 latin1_swedish_ci NULL
  13. NULL test latin1 latin1_swedish_ci NULL
  14. select schema_name from information_schema.schemata;
  15. schema_name
  16. information_schema
  17. mysql
  18. test
  19. show databases like 't%';
  20. Database (t%)
  21. test
  22. show databases;
  23. Database
  24. information_schema
  25. mysql
  26. test
  27. show databases where `database` = 't%';
  28. Database
  29. create database mysqltest;
  30. create table mysqltest.t1(a int, b VARCHAR(30), KEY string_data (b));
  31. create table test.t2(a int);
  32. create table t3(a int, KEY a_data (a));
  33. create table mysqltest.t4(a int);
  34. create table t5 (id int auto_increment primary key);
  35. insert into t5 values (10);
  36. create view v1 (c) as select table_name from information_schema.TABLES where table_name<>'ndb_binlog_index' AND table_name<>'ndb_apply_status';
  37. select * from v1;
  38. c
  39. CHARACTER_SETS
  40. COLLATIONS
  41. COLLATION_CHARACTER_SET_APPLICABILITY
  42. COLUMNS
  43. COLUMN_PRIVILEGES
  44. ENGINES
  45. EVENTS
  46. FILES
  47. GLOBAL_STATUS
  48. GLOBAL_VARIABLES
  49. KEY_COLUMN_USAGE
  50. PARTITIONS
  51. PLUGINS
  52. PROCESSLIST
  53. PROFILING
  54. REFERENTIAL_CONSTRAINTS
  55. ROUTINES
  56. SCHEMATA
  57. SCHEMA_PRIVILEGES
  58. SESSION_STATUS
  59. SESSION_VARIABLES
  60. STATISTICS
  61. TABLES
  62. TABLE_CONSTRAINTS
  63. TABLE_PRIVILEGES
  64. TRIGGERS
  65. USER_PRIVILEGES
  66. VIEWS
  67. columns_priv
  68. db
  69. event
  70. func
  71. general_log
  72. help_category
  73. help_keyword
  74. help_relation
  75. help_topic
  76. host
  77. plugin
  78. proc
  79. procs_priv
  80. servers
  81. slow_log
  82. tables_priv
  83. time_zone
  84. time_zone_leap_second
  85. time_zone_name
  86. time_zone_transition
  87. time_zone_transition_type
  88. user
  89. t1
  90. t4
  91. t2
  92. t3
  93. t5
  94. v1
  95. select c,table_name from v1
  96. inner join information_schema.TABLES v2 on (v1.c=v2.table_name)
  97. where v1.c like "t%";
  98. c table_name
  99. TABLES TABLES
  100. TABLE_CONSTRAINTS TABLE_CONSTRAINTS
  101. TABLE_PRIVILEGES TABLE_PRIVILEGES
  102. TRIGGERS TRIGGERS
  103. tables_priv tables_priv
  104. time_zone time_zone
  105. time_zone_leap_second time_zone_leap_second
  106. time_zone_name time_zone_name
  107. time_zone_transition time_zone_transition
  108. time_zone_transition_type time_zone_transition_type
  109. t1 t1
  110. t4 t4
  111. t2 t2
  112. t3 t3
  113. t5 t5
  114. select c,table_name from v1
  115. left join information_schema.TABLES v2 on (v1.c=v2.table_name)
  116. where v1.c like "t%";
  117. c table_name
  118. TABLES TABLES
  119. TABLE_CONSTRAINTS TABLE_CONSTRAINTS
  120. TABLE_PRIVILEGES TABLE_PRIVILEGES
  121. TRIGGERS TRIGGERS
  122. tables_priv tables_priv
  123. time_zone time_zone
  124. time_zone_leap_second time_zone_leap_second
  125. time_zone_name time_zone_name
  126. time_zone_transition time_zone_transition
  127. time_zone_transition_type time_zone_transition_type
  128. t1 t1
  129. t4 t4
  130. t2 t2
  131. t3 t3
  132. t5 t5
  133. select c, v2.table_name from v1
  134. right join information_schema.TABLES v2 on (v1.c=v2.table_name)
  135. where v1.c like "t%";
  136. c table_name
  137. TABLES TABLES
  138. TABLE_CONSTRAINTS TABLE_CONSTRAINTS
  139. TABLE_PRIVILEGES TABLE_PRIVILEGES
  140. TRIGGERS TRIGGERS
  141. tables_priv tables_priv
  142. time_zone time_zone
  143. time_zone_leap_second time_zone_leap_second
  144. time_zone_name time_zone_name
  145. time_zone_transition time_zone_transition
  146. time_zone_transition_type time_zone_transition_type
  147. t1 t1
  148. t4 t4
  149. t2 t2
  150. t3 t3
  151. t5 t5
  152. select table_name from information_schema.TABLES
  153. where table_schema = "mysqltest" and table_name like "t%";
  154. table_name
  155. t1
  156. t4
  157. select * from information_schema.STATISTICS where TABLE_SCHEMA = "mysqltest";
  158. 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 COMMENT
  159. NULL mysqltest t1 1 mysqltest string_data 1 b A NULL NULL NULL YES BTREE
  160. show keys from t3 where Key_name = "a_data";
  161. Table Non_unique Key_name Seq_in_index Column_name Collation Cardinality Sub_part Packed Null Index_type Comment
  162. t3 1 a_data 1 a A NULL NULL NULL YES BTREE
  163. show tables like 't%';
  164. Tables_in_test (t%)
  165. t2
  166. t3
  167. t5
  168. show table status;
  169. 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 Comment
  170. t2 MyISAM 10 Fixed 0 0 0 # 1024 0 NULL # # NULL latin1_swedish_ci NULL
  171. t3 MyISAM 10 Fixed 0 0 0 # 1024 0 NULL # # NULL latin1_swedish_ci NULL
  172. t5 MyISAM 10 Fixed 1 7 7 # 2048 0 11 # # NULL latin1_swedish_ci NULL
  173. v1 NULL NULL NULL NULL NULL NULL # NULL NULL NULL # # NULL NULL NULL NULL VIEW
  174. show full columns from t3 like "a%";
  175. Field Type Collation Null Key Default Extra Privileges Comment
  176. a int(11) NULL YES MUL NULL select,insert,update,references
  177. show full columns from mysql.db like "Insert%";
  178. Field Type Collation Null Key Default Extra Privileges Comment
  179. Insert_priv enum('N','Y') utf8_general_ci NO N select,insert,update,references
  180. show full columns from v1;
  181. Field Type Collation Null Key Default Extra Privileges Comment
  182. c varchar(64) utf8_general_ci NO select,insert,update,references
  183. select * from information_schema.COLUMNS where table_name="t1"
  184. and column_name= "a";
  185. 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_COMMENT
  186. NULL mysqltest t1 a 1 NULL YES int NULL NULL 10 0 NULL NULL int(11) select,insert,update,references
  187. show columns from mysqltest.t1 where field like "%a%";
  188. Field Type Null Key Default Extra
  189. a int(11) YES NULL
  190. create view mysqltest.v1 (c) as select a from mysqltest.t1;
  191. grant select (a) on mysqltest.t1 to mysqltest_2@localhost;
  192. grant select on mysqltest.v1 to mysqltest_3;
  193. select table_name, column_name, privileges from information_schema.columns
  194. where table_schema = 'mysqltest' and table_name = 't1';
  195. table_name column_name privileges
  196. t1 a select
  197. show columns from mysqltest.t1;
  198. Field Type Null Key Default Extra
  199. a int(11) YES NULL
  200. select table_name, column_name, privileges from information_schema.columns
  201. where table_schema = 'mysqltest' and table_name = 'v1';
  202. table_name column_name privileges
  203. v1 c select
  204. explain select * from v1;
  205. ERROR HY000: EXPLAIN/SHOW can not be issued; lacking privileges for underlying table
  206. drop view v1, mysqltest.v1;
  207. drop tables mysqltest.t4, mysqltest.t1, t2, t3, t5;
  208. drop database mysqltest;
  209. select * from information_schema.CHARACTER_SETS
  210. where CHARACTER_SET_NAME like 'latin1%';
  211. CHARACTER_SET_NAME DEFAULT_COLLATE_NAME DESCRIPTION MAXLEN
  212. latin1 latin1_swedish_ci cp1252 West European 1
  213. SHOW CHARACTER SET LIKE 'latin1%';
  214. Charset Description Default collation Maxlen
  215. latin1 cp1252 West European latin1_swedish_ci 1
  216. SHOW CHARACTER SET WHERE charset like 'latin1%';
  217. Charset Description Default collation Maxlen
  218. latin1 cp1252 West European latin1_swedish_ci 1
  219. select * from information_schema.COLLATIONS
  220. where COLLATION_NAME like 'latin1%';
  221. COLLATION_NAME CHARACTER_SET_NAME ID IS_DEFAULT IS_COMPILED SORTLEN
  222. latin1_german1_ci latin1 5 # 1
  223. latin1_swedish_ci latin1 8 Yes # 1
  224. latin1_danish_ci latin1 15 # 1
  225. latin1_german2_ci latin1 31 # 2
  226. latin1_bin latin1 47 # 1
  227. latin1_general_ci latin1 48 # 1
  228. latin1_general_cs latin1 49 # 1
  229. latin1_spanish_ci latin1 94 # 1
  230. SHOW COLLATION LIKE 'latin1%';
  231. Collation Charset Id Default Compiled Sortlen
  232. latin1_german1_ci latin1 5 # 1
  233. latin1_swedish_ci latin1 8 Yes # 1
  234. latin1_danish_ci latin1 15 # 1
  235. latin1_german2_ci latin1 31 # 2
  236. latin1_bin latin1 47 # 1
  237. latin1_general_ci latin1 48 # 1
  238. latin1_general_cs latin1 49 # 1
  239. latin1_spanish_ci latin1 94 # 1
  240. SHOW COLLATION WHERE collation like 'latin1%';
  241. Collation Charset Id Default Compiled Sortlen
  242. latin1_german1_ci latin1 5 # 1
  243. latin1_swedish_ci latin1 8 Yes # 1
  244. latin1_danish_ci latin1 15 # 1
  245. latin1_german2_ci latin1 31 # 2
  246. latin1_bin latin1 47 # 1
  247. latin1_general_ci latin1 48 # 1
  248. latin1_general_cs latin1 49 # 1
  249. latin1_spanish_ci latin1 94 # 1
  250. select * from information_schema.COLLATION_CHARACTER_SET_APPLICABILITY
  251. where COLLATION_NAME like 'latin1%';
  252. COLLATION_NAME CHARACTER_SET_NAME
  253. latin1_german1_ci latin1
  254. latin1_swedish_ci latin1
  255. latin1_danish_ci latin1
  256. latin1_german2_ci latin1
  257. latin1_bin latin1
  258. latin1_general_ci latin1
  259. latin1_general_cs latin1
  260. latin1_spanish_ci latin1
  261. drop procedure if exists sel2;
  262. drop function if exists sub1;
  263. drop function if exists sub2;
  264. create function sub1(i int) returns int
  265. return i+1;
  266. create procedure sel2()
  267. begin
  268. select * from t1;
  269. select * from t2;
  270. end|
  271. select parameter_style, sql_data_access, dtd_identifier
  272. from information_schema.routines;
  273. parameter_style sql_data_access dtd_identifier
  274. SQL CONTAINS SQL NULL
  275. SQL CONTAINS SQL int(11)
  276. show procedure status;
  277. Db Name Type Definer Modified Created Security_type Comment character_set_client collation_connection Database Collation
  278. test sel2 PROCEDURE root@localhost # # DEFINER latin1 latin1_swedish_ci latin1_swedish_ci
  279. show function status;
  280. Db Name Type Definer Modified Created Security_type Comment character_set_client collation_connection Database Collation
  281. test sub1 FUNCTION root@localhost # # DEFINER latin1 latin1_swedish_ci latin1_swedish_ci
  282. select a.ROUTINE_NAME from information_schema.ROUTINES a,
  283. information_schema.SCHEMATA b where
  284. a.ROUTINE_SCHEMA = b.SCHEMA_NAME;
  285. ROUTINE_NAME
  286. sel2
  287. sub1
  288. explain select a.ROUTINE_NAME from information_schema.ROUTINES a,
  289. information_schema.SCHEMATA b where
  290. a.ROUTINE_SCHEMA = b.SCHEMA_NAME;
  291. id select_type table type possible_keys key key_len ref rows Extra
  292. 1 SIMPLE # ALL NULL NULL NULL NULL NULL
  293. 1 SIMPLE # ALL NULL NULL NULL NULL NULL Using where; Using join buffer
  294. select a.ROUTINE_NAME, b.name from information_schema.ROUTINES a,
  295. mysql.proc b where a.ROUTINE_NAME = convert(b.name using utf8) order by 1;
  296. ROUTINE_NAME name
  297. sel2 sel2
  298. sub1 sub1
  299. select count(*) from information_schema.ROUTINES;
  300. count(*)
  301. 2
  302. create view v1 as select routine_schema, routine_name from information_schema.routines
  303. order by routine_schema, routine_name;
  304. select * from v1;
  305. routine_schema routine_name
  306. test sel2
  307. test sub1
  308. drop view v1;
  309. select ROUTINE_NAME, ROUTINE_DEFINITION from information_schema.ROUTINES;
  310. ROUTINE_NAME ROUTINE_DEFINITION
  311. show create function sub1;
  312. ERROR 42000: FUNCTION sub1 does not exist
  313. select ROUTINE_NAME, ROUTINE_DEFINITION from information_schema.ROUTINES;
  314. ROUTINE_NAME ROUTINE_DEFINITION
  315. sel2 NULL
  316. sub1 NULL
  317. grant all privileges on test.* to mysqltest_1@localhost;
  318. select ROUTINE_NAME, ROUTINE_DEFINITION from information_schema.ROUTINES;
  319. ROUTINE_NAME ROUTINE_DEFINITION
  320. sel2 NULL
  321. sub1 NULL
  322. create function sub2(i int) returns int
  323. return i+1;
  324. select ROUTINE_NAME, ROUTINE_DEFINITION from information_schema.ROUTINES;
  325. ROUTINE_NAME ROUTINE_DEFINITION
  326. sel2 NULL
  327. sub1 NULL
  328. sub2 return i+1
  329. show create procedure sel2;
  330. Procedure sql_mode Create Procedure character_set_client collation_connection Database Collation
  331. sel2 NULL latin1 latin1_swedish_ci latin1_swedish_ci
  332. show create function sub1;
  333. Function sql_mode Create Function character_set_client collation_connection Database Collation
  334. sub1 NULL latin1 latin1_swedish_ci latin1_swedish_ci
  335. show create function sub2;
  336. Function sql_mode Create Function character_set_client collation_connection Database Collation
  337. sub2 CREATE DEFINER=`mysqltest_1`@`localhost` FUNCTION `sub2`(i int) RETURNS int(11)
  338. return i+1 latin1 latin1_swedish_ci latin1_swedish_ci
  339. show function status like "sub2";
  340. Db Name Type Definer Modified Created Security_type Comment character_set_client collation_connection Database Collation
  341. test sub2 FUNCTION mysqltest_1@localhost # # DEFINER latin1 latin1_swedish_ci latin1_swedish_ci
  342. drop function sub2;
  343. show create procedure sel2;
  344. Procedure sql_mode Create Procedure character_set_client collation_connection Database Collation
  345. sel2 CREATE DEFINER=`root`@`localhost` PROCEDURE `sel2`()
  346. begin
  347. select * from t1;
  348. select * from t2;
  349. end latin1 latin1_swedish_ci latin1_swedish_ci
  350. create view v0 (c) as select schema_name from information_schema.schemata;
  351. select * from v0;
  352. c
  353. information_schema
  354. mysql
  355. test
  356. explain select * from v0;
  357. id select_type table type possible_keys key key_len ref rows Extra
  358. 1 SIMPLE # ALL NULL NULL NULL NULL NULL
  359. create view v1 (c) as select table_name from information_schema.tables
  360. where table_name="v1";
  361. select * from v1;
  362. c
  363. v1
  364. create view v2 (c) as select column_name from information_schema.columns
  365. where table_name="v2";
  366. select * from v2;
  367. c
  368. c
  369. create view v3 (c) as select CHARACTER_SET_NAME from information_schema.character_sets
  370. where CHARACTER_SET_NAME like "latin1%";
  371. select * from v3;
  372. c
  373. latin1
  374. create view v4 (c) as select COLLATION_NAME from information_schema.collations
  375. where COLLATION_NAME like "latin1%";
  376. select * from v4;
  377. c
  378. latin1_german1_ci
  379. latin1_swedish_ci
  380. latin1_danish_ci
  381. latin1_german2_ci
  382. latin1_bin
  383. latin1_general_ci
  384. latin1_general_cs
  385. latin1_spanish_ci
  386. show keys from v4;
  387. Table Non_unique Key_name Seq_in_index Column_name Collation Cardinality Sub_part Packed Null Index_type Comment
  388. select * from information_schema.views where TABLE_NAME like "v%";
  389. TABLE_CATALOG TABLE_SCHEMA TABLE_NAME VIEW_DEFINITION CHECK_OPTION IS_UPDATABLE DEFINER SECURITY_TYPE CHARACTER_SET_CLIENT COLLATION_CONNECTION
  390. NULL test v0 select `schemata`.`SCHEMA_NAME` AS `c` from `information_schema`.`schemata` NONE NO root@localhost DEFINER latin1 latin1_swedish_ci
  391. NULL 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_ci
  392. NULL 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_ci
  393. NULL 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_ci
  394. NULL 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_ci
  395. drop view v0, v1, v2, v3, v4;
  396. create table t1 (a int);
  397. grant select,update,insert on t1 to mysqltest_1@localhost;
  398. grant select (a), update (a),insert(a), references(a) on t1 to mysqltest_1@localhost;
  399. grant all on test.* to mysqltest_1@localhost with grant option;
  400. select * from information_schema.USER_PRIVILEGES where grantee like '%mysqltest_1%';
  401. GRANTEE TABLE_CATALOG PRIVILEGE_TYPE IS_GRANTABLE
  402. 'mysqltest_1'@'localhost' NULL USAGE NO
  403. select * from information_schema.SCHEMA_PRIVILEGES where grantee like '%mysqltest_1%';
  404. GRANTEE TABLE_CATALOG TABLE_SCHEMA PRIVILEGE_TYPE IS_GRANTABLE
  405. 'mysqltest_1'@'localhost' NULL test SELECT YES
  406. 'mysqltest_1'@'localhost' NULL test INSERT YES
  407. 'mysqltest_1'@'localhost' NULL test UPDATE YES
  408. 'mysqltest_1'@'localhost' NULL test DELETE YES
  409. 'mysqltest_1'@'localhost' NULL test CREATE YES
  410. 'mysqltest_1'@'localhost' NULL test DROP YES
  411. 'mysqltest_1'@'localhost' NULL test REFERENCES YES
  412. 'mysqltest_1'@'localhost' NULL test INDEX YES
  413. 'mysqltest_1'@'localhost' NULL test ALTER YES
  414. 'mysqltest_1'@'localhost' NULL test CREATE TEMPORARY TABLES YES
  415. 'mysqltest_1'@'localhost' NULL test LOCK TABLES YES
  416. 'mysqltest_1'@'localhost' NULL test EXECUTE YES
  417. 'mysqltest_1'@'localhost' NULL test CREATE VIEW YES
  418. 'mysqltest_1'@'localhost' NULL test SHOW VIEW YES
  419. 'mysqltest_1'@'localhost' NULL test CREATE ROUTINE YES
  420. 'mysqltest_1'@'localhost' NULL test ALTER ROUTINE YES
  421. 'mysqltest_1'@'localhost' NULL test EVENT YES
  422. 'mysqltest_1'@'localhost' NULL test TRIGGER YES
  423. select * from information_schema.TABLE_PRIVILEGES where grantee like '%mysqltest_1%';
  424. GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME PRIVILEGE_TYPE IS_GRANTABLE
  425. 'mysqltest_1'@'localhost' NULL test t1 SELECT NO
  426. 'mysqltest_1'@'localhost' NULL test t1 INSERT NO
  427. 'mysqltest_1'@'localhost' NULL test t1 UPDATE NO
  428. select * from information_schema.COLUMN_PRIVILEGES where grantee like '%mysqltest_1%';
  429. GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME PRIVILEGE_TYPE IS_GRANTABLE
  430. 'mysqltest_1'@'localhost' NULL test t1 a SELECT NO
  431. 'mysqltest_1'@'localhost' NULL test t1 a INSERT NO
  432. 'mysqltest_1'@'localhost' NULL test t1 a UPDATE NO
  433. 'mysqltest_1'@'localhost' NULL test t1 a REFERENCES NO
  434. delete from mysql.user where user like 'mysqltest%';
  435. delete from mysql.db where user like 'mysqltest%';
  436. delete from mysql.tables_priv where user like 'mysqltest%';
  437. delete from mysql.columns_priv where user like 'mysqltest%';
  438. flush privileges;
  439. drop table t1;
  440. create table t1 (a int null, primary key(a));
  441. alter table t1 add constraint constraint_1 unique (a);
  442. alter table t1 add constraint unique key_1(a);
  443. alter table t1 add constraint constraint_2 unique key_2(a);
  444. show create table t1;
  445. Table Create Table
  446. t1 CREATE TABLE `t1` (
  447. `a` int(11) NOT NULL DEFAULT '0',
  448. PRIMARY KEY (`a`),
  449. UNIQUE KEY `constraint_1` (`a`),
  450. UNIQUE KEY `key_1` (`a`),
  451. UNIQUE KEY `key_2` (`a`)
  452. ) ENGINE=MyISAM DEFAULT CHARSET=latin1
  453. select * from information_schema.TABLE_CONSTRAINTS where
  454. TABLE_SCHEMA= "test";
  455. CONSTRAINT_CATALOG CONSTRAINT_SCHEMA CONSTRAINT_NAME TABLE_SCHEMA TABLE_NAME CONSTRAINT_TYPE
  456. NULL test PRIMARY test t1 PRIMARY KEY
  457. NULL test constraint_1 test t1 UNIQUE
  458. NULL test key_1 test t1 UNIQUE
  459. NULL test key_2 test t1 UNIQUE
  460. select * from information_schema.KEY_COLUMN_USAGE where
  461. TABLE_SCHEMA= "test";
  462. 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_NAME
  463. NULL test PRIMARY NULL test t1 a 1 NULL NULL NULL NULL
  464. NULL test constraint_1 NULL test t1 a 1 NULL NULL NULL NULL
  465. NULL test key_1 NULL test t1 a 1 NULL NULL NULL NULL
  466. NULL test key_2 NULL test t1 a 1 NULL NULL NULL NULL
  467. select table_name from information_schema.TABLES where table_schema like "test%";
  468. table_name
  469. t1
  470. select table_name,column_name from information_schema.COLUMNS where table_schema like "test%";
  471. table_name column_name
  472. t1 a
  473. select ROUTINE_NAME from information_schema.ROUTINES;
  474. ROUTINE_NAME
  475. sel2
  476. sub1
  477. delete from mysql.user where user='mysqltest_1';
  478. drop table t1;
  479. drop procedure sel2;
  480. drop function sub1;
  481. create table t1(a int);
  482. create view v1 (c) as select a from t1 with check option;
  483. create view v2 (c) as select a from t1 WITH LOCAL CHECK OPTION;
  484. create view v3 (c) as select a from t1 WITH CASCADED CHECK OPTION;
  485. select * from information_schema.views;
  486. TABLE_CATALOG TABLE_SCHEMA TABLE_NAME VIEW_DEFINITION CHECK_OPTION IS_UPDATABLE DEFINER SECURITY_TYPE CHARACTER_SET_CLIENT COLLATION_CONNECTION
  487. NULL test v1 select `test`.`t1`.`a` AS `c` from `test`.`t1` CASCADED YES root@localhost DEFINER latin1 latin1_swedish_ci
  488. NULL test v2 select `test`.`t1`.`a` AS `c` from `test`.`t1` LOCAL YES root@localhost DEFINER latin1 latin1_swedish_ci
  489. NULL test v3 select `test`.`t1`.`a` AS `c` from `test`.`t1` CASCADED YES root@localhost DEFINER latin1 latin1_swedish_ci
  490. grant select (a) on test.t1 to joe@localhost with grant option;
  491. select * from INFORMATION_SCHEMA.COLUMN_PRIVILEGES;
  492. GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME PRIVILEGE_TYPE IS_GRANTABLE
  493. 'joe'@'localhost' NULL test t1 a SELECT YES
  494. select * from INFORMATION_SCHEMA.TABLE_PRIVILEGES;
  495. GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME PRIVILEGE_TYPE IS_GRANTABLE
  496. drop view v1, v2, v3;
  497. drop table t1;
  498. delete from mysql.user where user='joe';
  499. delete from mysql.db where user='joe';
  500. delete from mysql.tables_priv where user='joe';
  501. delete from mysql.columns_priv where user='joe';
  502. flush privileges;
  503. create table t1 (a int not null auto_increment,b int, primary key (a));
  504. insert into t1 values (1,1),(NULL,3),(NULL,4);
  505. select AUTO_INCREMENT from information_schema.tables where table_name = 't1';
  506. AUTO_INCREMENT
  507. 4
  508. drop table t1;
  509. create table t1 (s1 int);
  510. insert into t1 values (0),(9),(0);
  511. select s1 from t1 where s1 in (select version from
  512. information_schema.tables) union select version from
  513. information_schema.tables;
  514. s1
  515. 10
  516. drop table t1;
  517. SHOW CREATE TABLE INFORMATION_SCHEMA.character_sets;
  518. Table Create Table
  519. CHARACTER_SETS CREATE TEMPORARY TABLE `CHARACTER_SETS` (
  520. `CHARACTER_SET_NAME` varchar(32) NOT NULL DEFAULT '',
  521. `DEFAULT_COLLATE_NAME` varchar(32) NOT NULL DEFAULT '',
  522. `DESCRIPTION` varchar(60) NOT NULL DEFAULT '',
  523. `MAXLEN` bigint(3) NOT NULL DEFAULT '0'
  524. ) ENGINE=MEMORY DEFAULT CHARSET=utf8
  525. set names latin2;
  526. SHOW CREATE TABLE INFORMATION_SCHEMA.character_sets;
  527. Table Create Table
  528. CHARACTER_SETS CREATE TEMPORARY TABLE `CHARACTER_SETS` (
  529. `CHARACTER_SET_NAME` varchar(32) NOT NULL DEFAULT '',
  530. `DEFAULT_COLLATE_NAME` varchar(32) NOT NULL DEFAULT '',
  531. `DESCRIPTION` varchar(60) NOT NULL DEFAULT '',
  532. `MAXLEN` bigint(3) NOT NULL DEFAULT '0'
  533. ) ENGINE=MEMORY DEFAULT CHARSET=utf8
  534. set names latin1;
  535. create table t1 select * from information_schema.CHARACTER_SETS
  536. where CHARACTER_SET_NAME like "latin1";
  537. select * from t1;
  538. CHARACTER_SET_NAME DEFAULT_COLLATE_NAME DESCRIPTION MAXLEN
  539. latin1 latin1_swedish_ci cp1252 West European 1
  540. alter table t1 default character set utf8;
  541. show create table t1;
  542. Table Create Table
  543. t1 CREATE TABLE `t1` (
  544. `CHARACTER_SET_NAME` varchar(32) NOT NULL DEFAULT '',
  545. `DEFAULT_COLLATE_NAME` varchar(32) NOT NULL DEFAULT '',
  546. `DESCRIPTION` varchar(60) NOT NULL DEFAULT '',
  547. `MAXLEN` bigint(3) NOT NULL DEFAULT '0'
  548. ) ENGINE=MyISAM DEFAULT CHARSET=utf8
  549. drop table t1;
  550. create view v1 as select * from information_schema.TABLES;
  551. drop view v1;
  552. create table t1(a NUMERIC(5,3), b NUMERIC(5,1), c float(5,2),
  553. d NUMERIC(6,4), e float, f DECIMAL(6,3), g int(11), h DOUBLE(10,3),
  554. i DOUBLE);
  555. select COLUMN_NAME,COLUMN_TYPE, CHARACTER_MAXIMUM_LENGTH,
  556. CHARACTER_OCTET_LENGTH, NUMERIC_PRECISION, NUMERIC_SCALE
  557. from information_schema.columns where table_name= 't1';
  558. COLUMN_NAME COLUMN_TYPE CHARACTER_MAXIMUM_LENGTH CHARACTER_OCTET_LENGTH NUMERIC_PRECISION NUMERIC_SCALE
  559. a decimal(5,3) NULL NULL 5 3
  560. b decimal(5,1) NULL NULL 5 1
  561. c float(5,2) NULL NULL 5 2
  562. d decimal(6,4) NULL NULL 6 4
  563. e float NULL NULL 12 NULL
  564. f decimal(6,3) NULL NULL 6 3
  565. g int(11) NULL NULL 10 0
  566. h double(10,3) NULL NULL 10 3
  567. i double NULL NULL 22 NULL
  568. drop table t1;
  569. create table t115 as select table_name, column_name, column_type
  570. from information_schema.columns where table_name = 'proc';
  571. select * from t115;
  572. table_name column_name column_type
  573. proc db char(64)
  574. proc name char(64)
  575. proc type enum('FUNCTION','PROCEDURE')
  576. proc specific_name char(64)
  577. proc language enum('SQL')
  578. proc sql_data_access enum('CONTAINS_SQL','NO_SQL','READS_SQL_DATA','MODIFIES_SQL_DATA')
  579. proc is_deterministic enum('YES','NO')
  580. proc security_type enum('INVOKER','DEFINER')
  581. proc param_list blob
  582. proc returns longblob
  583. proc body longblob
  584. proc definer char(77)
  585. proc created timestamp
  586. proc modified timestamp
  587. proc 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')
  588. proc comment char(64)
  589. proc character_set_client char(32)
  590. proc collation_connection char(32)
  591. proc db_collation char(32)
  592. proc body_utf8 longblob
  593. drop table t115;
  594. create procedure p108 () begin declare c cursor for select data_type
  595. from information_schema.columns; open c; open c; end;//
  596. call p108()//
  597. ERROR 24000: Cursor is already open
  598. drop procedure p108;
  599. create view v1 as select A1.table_name from information_schema.TABLES A1
  600. where table_name= "user";
  601. select * from v1;
  602. table_name
  603. user
  604. drop view v1;
  605. create view vo as select 'a' union select 'a';
  606. show index from vo;
  607. Table Non_unique Key_name Seq_in_index Column_name Collation Cardinality Sub_part Packed Null Index_type Comment
  608. select * from information_schema.TABLE_CONSTRAINTS where
  609. TABLE_NAME= "vo";
  610. CONSTRAINT_CATALOG CONSTRAINT_SCHEMA CONSTRAINT_NAME TABLE_SCHEMA TABLE_NAME CONSTRAINT_TYPE
  611. select * from information_schema.KEY_COLUMN_USAGE where
  612. TABLE_NAME= "vo";
  613. 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_NAME
  614. drop view vo;
  615. select TABLE_NAME,TABLE_TYPE,ENGINE
  616. from information_schema.tables
  617. where table_schema='information_schema' limit 2;
  618. TABLE_NAME TABLE_TYPE ENGINE
  619. CHARACTER_SETS SYSTEM VIEW MEMORY
  620. COLLATIONS SYSTEM VIEW MEMORY
  621. show tables from information_schema like "T%";
  622. Tables_in_information_schema (T%)
  623. TABLES
  624. TABLE_CONSTRAINTS
  625. TABLE_PRIVILEGES
  626. TRIGGERS
  627. create database information_schema;
  628. ERROR 42000: Access denied for user 'root'@'localhost' to database 'information_schema'
  629. use information_schema;
  630. show full tables like "T%";
  631. Tables_in_information_schema (T%) Table_type
  632. TABLES SYSTEM VIEW
  633. TABLE_CONSTRAINTS SYSTEM VIEW
  634. TABLE_PRIVILEGES SYSTEM VIEW
  635. TRIGGERS SYSTEM VIEW
  636. create table t1(a int);
  637. ERROR 42S02: Unknown table 't1' in information_schema
  638. use test;
  639. show tables;
  640. Tables_in_test
  641. use information_schema;
  642. show tables like "T%";
  643. Tables_in_information_schema (T%)
  644. TABLES
  645. TABLE_CONSTRAINTS
  646. TABLE_PRIVILEGES
  647. TRIGGERS
  648. select table_name from tables where table_name='user';
  649. table_name
  650. user
  651. select column_name, privileges from columns
  652. where table_name='user' and column_name like '%o%';
  653. column_name privileges
  654. Host select,insert,update,references
  655. Password select,insert,update,references
  656. Drop_priv select,insert,update,references
  657. Reload_priv select,insert,update,references
  658. Shutdown_priv select,insert,update,references
  659. Process_priv select,insert,update,references
  660. Show_db_priv select,insert,update,references
  661. Lock_tables_priv select,insert,update,references
  662. Show_view_priv select,insert,update,references
  663. Create_routine_priv select,insert,update,references
  664. Alter_routine_priv select,insert,update,references
  665. max_questions select,insert,update,references
  666. max_connections select,insert,update,references
  667. max_user_connections select,insert,update,references
  668. use test;
  669. create function sub1(i int) returns int
  670. return i+1;
  671. create table t1(f1 int);
  672. create view v2 (c) as select f1 from t1;
  673. create view v3 (c) as select sub1(1);
  674. create table t4(f1 int, KEY f1_key (f1));
  675. drop table t1;
  676. drop function sub1;
  677. select table_name from information_schema.views
  678. where table_schema='test';
  679. table_name
  680. v2
  681. v3
  682. select table_name from information_schema.views
  683. where table_schema='test';
  684. table_name
  685. v2
  686. v3
  687. select column_name from information_schema.columns
  688. where table_schema='test';
  689. column_name
  690. f1
  691. Warnings:
  692. Warning 1356 View 'test.v2' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
  693. Warning 1356 View 'test.v3' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
  694. select index_name from information_schema.statistics where table_schema='test';
  695. index_name
  696. f1_key
  697. select constraint_name from information_schema.table_constraints
  698. where table_schema='test';
  699. constraint_name
  700. show create view v2;
  701. View Create View character_set_client collation_connection
  702. v2 CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER VIEW `v2` AS select `test`.`t1`.`f1` AS `c` from `t1` latin1 latin1_swedish_ci
  703. Warnings:
  704. Warning 1356 View 'test.v2' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
  705. show create table v3;
  706. View Create View character_set_client collation_connection
  707. v3 CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER VIEW `v3` AS select `sub1`(1) AS `c` latin1 latin1_swedish_ci
  708. Warnings:
  709. Warning 1356 View 'test.v3' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
  710. drop view v2;
  711. drop view v3;
  712. drop table t4;
  713. select * from information_schema.table_names;
  714. ERROR 42S02: Unknown table 'table_names' in information_schema
  715. select column_type from information_schema.columns
  716. where table_schema="information_schema" and table_name="COLUMNS" and
  717. (column_name="character_set_name" or column_name="collation_name");
  718. column_type
  719. varchar(32)
  720. varchar(32)
  721. select TABLE_ROWS from information_schema.tables where
  722. table_schema="information_schema" and table_name="COLUMNS";
  723. TABLE_ROWS
  724. NULL
  725. select table_type from information_schema.tables
  726. where table_schema="mysql" and table_name="user";
  727. table_type
  728. BASE TABLE
  729. show open tables where `table` like "user";
  730. Database Table In_use Name_locked
  731. mysql user 0 0
  732. show status where variable_name like "%database%";
  733. Variable_name Value
  734. Com_show_databases 3
  735. show variables where variable_name like "skip_show_databas";
  736. Variable_name Value
  737. show global status like "Threads_running";
  738. Variable_name Value
  739. Threads_running #
  740. create table t1(f1 int);
  741. create table t2(f2 int);
  742. create view v1 as select * from t1, t2;
  743. set @got_val= (select count(*) from information_schema.columns);
  744. drop view v1;
  745. drop table t1, t2;
  746. use test;
  747. CREATE TABLE t_crashme ( f1 BIGINT);
  748. CREATE VIEW a1 (t_CRASHME) AS SELECT f1 FROM t_crashme GROUP BY f1;
  749. CREATE VIEW a2 AS SELECT t_CRASHME FROM a1;
  750. count(*)
  751. 68
  752. drop view a2, a1;
  753. drop table t_crashme;
  754. select table_schema,table_name, column_name from
  755. information_schema.columns
  756. where data_type = 'longtext';
  757. table_schema table_name column_name
  758. information_schema COLUMNS COLUMN_DEFAULT
  759. information_schema COLUMNS COLUMN_TYPE
  760. information_schema EVENTS EVENT_DEFINITION
  761. information_schema PARTITIONS PARTITION_EXPRESSION
  762. information_schema PARTITIONS SUBPARTITION_EXPRESSION
  763. information_schema PARTITIONS PARTITION_DESCRIPTION
  764. information_schema PLUGINS PLUGIN_DESCRIPTION
  765. information_schema PROCESSLIST INFO
  766. information_schema ROUTINES ROUTINE_DEFINITION
  767. information_schema TRIGGERS ACTION_CONDITION
  768. information_schema TRIGGERS ACTION_STATEMENT
  769. information_schema VIEWS VIEW_DEFINITION
  770. select table_name, column_name, data_type from information_schema.columns
  771. where data_type = 'datetime';
  772. table_name column_name data_type
  773. EVENTS EXECUTE_AT datetime
  774. EVENTS STARTS datetime
  775. EVENTS ENDS datetime
  776. EVENTS CREATED datetime
  777. EVENTS LAST_ALTERED datetime
  778. EVENTS LAST_EXECUTED datetime
  779. FILES CREATION_TIME datetime
  780. FILES LAST_UPDATE_TIME datetime
  781. FILES LAST_ACCESS_TIME datetime
  782. FILES CREATE_TIME datetime
  783. FILES UPDATE_TIME datetime
  784. FILES CHECK_TIME datetime
  785. PARTITIONS CREATE_TIME datetime
  786. PARTITIONS UPDATE_TIME datetime
  787. PARTITIONS CHECK_TIME datetime
  788. ROUTINES CREATED datetime
  789. ROUTINES LAST_ALTERED datetime
  790. TABLES CREATE_TIME datetime
  791. TABLES UPDATE_TIME datetime
  792. TABLES CHECK_TIME datetime
  793. TRIGGERS CREATED datetime
  794. event execute_at datetime
  795. event last_executed datetime
  796. event starts datetime
  797. event ends datetime
  798. SELECT COUNT(*) FROM INFORMATION_SCHEMA.TABLES A
  799. WHERE NOT EXISTS
  800. (SELECT * FROM INFORMATION_SCHEMA.COLUMNS B
  801. WHERE A.TABLE_SCHEMA = B.TABLE_SCHEMA
  802. AND A.TABLE_NAME = B.TABLE_NAME);
  803. COUNT(*)
  804. 0
  805. create table t1
  806. ( x_bigint BIGINT,
  807. x_integer INTEGER,
  808. x_smallint SMALLINT,
  809. x_decimal DECIMAL(5,3),
  810. x_numeric NUMERIC(5,3),
  811. x_real REAL,
  812. x_float FLOAT,
  813. x_double_precision DOUBLE PRECISION );
  814. SELECT COLUMN_NAME, CHARACTER_MAXIMUM_LENGTH, CHARACTER_OCTET_LENGTH
  815. FROM INFORMATION_SCHEMA.COLUMNS
  816. WHERE TABLE_NAME= 't1';
  817. COLUMN_NAME CHARACTER_MAXIMUM_LENGTH CHARACTER_OCTET_LENGTH
  818. x_bigint NULL NULL
  819. x_integer NULL NULL
  820. x_smallint NULL NULL
  821. x_decimal NULL NULL
  822. x_numeric NULL NULL
  823. x_real NULL NULL
  824. x_float NULL NULL
  825. x_double_precision NULL NULL
  826. drop table t1;
  827. grant select on test.* to mysqltest_4@localhost;
  828. SELECT TABLE_NAME, COLUMN_NAME, PRIVILEGES FROM INFORMATION_SCHEMA.COLUMNS
  829. where COLUMN_NAME='TABLE_NAME';
  830. TABLE_NAME COLUMN_NAME PRIVILEGES
  831. COLUMNS TABLE_NAME select
  832. COLUMN_PRIVILEGES TABLE_NAME select
  833. FILES TABLE_NAME select
  834. KEY_COLUMN_USAGE TABLE_NAME select
  835. PARTITIONS TABLE_NAME select
  836. REFERENTIAL_CONSTRAINTS TABLE_NAME select
  837. STATISTICS TABLE_NAME select
  838. TABLES TABLE_NAME select
  839. TABLE_CONSTRAINTS TABLE_NAME select
  840. TABLE_PRIVILEGES TABLE_NAME select
  841. VIEWS TABLE_NAME select
  842. delete from mysql.user where user='mysqltest_4';
  843. delete from mysql.db where user='mysqltest_4';
  844. flush privileges;
  845. SELECT table_schema, count(*) FROM information_schema.TABLES where table_name<>'ndb_binlog_index' AND table_name<>'ndb_apply_status' GROUP BY TABLE_SCHEMA;
  846. table_schema count(*)
  847. information_schema 28
  848. mysql 22
  849. create table t1 (i int, j int);
  850. create trigger trg1 before insert on t1 for each row
  851. begin
  852. if new.j > 10 then
  853. set new.j := 10;
  854. end if;
  855. end|
  856. create trigger trg2 before update on t1 for each row
  857. begin
  858. if old.i % 2 = 0 then
  859. set new.j := -1;
  860. end if;
  861. end|
  862. create trigger trg3 after update on t1 for each row
  863. begin
  864. if new.j = -1 then
  865. set @fired:= "Yes";
  866. end if;
  867. end|
  868. show triggers;
  869. Trigger Event Table Statement Timing Created sql_mode Definer character_set_client collation_connection Database Collation
  870. trg1 INSERT t1 begin
  871. if new.j > 10 then
  872. set new.j := 10;
  873. end if;
  874. end BEFORE NULL root@localhost latin1 latin1_swedish_ci latin1_swedish_ci
  875. trg2 UPDATE t1 begin
  876. if old.i % 2 = 0 then
  877. set new.j := -1;
  878. end if;
  879. end BEFORE NULL root@localhost latin1 latin1_swedish_ci latin1_swedish_ci
  880. trg3 UPDATE t1 begin
  881. if new.j = -1 then
  882. set @fired:= "Yes";
  883. end if;
  884. end AFTER NULL root@localhost latin1 latin1_swedish_ci latin1_swedish_ci
  885. select * from information_schema.triggers;
  886. 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_COLLATION
  887. NULL test trg1 INSERT NULL test t1 0 NULL begin
  888. if new.j > 10 then
  889. set new.j := 10;
  890. end if;
  891. end ROW BEFORE NULL NULL OLD NEW NULL root@localhost latin1 latin1_swedish_ci latin1_swedish_ci
  892. NULL test trg2 UPDATE NULL test t1 0 NULL begin
  893. if old.i % 2 = 0 then
  894. set new.j := -1;
  895. end if;
  896. end ROW BEFORE NULL NULL OLD NEW NULL root@localhost latin1 latin1_swedish_ci latin1_swedish_ci
  897. NULL test trg3 UPDATE NULL test t1 0 NULL begin
  898. if new.j = -1 then
  899. set @fired:= "Yes";
  900. end if;
  901. end ROW AFTER NULL NULL OLD NEW NULL root@localhost latin1 latin1_swedish_ci latin1_swedish_ci
  902. drop trigger trg1;
  903. drop trigger trg2;
  904. drop trigger trg3;
  905. drop table t1;
  906. create database mysqltest;
  907. create table mysqltest.t1 (f1 int, f2 int);
  908. create table mysqltest.t2 (f1 int);
  909. grant select (f1) on mysqltest.t1 to user1@localhost;
  910. grant select on mysqltest.t2 to user2@localhost;
  911. grant select on mysqltest.* to user3@localhost;
  912. grant select on *.* to user4@localhost;
  913. select * from information_schema.column_privileges order by grantee;
  914. GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME PRIVILEGE_TYPE IS_GRANTABLE
  915. 'user1'@'localhost' NULL mysqltest t1 f1 SELECT NO
  916. select * from information_schema.table_privileges order by grantee;
  917. GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME PRIVILEGE_TYPE IS_GRANTABLE
  918. select * from information_schema.schema_privileges order by grantee;
  919. GRANTEE TABLE_CATALOG TABLE_SCHEMA PRIVILEGE_TYPE IS_GRANTABLE
  920. select * from information_schema.user_privileges order by grantee;
  921. GRANTEE TABLE_CATALOG PRIVILEGE_TYPE IS_GRANTABLE
  922. 'user1'@'localhost' NULL USAGE NO
  923. show grants;
  924. Grants for user1@localhost
  925. GRANT USAGE ON *.* TO 'user1'@'localhost'
  926. GRANT SELECT (f1) ON `mysqltest`.`t1` TO 'user1'@'localhost'
  927. select * from information_schema.column_privileges order by grantee;
  928. GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME PRIVILEGE_TYPE IS_GRANTABLE
  929. select * from information_schema.table_privileges order by grantee;
  930. GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME PRIVILEGE_TYPE IS_GRANTABLE
  931. 'user2'@'localhost' NULL mysqltest t2 SELECT NO
  932. select * from information_schema.schema_privileges order by grantee;
  933. GRANTEE TABLE_CATALOG TABLE_SCHEMA PRIVILEGE_TYPE IS_GRANTABLE
  934. select * from information_schema.user_privileges order by grantee;
  935. GRANTEE TABLE_CATALOG PRIVILEGE_TYPE IS_GRANTABLE
  936. 'user2'@'localhost' NULL USAGE NO
  937. show grants;
  938. Grants for user2@localhost
  939. GRANT USAGE ON *.* TO 'user2'@'localhost'
  940. GRANT SELECT ON `mysqltest`.`t2` TO 'user2'@'localhost'
  941. select * from information_schema.column_privileges order by grantee;
  942. GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME PRIVILEGE_TYPE IS_GRANTABLE
  943. select * from information_schema.table_privileges order by grantee;
  944. GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME PRIVILEGE_TYPE IS_GRANTABLE
  945. select * from information_schema.schema_privileges order by grantee;
  946. GRANTEE TABLE_CATALOG TABLE_SCHEMA PRIVILEGE_TYPE IS_GRANTABLE
  947. 'user3'@'localhost' NULL mysqltest SELECT NO
  948. select * from information_schema.user_privileges order by grantee;
  949. GRANTEE TABLE_CATALOG PRIVILEGE_TYPE IS_GRANTABLE
  950. 'user3'@'localhost' NULL USAGE NO
  951. show grants;
  952. Grants for user3@localhost
  953. GRANT USAGE ON *.* TO 'user3'@'localhost'
  954. GRANT SELECT ON `mysqltest`.* TO 'user3'@'localhost'
  955. select * from information_schema.column_privileges where grantee like '%user%'
  956. order by grantee;
  957. GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME PRIVILEGE_TYPE IS_GRANTABLE
  958. 'user1'@'localhost' NULL mysqltest t1 f1 SELECT NO
  959. select * from information_schema.table_privileges where grantee like '%user%'
  960. order by grantee;
  961. GRANTEE TABLE_CATALOG TABLE_SCHEMA TABLE_NAME PRIVILEGE_TYPE IS_GRANTABLE
  962. 'user2'@'localhost' NULL mysqltest t2 SELECT NO
  963. select * from information_schema.schema_privileges where grantee like '%user%'
  964. order by grantee;
  965. GRANTEE TABLE_CATALOG TABLE_SCHEMA PRIVILEGE_TYPE IS_GRANTABLE
  966. 'user3'@'localhost' NULL mysqltest SELECT NO
  967. select * from information_schema.user_privileges where grantee like '%user%'
  968. order by grantee;
  969. GRANTEE TABLE_CATALOG PRIVILEGE_TYPE IS_GRANTABLE
  970. 'user1'@'localhost' NULL USAGE NO
  971. 'user2'@'localhost' NULL USAGE NO
  972. 'user3'@'localhost' NULL USAGE NO
  973. 'user4'@'localhost' NULL SELECT NO
  974. show grants;
  975. Grants for user4@localhost
  976. GRANT SELECT ON *.* TO 'user4'@'localhost'
  977. drop user user1@localhost, user2@localhost, user3@localhost, user4@localhost;
  978. use test;
  979. drop database mysqltest;
  980. drop procedure if exists p1;
  981. drop procedure if exists p2;
  982. create procedure p1 () modifies sql data set @a = 5;
  983. create procedure p2 () set @a = 5;
  984. select sql_data_access from information_schema.routines
  985. where specific_name like 'p%';
  986. sql_data_access
  987. MODIFIES SQL DATA
  988. CONTAINS SQL
  989. drop procedure p1;
  990. drop procedure p2;
  991. show create database information_schema;
  992. Database Create Database
  993. information_schema CREATE DATABASE `information_schema` /*!40100 DEFAULT CHARACTER SET utf8 */
  994. create table t1(f1 LONGBLOB, f2 LONGTEXT);
  995. select column_name,data_type,CHARACTER_OCTET_LENGTH,
  996. CHARACTER_MAXIMUM_LENGTH
  997. from information_schema.columns
  998. where table_name='t1';
  999. column_name data_type CHARACTER_OCTET_LENGTH CHARACTER_MAXIMUM_LENGTH
  1000. f1 longblob 4294967295 4294967295
  1001. f2 longtext 4294967295 4294967295
  1002. drop table t1;
  1003. create table t1(f1 tinyint, f2 SMALLINT, f3 mediumint, f4 int,
  1004. f5 BIGINT, f6 BIT, f7 bit(64));
  1005. select column_name, NUMERIC_PRECISION, NUMERIC_SCALE
  1006. from information_schema.columns
  1007. where table_name='t1';
  1008. column_name NUMERIC_PRECISION NUMERIC_SCALE
  1009. f1 3 0
  1010. f2 5 0
  1011. f3 7 0
  1012. f4 10 0
  1013. f5 19 0
  1014. f6 1 NULL
  1015. f7 64 NULL
  1016. drop table t1;
  1017. create table t1 (f1 integer);
  1018. create trigger tr1 after insert on t1 for each row set @test_var=42;
  1019. use information_schema;
  1020. select trigger_schema, trigger_name from triggers where
  1021. trigger_name='tr1';
  1022. trigger_schema trigger_name
  1023. test tr1
  1024. use test;
  1025. drop table t1;
  1026. create table t1 (a int not null, b int);
  1027. use information_schema;
  1028. select column_name, column_default from columns
  1029. where table_schema='test' and table_name='t1';
  1030. column_name column_default
  1031. a NULL
  1032. b NULL
  1033. use test;
  1034. show columns from t1;
  1035. Field Type Null Key Default Extra
  1036. a int(11) NO NULL
  1037. b int(11) YES NULL
  1038. drop table t1;
  1039. CREATE TABLE t1 (a int);
  1040. CREATE TABLE t2 (b int);
  1041. SHOW TABLE STATUS FROM test
  1042. WHERE name IN ( SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
  1043. WHERE TABLE_SCHEMA='test' AND TABLE_TYPE='BASE TABLE');
  1044. 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 Comment
  1045. t1 MyISAM 10 Fixed 0 0 0 # 1024 0 NULL # # NULL latin1_swedish_ci NULL
  1046. t2 MyISAM 10 Fixed 0 0 0 # 1024 0 NULL # # NULL latin1_swedish_ci NULL
  1047. DROP TABLE t1,t2;
  1048. create table t1(f1 int);
  1049. create view v1 (c) as select f1 from t1;
  1050. select database();
  1051. database()
  1052. NULL
  1053. show fields from test.v1;
  1054. Field Type Null Key Default Extra
  1055. c int(11) YES NULL
  1056. drop view v1;
  1057. drop table t1;
  1058. alter database information_schema;
  1059. 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 1
  1060. drop database information_schema;
  1061. ERROR 42000: Access denied for user 'root'@'localhost' to database 'information_schema'
  1062. drop table information_schema.tables;
  1063. ERROR 42000: Access denied for user 'root'@'localhost' to database 'information_schema'
  1064. alter table information_schema.tables;
  1065. ERROR 42000: Access denied for user 'root'@'localhost' to database 'information_schema'
  1066. use information_schema;
  1067. create temporary table schemata(f1 char(10));
  1068. ERROR 42000: Access denied for user 'root'@'localhost' to database 'information_schema'
  1069. CREATE PROCEDURE p1 ()
  1070. BEGIN
  1071. SELECT 'foo' FROM DUAL;
  1072. END |
  1073. ERROR 42000: Unknown database 'information_schema'
  1074. select ROUTINE_NAME from routines;
  1075. ROUTINE_NAME
  1076. grant all on information_schema.* to 'user1'@'localhost';
  1077. ERROR 42000: Access denied for user 'root'@'localhost' to database 'information_schema'
  1078. grant select on information_schema.* to 'user1'@'localhost';
  1079. ERROR 42000: Access denied for user 'root'@'localhost' to database 'information_schema'
  1080. use test;
  1081. create table t1(id int);
  1082. insert into t1(id) values (1);
  1083. select 1 from (select 1 from test.t1) a;
  1084. 1
  1085. 1
  1086. use information_schema;
  1087. select 1 from (select 1 from test.t1) a;
  1088. 1
  1089. 1
  1090. use test;
  1091. drop table t1;
  1092. create table t1 (f1 int(11));
  1093. create view v1 as select * from t1;
  1094. drop table t1;
  1095. select table_type from information_schema.tables
  1096. where table_name="v1";
  1097. table_type
  1098. VIEW
  1099. drop view v1;
  1100. create temporary table t1(f1 int, index(f1));
  1101. show columns from t1;
  1102. Field Type Null Key Default Extra
  1103. f1 int(11) YES MUL NULL
  1104. describe t1;
  1105. Field Type Null Key Default Extra
  1106. f1 int(11) YES MUL NULL
  1107. show indexes from t1;
  1108. Table Non_unique Key_name Seq_in_index Column_name Collation Cardinality Sub_part Packed Null Index_type Comment
  1109. t1 1 f1 1 f1 A NULL NULL NULL YES BTREE
  1110. drop table t1;
  1111. create table t1(f1 binary(32), f2 varbinary(64));
  1112. select character_maximum_length, character_octet_length
  1113. from information_schema.columns where table_name='t1';
  1114. character_maximum_length character_octet_length
  1115. 32 32
  1116. 64 64
  1117. drop table t1;
  1118. CREATE TABLE t1 (f1 BIGINT, f2 VARCHAR(20), f3 BIGINT);
  1119. INSERT INTO t1 SET f1 = 1, f2 = 'Schoenenbourg', f3 = 1;
  1120. CREATE FUNCTION func2() RETURNS BIGINT RETURN 1;
  1121. CREATE FUNCTION func1() RETURNS BIGINT
  1122. BEGIN
  1123. RETURN ( SELECT COUNT(*) FROM INFORMATION_SCHEMA.VIEWS);
  1124. END//
  1125. CREATE VIEW v1 AS SELECT 1 FROM t1
  1126. WHERE f3 = (SELECT func2 ());
  1127. SELECT func1();
  1128. func1()
  1129. 1
  1130. DROP TABLE t1;
  1131. DROP VIEW v1;
  1132. DROP FUNCTION func1;
  1133. DROP FUNCTION func2;
  1134. select column_type, group_concat(table_schema, '.', table_name), count(*) as num
  1135. from information_schema.columns where
  1136. table_schema='information_schema' and
  1137. (column_type = 'varchar(7)' or column_type = 'varchar(20)'
  1138. or column_type = 'varchar(27)')
  1139. group by column_type order by num;
  1140. column_type group_concat(table_schema, '.', table_name) num
  1141. varchar(27) information_schema.COLUMNS 1
  1142. varchar(7) information_schema.ROUTINES,information_schema.VIEWS 2
  1143. varchar(20) information_schema.FILES,information_schema.FILES,information_schema.PLUGINS,information_schema.PLUGINS,information_schema.PLUGINS,information_schema.PROFILING 6
  1144. create table t1(f1 char(1) not null, f2 char(9) not null)
  1145. default character set utf8;
  1146. select CHARACTER_MAXIMUM_LENGTH, CHARACTER_OCTET_LENGTH from
  1147. information_schema.columns where table_schema='test' and table_name = 't1';
  1148. CHARACTER_MAXIMUM_LENGTH CHARACTER_OCTET_LENGTH
  1149. 1 3
  1150. 9 27
  1151. drop table t1;
  1152. use mysql;
  1153. INSERT INTO `proc` VALUES ('test','','PROCEDURE','','SQL','CONTAINS_SQL',
  1154. 'NO','DEFINER','','','BEGIN\r\n \r\nEND','root@%','2006-03-02 18:40:03',
  1155. '2006-03-02 18:40:03','','','utf8','utf8_general_ci','utf8_general_ci','n/a');
  1156. select routine_name from information_schema.routines;
  1157. routine_name
  1158. delete from proc where name='';
  1159. use test;
  1160. grant select on test.* to mysqltest_1@localhost;
  1161. create table t1 (id int);
  1162. create view v1 as select * from t1;
  1163. create definer = mysqltest_1@localhost
  1164. sql security definer view v2 as select 1;
  1165. select * from information_schema.views
  1166. where table_name='v1' or table_name='v2';
  1167. TABLE_CATALOG TABLE_SCHEMA TABLE_NAME VIEW_DEFINITION CHECK_OPTION IS_UPDATABLE DEFINER SECURITY_TYPE CHARACTER_SET_CLIENT COLLATION_CONNECTION
  1168. NULL test v1 NONE YES root@localhost DEFINER latin1 latin1_swedish_ci
  1169. NULL test v2 select 1 AS `1` NONE NO mysqltest_1@localhost DEFINER latin1 latin1_swedish_ci
  1170. drop view v1, v2;
  1171. drop table t1;
  1172. drop user mysqltest_1@localhost;
  1173. set @a:= '.';
  1174. create table t1(f1 char(5));
  1175. create table t2(f1 char(5));
  1176. select concat(@a, table_name), @a, table_name
  1177. from information_schema.tables where table_schema = 'test';
  1178. concat(@a, table_name) @a table_name
  1179. .t1 . t1
  1180. .t2 . t2
  1181. drop table t1,t2;
  1182. DROP PROCEDURE IF EXISTS p1;
  1183. DROP FUNCTION IF EXISTS f1;
  1184. CREATE PROCEDURE p1() SET @a= 1;
  1185. CREATE FUNCTION f1() RETURNS INT RETURN @a + 1;
  1186. CREATE USER mysql_bug20230@localhost;
  1187. GRANT EXECUTE ON PROCEDURE p1 TO mysql_bug20230@localhost;
  1188. GRANT EXECUTE ON FUNCTION f1 TO mysql_bug20230@localhost;
  1189. SELECT ROUTINE_NAME, ROUTINE_DEFINITION FROM INFORMATION_SCHEMA.ROUTINES;
  1190. ROUTINE_NAME ROUTINE_DEFINITION
  1191. f1 RETURN @a + 1
  1192. p1 SET @a= 1
  1193. SHOW CREATE PROCEDURE p1;
  1194. Procedure sql_mode Create Procedure character_set_client collation_connection Database Collation
  1195. p1 CREATE DEFINER=`root`@`localhost` PROCEDURE `p1`()
  1196. SET @a= 1 latin1 latin1_swedish_ci latin1_swedish_ci
  1197. SHOW CREATE FUNCTION f1;
  1198. Function sql_mode Create Function character_set_client collation_connection Database Collation
  1199. f1 CREATE DEFINER=`root`@`localhost` FUNCTION `f1`() RETURNS int(11)
  1200. RETURN @a + 1 latin1 latin1_swedish_ci latin1_swedish_ci
  1201. SELECT ROUTINE_NAME, ROUTINE_DEFINITION FROM INFORMATION_SCHEMA.ROUTINES;
  1202. ROUTINE_NAME ROUTINE_DEFINITION
  1203. f1 NULL
  1204. p1 NULL
  1205. SHOW CREATE PROCEDURE p1;
  1206. Procedure sql_mode Create Procedure character_set_client collation_connection Database Collation
  1207. p1 NULL latin1 latin1_swedish_ci latin1_swedish_ci
  1208. SHOW CREATE FUNCTION f1;
  1209. Function sql_mode Create Function character_set_client collation_connection Database Collation
  1210. f1 NULL latin1 latin1_swedish_ci latin1_swedish_ci
  1211. CALL p1();
  1212. SELECT f1();
  1213. f1()
  1214. 2
  1215. DROP FUNCTION f1;
  1216. DROP PROCEDURE p1;
  1217. DROP USER mysql_bug20230@localhost;
  1218. SELECT t.table_name, c1.column_name
  1219. FROM information_schema.tables t
  1220. INNER JOIN
  1221. information_schema.columns c1
  1222. ON t.table_schema = c1.table_schema AND
  1223. t.table_name = c1.table_name
  1224. WHERE t.table_schema = 'information_schema' AND
  1225. c1.ordinal_position =
  1226. ( SELECT COALESCE(MIN(c2.ordinal_position),1)
  1227. FROM information_schema.columns c2
  1228. WHERE c2.table_schema = t.table_schema AND
  1229. c2.table_name = t.table_name AND
  1230. c2.column_name LIKE '%SCHEMA%'
  1231. );
  1232. table_name column_name
  1233. CHARACTER_SETS CHARACTER_SET_NAME
  1234. COLLATIONS COLLATION_NAME
  1235. COLLATION_CHARACTER_SET_APPLICABILITY COLLATION_NAME
  1236. COLUMNS TABLE_SCHEMA
  1237. COLUMN_PRIVILEGES TABLE_SCHEMA
  1238. ENGINES ENGINE
  1239. EVENTS EVENT_SCHEMA
  1240. FILES TABLE_SCHEMA
  1241. GLOBAL_STATUS VARIABLE_NAME
  1242. GLOBAL_VARIABLES VARIABLE_NAME
  1243. KEY_COLUMN_USAGE CONSTRAINT_SCHEMA
  1244. PARTITIONS TABLE_SCHEMA
  1245. PLUGINS PLUGIN_NAME
  1246. PROCESSLIST ID
  1247. PROFILING QUERY_ID
  1248. REFERENTIAL_CONSTRAINTS CONSTRAINT_SCHEMA
  1249. ROUTINES ROUTINE_SCHEMA
  1250. SCHEMATA SCHEMA_NAME
  1251. SCHEMA_PRIVILEGES TABLE_SCHEMA
  1252. SESSION_STATUS VARIABLE_NAME
  1253. SESSION_VARIABLES VARIABLE_NAME
  1254. STATISTICS TABLE_SCHEMA
  1255. TABLES TABLE_SCHEMA
  1256. TABLE_CONSTRAINTS CONSTRAINT_SCHEMA
  1257. TABLE_PRIVILEGES TABLE_SCHEMA
  1258. TRIGGERS TRIGGER_SCHEMA
  1259. USER_PRIVILEGES GRANTEE
  1260. VIEWS TABLE_SCHEMA
  1261. SELECT t.table_name, c1.column_name
  1262. FROM information_schema.tables t
  1263. INNER JOIN
  1264. information_schema.columns c1
  1265. ON t.table_schema = c1.table_schema AND
  1266. t.table_name = c1.table_name
  1267. WHERE t.table_schema = 'information_schema' AND
  1268. c1.ordinal_position =
  1269. ( SELECT COALESCE(MIN(c2.ordinal_position),1)
  1270. FROM information_schema.columns c2
  1271. WHERE c2.table_schema = 'information_schema' AND
  1272. c2.table_name = t.table_name AND
  1273. c2.column_name LIKE '%SCHEMA%'
  1274. );
  1275. table_name column_name
  1276. CHARACTER_SETS CHARACTER_SET_NAME
  1277. COLLATIONS COLLATION_NAME
  1278. COLLATION_CHARACTER_SET_APPLICABILITY COLLATION_NAME
  1279. COLUMNS TABLE_SCHEMA
  1280. COLUMN_PRIVILEGES TABLE_SCHEMA
  1281. ENGINES ENGINE
  1282. EVENTS EVENT_SCHEMA
  1283. FILES TABLE_SCHEMA
  1284. GLOBAL_STATUS VARIABLE_NAME
  1285. GLOBAL_VARIABLES VARIABLE_NAME
  1286. KEY_COLUMN_USAGE CONSTRAINT_SCHEMA
  1287. PARTITIONS TABLE_SCHEMA
  1288. PLUGINS PLUGIN_NAME
  1289. PROCESSLIST ID
  1290. PROFILING QUERY_ID
  1291. REFERENTIAL_CONSTRAINTS CONSTRAINT_SCHEMA
  1292. ROUTINES ROUTINE_SCHEMA
  1293. SCHEMATA SCHEMA_NAME
  1294. SCHEMA_PRIVILEGES TABLE_SCHEMA
  1295. SESSION_STATUS VARIABLE_NAME
  1296. SESSION_VARIABLES VARIABLE_NAME
  1297. STATISTICS TABLE_SCHEMA
  1298. TABLES TABLE_SCHEMA
  1299. TABLE_CONSTRAINTS CONSTRAINT_SCHEMA
  1300. TABLE_PRIVILEGES TABLE_SCHEMA
  1301. TRIGGERS TRIGGER_SCHEMA
  1302. USER_PRIVILEGES GRANTEE
  1303. VIEWS TABLE_SCHEMA
  1304. SELECT MAX(table_name) FROM information_schema.tables;
  1305. MAX(table_name)
  1306. VIEWS
  1307. SELECT table_name from information_schema.tables
  1308. WHERE table_name=(SELECT MAX(table_name)
  1309. FROM information_schema.tables);
  1310. table_name
  1311. VIEWS
  1312. DROP TABLE IF EXISTS bug23037;
  1313. DROP FUNCTION IF EXISTS get_value;
  1314. SELECT COLUMN_NAME, MD5(COLUMN_DEFAULT), LENGTH(COLUMN_DEFAULT) FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='bug23037';
  1315. COLUMN_NAME MD5(COLUMN_DEFAULT) LENGTH(COLUMN_DEFAULT)
  1316. fld1 7cf7a6782be951a1f2464a350da926a5 65532
  1317. SELECT MD5(get_value());
  1318. MD5(get_value())
  1319. 7cf7a6782be951a1f2464a350da926a5
  1320. SELECT COLUMN_NAME, MD5(COLUMN_DEFAULT), LENGTH(COLUMN_DEFAULT), COLUMN_DEFAULT=get_value() FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='bug23037';
  1321. COLUMN_NAME MD5(COLUMN_DEFAULT) LENGTH(COLUMN_DEFAULT) COLUMN_DEFAULT=get_value()
  1322. fld1 7cf7a6782be951a1f2464a350da926a5 65532 1
  1323. DROP TABLE bug23037;
  1324. DROP FUNCTION get_value;
  1325. create view v1 as
  1326. select table_schema as object_schema,
  1327. table_name as object_name,
  1328. table_type as object_type
  1329. from information_schema.tables
  1330. order by object_schema;
  1331. explain select * from v1;
  1332. id select_type table type possible_keys key key_len ref rows Extra
  1333. 1 SIMPLE tables ALL NULL NULL NULL NULL NULL Open_frm_only; Scanned all databases; Using filesort
  1334. explain select * from (select table_name from information_schema.tables) as a;
  1335. id select_type table type possible_keys key key_len ref rows Extra
  1336. 1 PRIMARY <derived2> system NULL NULL NULL NULL 0 const row not found
  1337. 2 DERIVED tables ALL NULL NULL NULL NULL NULL Skip_open_table; Scanned all databases
  1338. drop view v1;
  1339. create table t1 (f1 int(11));
  1340. create table t2 (f1 int(11), f2 int(11));
  1341. select table_name from information_schema.tables
  1342. where table_schema = 'test' and table_name not in
  1343. (select table_name from information_schema.columns
  1344. where table_schema = 'test' and column_name = 'f3');
  1345. table_name
  1346. t1
  1347. t2
  1348. drop table t1,t2;
  1349. select 1 as f1 from information_schema.tables where "CHARACTER_SETS"=
  1350. (select cast(table_name as char) from information_schema.tables
  1351. order by table_name limit 1) limit 1;
  1352. f1
  1353. 1
  1354. select t.table_name, group_concat(t.table_schema, '.', t.table_name),
  1355. count(*) as num1
  1356. from information_schema.tables t
  1357. inner join information_schema.columns c1
  1358. on t.table_schema = c1.table_schema AND t.table_name = c1.table_name
  1359. where t.table_schema = 'information_schema' and
  1360. c1.ordinal_position =
  1361. (select isnull(c2.column_type) -
  1362. isnull(group_concat(c2.table_schema, '.', c2.table_name)) +
  1363. count(*) as num
  1364. from information_schema.columns c2 where
  1365. c2.table_schema='information_schema' and
  1366. (c2.column_type = 'varchar(7)' or c2.column_type = 'varchar(20)')
  1367. group by c2.column_type order by num limit 1)
  1368. group by t.table_name order by num1, t.table_name;
  1369. table_name group_concat(t.table_schema, '.', t.table_name) num1
  1370. CHARACTER_SETS information_schema.CHARACTER_SETS 1
  1371. COLLATIONS information_schema.COLLATIONS 1
  1372. COLLATION_CHARACTER_SET_APPLICABILITY information_schema.COLLATION_CHARACTER_SET_APPLICABILITY 1
  1373. COLUMNS information_schema.COLUMNS 1
  1374. COLUMN_PRIVILEGES information_schema.COLUMN_PRIVILEGES 1
  1375. ENGINES information_schema.ENGINES 1
  1376. EVENTS information_schema.EVENTS 1
  1377. FILES information_schema.FILES 1
  1378. GLOBAL_STATUS information_schema.GLOBAL_STATUS 1
  1379. GLOBAL_VARIABLES information_schema.GLOBAL_VARIABLES 1
  1380. KEY_COLUMN_USAGE information_schema.KEY_COLUMN_USAGE 1
  1381. PARTITIONS information_schema.PARTITIONS 1
  1382. PLUGINS information_schema.PLUGINS 1
  1383. PROCESSLIST information_schema.PROCESSLIST 1
  1384. PROFILING information_schema.PROFILING 1
  1385. REFERENTIAL_CONSTRAINTS information_schema.REFERENTIAL_CONSTRAINTS 1
  1386. ROUTINES information_schema.ROUTINES 1
  1387. SCHEMATA information_schema.SCHEMATA 1
  1388. SCHEMA_PRIVILEGES information_schema.SCHEMA_PRIVILEGES 1
  1389. SESSION_STATUS information_schema.SESSION_STATUS 1
  1390. SESSION_VARIABLES information_schema.SESSION_VARIABLES 1
  1391. STATISTICS information_schema.STATISTICS 1
  1392. TABLES information_schema.TABLES 1
  1393. TABLE_CONSTRAINTS information_schema.TABLE_CONSTRAINTS 1
  1394. TABLE_PRIVILEGES information_schema.TABLE_PRIVILEGES 1
  1395. TRIGGERS information_schema.TRIGGERS 1
  1396. USER_PRIVILEGES information_schema.USER_PRIVILEGES 1
  1397. VIEWS information_schema.VIEWS 1
  1398. create table t1(f1 int);
  1399. create view v1 as select f1+1 as a from t1;
  1400. create table t2 (f1 int, f2 int);
  1401. create view v2 as select f1+1 as a, f2 as b from t2;
  1402. select table_name, is_updatable from information_schema.views;
  1403. table_name is_updatable
  1404. v1 NO
  1405. v2 YES
  1406. delete from v1;
  1407. drop view v1,v2;
  1408. drop table t1,t2;
  1409. alter database;
  1410. 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 1
  1411. alter database test;
  1412. 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 1
  1413. create database mysqltest;
  1414. create table mysqltest.t1(a int, b int, c int);
  1415. create trigger mysqltest.t1_ai after insert on mysqltest.t1
  1416. for each row set @a = new.a + new.b + new.c;
  1417. grant select(b) on mysqltest.t1 to mysqltest_1@localhost;
  1418. select trigger_name from information_schema.triggers
  1419. where event_object_table='t1';
  1420. trigger_name
  1421. t1_ai
  1422. show triggers from mysqltest;
  1423. Trigger Event Table Statement Timing Created sql_mode Definer character_set_client collation_connection Database Collation
  1424. t1_ai INSERT t1 set @a = new.a + new.b + new.c AFTER NULL root@localhost latin1 latin1_swedish_ci latin1_swedish_ci
  1425. show columns from t1;
  1426. Field Type Null Key Default Extra
  1427. b int(11) YES NULL
  1428. select column_name from information_schema.columns where table_name='t1';
  1429. column_name
  1430. b
  1431. show triggers;
  1432. Trigger Event Table Statement Timing Created sql_mode Definer character_set_client collation_connection Database Collation
  1433. select trigger_name from information_schema.triggers
  1434. where event_object_table='t1';
  1435. trigger_name
  1436. drop user mysqltest_1@localhost;
  1437. drop database mysqltest;
  1438. create table t1 (
  1439. f1 varchar(50),
  1440. f2 varchar(50) not null,
  1441. f3 varchar(50) default '',
  1442. f4 varchar(50) default NULL,
  1443. f5 bigint not null,
  1444. f6 bigint not null default 10,
  1445. f7 datetime not null,
  1446. f8 datetime default '2006-01-01'
  1447. );
  1448. select column_default from information_schema.columns where table_name= 't1';
  1449. column_default
  1450. NULL
  1451. NULL
  1452. NULL
  1453. NULL
  1454. 10
  1455. NULL
  1456. 2006-01-01 00:00:00
  1457. show columns from t1;
  1458. Field Type Null Key Default Extra
  1459. f1 varchar(50) YES NULL
  1460. f2 varchar(50) NO NULL
  1461. f3 varchar(50) YES
  1462. f4 varchar(50) YES NULL
  1463. f5 bigint(20) NO NULL
  1464. f6 bigint(20) NO 10
  1465. f7 datetime NO NULL
  1466. f8 datetime YES 2006-01-01 00:00:00
  1467. drop table t1;
  1468. show fields from information_schema.table_names;
  1469. ERROR 42S02: Unknown table 'table_names' in information_schema
  1470. show keys from information_schema.table_names;
  1471. ERROR 42S02: Unknown table 'table_names' in information_schema
  1472. USE information_schema;
  1473. SET max_heap_table_size = 16384;
  1474. CREATE TABLE test.t1( a INT );
  1475. SELECT *
  1476. FROM tables ta
  1477. JOIN collations co ON ( co.collation_name = ta.table_catalog )
  1478. JOIN character_sets cs ON ( cs.character_set_name = ta.table_catalog );
  1479. 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 MAXLEN
  1480. DROP TABLE test.t1;
  1481. SET max_heap_table_size = DEFAULT;
  1482. USE test;
  1483. End of 5.0 tests.
  1484. select * from information_schema.engines WHERE ENGINE="MyISAM";
  1485. ENGINE SUPPORT COMMENT TRANSACTIONS XA SAVEPOINTS
  1486. MyISAM DEFAULT Default engine as of MySQL 3.23 with great performance NO NO NO
  1487. grant select on *.* to user3148@localhost;
  1488. select user,db from information_schema.processlist;
  1489. user db
  1490. user3148 test
  1491. drop user user3148@localhost;
  1492. DROP TABLE IF EXISTS server_status;
  1493. DROP EVENT IF EXISTS event_status;
  1494. SET GLOBAL event_scheduler=1;
  1495. CREATE EVENT event_status
  1496. ON SCHEDULE AT NOW()
  1497. ON COMPLETION NOT PRESERVE
  1498. DO
  1499. BEGIN
  1500. CREATE TABLE server_status
  1501. SELECT variable_name
  1502. FROM information_schema.global_status
  1503. WHERE variable_name LIKE 'ABORTED_CONNECTS' OR
  1504. variable_name LIKE 'BINLOG_CACHE_DISK_USE';
  1505. END$$
  1506. SELECT variable_name FROM server_status;
  1507. variable_name
  1508. ABORTED_CONNECTS
  1509. BINLOG_CACHE_DISK_USE
  1510. DROP TABLE server_status;
  1511. SET GLOBAL event_scheduler=0;
  1512. explain select table_name from information_schema.views where
  1513. table_schema='test' and table_name='v1';
  1514. id select_type table type possible_keys key key_len ref rows Extra
  1515. 1 SIMPLE views ALL NULL TABLE_SCHEMA,TABLE_NAME NULL NULL NULL Using where; Open_frm_only; Scanned 0 databases
  1516. explain select * from information_schema.tables;
  1517. id select_type table type possible_keys key key_len ref rows Extra
  1518. 1 SIMPLE tables ALL NULL NULL NULL NULL NULL Open_full_table; Scanned all databases
  1519. explain select * from information_schema.collations;
  1520. id select_type table type possible_keys key key_len ref rows Extra
  1521. 1 SIMPLE collations ALL NULL NULL NULL NULL NULL
  1522. explain select * from information_schema.tables where
  1523. table_schema='test' and table_name= 't1';
  1524. id select_type table type possible_keys key key_len ref rows Extra
  1525. 1 SIMPLE tables ALL NULL TABLE_SCHEMA,TABLE_NAME NULL NULL NULL Using where; Open_full_table; Scanned 0 databases
  1526. explain select table_name, table_type from information_schema.tables
  1527. where table_schema='test';
  1528. id select_type table type possible_keys key key_len ref rows Extra
  1529. 1 SIMPLE tables ALL NULL TABLE_SCHEMA NULL NULL NULL Using where; Open_frm_only; Scanned 1 database
  1530. explain select b.table_name
  1531. from information_schema.tables a, information_schema.columns b
  1532. where a.table_name='t1' and a.table_schema='test' and b.table_name=a.table_name;
  1533. id select_type table type possible_keys key key_len ref rows Extra
  1534. 1 SIMPLE a ALL NULL TABLE_SCHEMA,TABLE_NAME NULL NULL NULL Using where; Skip_open_table; Scanned 0 databases
  1535. 1 SIMPLE b ALL NULL NULL NULL NULL NULL Using where; Open_frm_only; Scanned all databases; Using join buffer
  1536. SELECT * FROM INFORMATION_SCHEMA.SCHEMATA
  1537. WHERE SCHEMA_NAME = 'mysqltest';
  1538. CATALOG_NAME SCHEMA_NAME DEFAULT_CHARACTER_SET_NAME DEFAULT_COLLATION_NAME SQL_PATH
  1539. SELECT * FROM INFORMATION_SCHEMA.SCHEMATA
  1540. WHERE SCHEMA_NAME = '';
  1541. CATALOG_NAME SCHEMA_NAME DEFAULT_CHARACTER_SET_NAME DEFAULT_COLLATION_NAME SQL_PATH
  1542. SELECT * FROM INFORMATION_SCHEMA.SCHEMATA
  1543. WHERE SCHEMA_NAME = 'test';
  1544. CATALOG_NAME SCHEMA_NAME DEFAULT_CHARACTER_SET_NAME DEFAULT_COLLATION_NAME SQL_PATH
  1545. NULL test latin1 latin1_swedish_ci NULL
  1546. select count(*) from INFORMATION_SCHEMA.TABLES where TABLE_SCHEMA='mysql' AND TABLE_NAME='nonexisting';
  1547. count(*)
  1548. 0
  1549. select count(*) from INFORMATION_SCHEMA.TABLES where TABLE_SCHEMA='mysql' AND TABLE_NAME='';
  1550. count(*)
  1551. 0
  1552. select count(*) from INFORMATION_SCHEMA.TABLES where TABLE_SCHEMA='' AND TABLE_NAME='';
  1553. count(*)
  1554. 0
  1555. select count(*) from INFORMATION_SCHEMA.TABLES where TABLE_SCHEMA='' AND TABLE_NAME='nonexisting';
  1556. count(*)
  1557. 0
  1558. CREATE VIEW v1
  1559. AS SELECT *
  1560. FROM information_schema.tables;
  1561. SELECT VIEW_DEFINITION FROM INFORMATION_SCHEMA.VIEWS where TABLE_NAME = 'v1';
  1562. VIEW_DEFINITION
  1563. select `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`
  1564. DROP VIEW v1;
  1565. SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA
  1566. WHERE SCHEMA_NAME ='information_schema';
  1567. SCHEMA_NAME
  1568. information_schema
  1569. SELECT TABLE_COLLATION FROM INFORMATION_SCHEMA.TABLES
  1570. WHERE TABLE_SCHEMA='mysql' and TABLE_NAME= 'db';
  1571. TABLE_COLLATION
  1572. utf8_bin
  1573. select * from information_schema.columns where table_schema = NULL;
  1574. 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_COMMENT
  1575. select * from `information_schema`.`COLUMNS` where `TABLE_NAME` = NULL;
  1576. 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_COMMENT
  1577. select * from `information_schema`.`KEY_COLUMN_USAGE` where `TABLE_SCHEMA` = NULL;
  1578. 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_NAME
  1579. select * from `information_schema`.`KEY_COLUMN_USAGE` where `TABLE_NAME` = NULL;
  1580. 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_NAME
  1581. select * from `information_schema`.`PARTITIONS` where `TABLE_SCHEMA` = NULL;
  1582. 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_NAME
  1583. select * from `information_schema`.`PARTITIONS` where `TABLE_NAME` = NULL;
  1584. 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_NAME
  1585. select * from `information_schema`.`REFERENTIAL_CONSTRAINTS` where `CONSTRAINT_SCHEMA` = NULL;
  1586. 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_NAME
  1587. select * from `information_schema`.`REFERENTIAL_CONSTRAINTS` where `TABLE_NAME` = NULL;
  1588. 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_NAME
  1589. select * from information_schema.schemata where schema_name = NULL;
  1590. CATALOG_NAME SCHEMA_NAME DEFAULT_CHARACTER_SET_NAME DEFAULT_COLLATION_NAME SQL_PATH
  1591. select * from `information_schema`.`STATISTICS` where `TABLE_SCHEMA` = NULL;
  1592. 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 COMMENT
  1593. select * from `information_schema`.`STATISTICS` where `TABLE_NAME` = NULL;
  1594. 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 COMMENT
  1595. select * from information_schema.tables where table_schema = NULL;
  1596. 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
  1597. select * from information_schema.tables where table_catalog = NULL;
  1598. 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
  1599. select * from information_schema.tables where table_name = NULL;
  1600. 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
  1601. select * from `information_schema`.`TABLE_CONSTRAINTS` where `TABLE_SCHEMA` = NULL;
  1602. CONSTRAINT_CATALOG CONSTRAINT_SCHEMA CONSTRAINT_NAME TABLE_SCHEMA TABLE_NAME CONSTRAINT_TYPE
  1603. select * from `information_schema`.`TABLE_CONSTRAINTS` where `TABLE_NAME` = NULL;
  1604. CONSTRAINT_CATALOG CONSTRAINT_SCHEMA CONSTRAINT_NAME TABLE_SCHEMA TABLE_NAME CONSTRAINT_TYPE
  1605. select * from `information_schema`.`TRIGGERS` where `EVENT_OBJECT_SCHEMA` = NULL;
  1606. 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_COLLATION
  1607. select * from `information_schema`.`TRIGGERS` where `EVENT_OBJECT_TABLE` = NULL;
  1608. 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_COLLATION
  1609. select * from `information_schema`.`VIEWS` where `TABLE_SCHEMA` = NULL;
  1610. TABLE_CATALOG TABLE_SCHEMA TABLE_NAME VIEW_DEFINITION CHECK_OPTION IS_UPDATABLE DEFINER SECURITY_TYPE CHARACTER_SET_CLIENT COLLATION_CONNECTION
  1611. select * from `information_schema`.`VIEWS` where `TABLE_NAME` = NULL;
  1612. TABLE_CATALOG TABLE_SCHEMA TABLE_NAME VIEW_DEFINITION CHECK_OPTION IS_UPDATABLE DEFINER SECURITY_TYPE CHARACTER_SET_CLIENT COLLATION_CONNECTION
  1613. explain extended select 1 from information_schema.tables;
  1614. id select_type table type possible_keys key key_len ref rows filtered Extra
  1615. 1 SIMPLE tables ALL NULL NULL NULL NULL NULL NULL Skip_open_table; Scanned all databases
  1616. Warnings:
  1617. Note 1003 select 1 AS `1` from `information_schema`.`tables`
  1618. use information_schema;
  1619. show events;
  1620. Db Name Definer Time zone Type Execute at Interval value Interval field Starts Ends Status Originator character_set_client collation_connection Database Collation
  1621. show events from information_schema;
  1622. Db Name Definer Time zone Type Execute at Interval value Interval field Starts Ends Status Originator character_set_client collation_connection Database Collation
  1623. show events where Db= 'information_schema';
  1624. Db Name Definer Time zone Type Execute at Interval value Interval field Starts Ends Status Originator character_set_client collation_connection Database Collation
  1625. use test;
  1626. #
  1627. # Bug#34166: Server crash in SHOW OPEN TABLES and prelocking
  1628. #
  1629. drop table if exists t1;
  1630. drop function if exists f1;
  1631. create table t1 (a int);
  1632. create function f1() returns int
  1633. begin
  1634. insert into t1 (a) values (1);
  1635. return 0;
  1636. end|
  1637. show open tables where f1()=0;
  1638. show open tables where f1()=0;
  1639. drop table t1;
  1640. drop function f1;
  1641. select * from information_schema.tables where 1=sleep(100000);
  1642. select * from information_schema.columns where 1=sleep(100000);
  1643. explain select count(*) from information_schema.tables;
  1644. id select_type table type possible_keys key key_len ref rows Extra
  1645. 1 SIMPLE tables ALL NULL NULL NULL NULL NULL Skip_open_table; Scanned all databases
  1646. explain select count(*) from information_schema.columns;
  1647. id select_type table type possible_keys key key_len ref rows Extra
  1648. 1 SIMPLE columns ALL NULL NULL NULL NULL NULL Open_frm_only; Scanned all databases
  1649. explain select count(*) from information_schema.views;
  1650. id select_type table type possible_keys key key_len ref rows Extra
  1651. 1 SIMPLE views ALL NULL NULL NULL NULL NULL Open_frm_only; Scanned all databases
  1652. End of 5.1 tests.