Skip navigation links

Additional languages
5.3.5 Changes in MySQL 5.1.20 (25 June 2007) »
Section Navigation      [Toggle]

5.3.4. Changes in MySQL 5.1.21 (16 August 2007)

Functionality added or changed:

  • Incompatible Change: In MySQL 5.1.6, when log tables were implemented, the default log destination for the general query and slow query log was TABLE. This default has been changed to FILE, which is compatible with MySQL 5.0, but incompatible with earlier releases of MySQL 5.1 from 5.1.6 to 5.1.20. If you are upgrading from MySQL 5.0 to this release, no logging option changes should be necessary. However, if you are upgrading from 5.1.6 through 5.1.20 to this release and were using TABLE logging, use the --log-output=TABLE option explicitly to preserve your server's table-logging behavior.

    In MySQL 5.1.x, this bug was addressed twice because it turned out that the default was set in two places, only one of which was fixed the first time. (Bug#29993)

  • Incompatible Change: The innodb_log_arch_dir system variable (which has been deprecated since MySQL 5.0.24) has been removed and should no longer be used.

  • Incompatible Change: On Windows only, the mysqld-nt has been removed from this release and all future releases. The mysqld server now includes named-pipe support as standard, and you do not have to use the mysqld-nt version to enable named-pipe support.

Bugs fixed:

  • Incompatible Change: Several issues were identified for stored programs (stored functions and procedures, triggers, and events) and views containing non-ASCII symbols. These issues involved conversion errors due to incomplete character set information when translating these objects to and from stored format, such as:

    • Parsing the original object definition so that it can be stored.

    • Compiling the stored definition into executable form when the object is invoked.

    • Retrieval of object definitions from INFORMATION_SCHEMA tables.

    • Displaying the object definition in SHOW statements. This issue also affected mysqldump, which uses SHOW.

    The fix for the problems is to store character set information from the object creation context so that this information is available when the object needs to be used later. The context includes the client character set, the connection character set and collation, and the collation of the database with which the object is associated.

    As a result of the patch, several tables have new columns:

    • In the mysql database, the proc and event tables now have these columns: character_set_client, collation_connection, db_collation, body_utf8.

    • In INFORMATION_SCHEMA, the VIEWS table now has these columns: CHARACTER_SET_CLIENT, COLLATION_CONNECTION. The ROUTINES, TRIGGERS, and EVENTS tables now have these columns: CHARACTER_SET_CLIENT, COLLATION_CONNECTION, DATABASE_COLLATION.

    These columns store the session values of the character_set_client and collation_connection system variables, and the collation of the database with which the object is associated. The values are those in effect at object creation time. (The saved database collation is not the value of the collation_database system variable, which applies to the default database; the database that contains the object is not necessarily the default database.)

    Several SHOW statements now display additional columns corresponding to the new table columns. These statements are: SHOW CREATE EVENT, SHOW CREATE FUNCTION, SHOW CREATE PROCEDURE, SHOW CREATE VIEW, SHOW EVENTS, SHOW FUNCTION STATUS, SHOW PROCEDURE STATUS, SHOW TRIGGERS.

    A new statement, SHOW CREATE TRIGGER is introduced and is used by mysqldump for producing CREATE TRIGGER statements.

    Subsequent to the patch just described, it was discovered that the patch broke mysql_upgrade; this has been corrected.

    Important

    The fixes for the problems just describe affect all existing stored programs and views. (For example, you will see warnings about “no creation context.”) To avoid warnings from the server about the use of old definitions from any release prior to 5.1.21, you should dump stored programs and views with mysqldump after upgrading to 5.1.21, and then reload them to recreate them with new definitions. Invoke mysqldump with a --default-character-set option that names the non-ASCII character set that was used for the definitions when the objects were originally defined.

    (Bug#25221, Bug#21249, Bug#30027, Bug#16291, Bug#11986, Bug#25212, Bug#19443, Bug#30029)