Author: paul
Date: 2007-08-07 18:52:58 +0200 (Tue, 07 Aug 2007)
New Revision: 7373
Log:
r28475@polar: paul | 2007-08-07 11:50:02 -0500
Elevate changelog entry for Bug#11986 (and others relating to stored
program/view non-ASCII characters) to incompatible change, add upgrade
instructions. Add note to upgrading section.
Modified:
trunk/refman-5.1/installing.xml
trunk/refman-5.1/news-5.1.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:28474
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:23498
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:19268
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:28475
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:23498
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:19268
Modified: trunk/refman-5.1/installing.xml
===================================================================
--- trunk/refman-5.1/installing.xml 2007-08-07 16:52:41 UTC (rev 7372)
+++ trunk/refman-5.1/installing.xml 2007-08-07 16:52:58 UTC (rev 7373)
Changed blocks: 1, Lines Added: 22, Lines Deleted: 0; 1721 bytes
@@ -12303,6 +12303,28 @@
<listitem>
<para>
+ <emphasis role="bold">Incompatible change</emphasis>:
+ 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. To address these problems, the representation
+ for these objects was changed in MySQL 5.1.21. 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 <command>mysqldump</command> after
+ upgrading to 5.1.21 or higher, and then reload them to
+ recreate them with new definitions. Invoke
+ <command>mysqldump</command> with a
+ <option>--default-character-set</option> option that names
+ the non-ASCII character set that was used for the
+ definitions when the objects were originally defined.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
<emphasis role="bold">Incompatible change</emphasis>: As of
MySQL 5.1.20, <command>mysqld_safe</command> supports error
logging to <literal>syslog</literal> on systems that support
Modified: trunk/refman-5.1/news-5.1.xml
===================================================================
--- trunk/refman-5.1/news-5.1.xml 2007-08-07 16:52:41 UTC (rev 7372)
+++ trunk/refman-5.1/news-5.1.xml 2007-08-07 16:52:58 UTC (rev 7373)
Changed blocks: 2, Lines Added: 139, Lines Deleted: 125; 10836 bytes
@@ -172,6 +172,145 @@
<listitem>
<para>
+ <emphasis role="bold">Incompatible change</emphasis>: 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:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Parsing the original object definition so that it can be
+ stored.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Compiling the stored definition into executable form when
+ the object is invoked.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Retrieval of object definitions from
+ <literal>INFORMATION_SCHEMA</literal> tables.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Displaying the object definition in
+ <literal>SHOW</literal> statements. This issue also
+ affected <command>mysqldump</command>, which uses
+ <literal>SHOW</literal>.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ As a result of the patch, several tables have new columns:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ In the <literal>mysql</literal> database, the
+ <literal>proc</literal> and <literal>event</literal>
+ tables now have these columns:
+ <literal>character_set_client</literal>,
+ <literal>collation_connection</literal>,
+ <literal>db_collation</literal>,
+ <literal>body_utf8</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ In <literal>INFORMATION_SCHEMA</literal>, the
+ <literal>VIEWS</literal> table now has these columns:
+ <literal>CHARACTER_SET_CLIENT</literal>,
+ <literal>COLLATION_CONNECTION</literal>. The
+ <literal>ROUTINES</literal>, <literal>TRIGGERS</literal>,
+ and <literal>EVENT</literal> tables now have these
+ columns: <literal>CHARACTER_SET_CLIENT</literal>,
+ <literal>COLLATION_CONNECTION</literal>,
+ <literal>DATABASE_COLLATION</literal>.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ These columns store the session values of the
+ <literal>character_set_client</literal> and
+ <literal>collation_connection</literal> 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
+ <literal>collation_database</literal> system variable, which
+ applies to the default database; the database that contains
+ the object is not necessarily the default database.)
+ </para>
+
+ <para>
+ Several <literal>SHOW</literal> statements now display
+ additional columns corresponding to the new table columns.
+ These statements are: <literal>SHOW CREATE EVENT</literal>,
+ <literal>SHOW CREATE FUNCTION</literal>, <literal>SHOW CREATE
+ PROCEDURE</literal>, <literal>SHOW CREATE VIEW</literal>,
+ <literal>SHOW EVENTS</literal>, <literal>SHOW FUNCTION
+ STATUS</literal>, <literal>SHOW PROCEDURE STATUS</literal>,
+ <literal>SHOW TRIGGERS</literal>.
+ </para>
+
+ <para>
+ A new statement, <literal>SHOW CREATE TRIGGER</literal> is
+ introduced and is used by <command>mysqldump</command> for
+ producing <literal>CREATE TRIGGER</literal> statements.
+ </para>
+
+ <para>
+ (Bug #11986, Bug #16291, Bug #19443, Bug #21249, Bug #25212,
+ Bug #25221, Bug #30027)
+ </para>
+
+ <para>
+ Subsequent to the patch just described, it was discovered that
+ the patch broke <command>mysql_upgrade</command>. (Bug #30029)
+ </para>
+
+ <para>
+ <emphasis role="bold">Important</emphasis>: 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 <command>mysqldump</command> after upgrading to
+ 5.1.21, and then reload them to recreate them with new
+ definitions. Invoke <command>mysqldump</command> with a
+ <option>--default-character-set</option> option that names the
+ non-ASCII character set that was used for the definitions when
+ the objects were originally defined.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
<literal>NDB Cluster</literal> (Replication): Inconsistencies
could occur between the master and the slave when replicating
Disk Data tables. (Bug #19259)
@@ -1526,131 +1665,6 @@
<listitem>
<para>
- Several issues were identified for stored programs containing
- and views 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:
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- Parsing the original object definition so that it can be
- stored.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Compiling the stored definition into executable form when
- the object is invoked.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Retrieval of object definitions from
- <literal>INFORMATION_SCHEMA</literal> tables.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Displaying the object definition in
- <literal>SHOW</literal> statements. This issue also
- affected <command>mysqldump</command>, which uses
- <literal>SHOW</literal>.
- </para>
- </listitem>
-
- </itemizedlist>
-
- <para>
- 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.
- </para>
-
- <para>
- As a result of the patch, several tables have new columns:
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- In the <literal>mysql</literal> database, the
- <literal>proc</literal> and <literal>event</literal>
- tables now have these columns:
- <literal>character_set_client</literal>,
- <literal>collation_connection</literal>,
- <literal>db_collation</literal>,
- <literal>body_utf8</literal>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- In <literal>INFORMATION_SCHEMA</literal>, the
- <literal>VIEWS</literal> table now has these columns:
- <literal>CHARACTER_SET_CLIENT</literal>,
- <literal>COLLATION_CONNECTION</literal>. The
- <literal>ROUTINES</literal>, <literal>TRIGGERS</literal>,
- and <literal>EVENT</literal> tables now have these
- columns: <literal>CHARACTER_SET_CLIENT</literal>,
- <literal>COLLATION_CONNECTION</literal>,
- <literal>DATABASE_COLLATION</literal>.
- </para>
- </listitem>
-
- </itemizedlist>
-
- <para>
- These columns store the session values of the
- <literal>character_set_client</literal> and
- <literal>collation_connection</literal> 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
- <literal>collation_database</literal> system variable, which
- applies to the default database; the database that contains
- the object is not necessarily the default database.)
- </para>
-
- <para>
- Several <literal>SHOW</literal> statements now display
- additional columns corresponding to the new table columns.
- These statements are: <literal>SHOW CREATE EVENT</literal>,
- <literal>SHOW CREATE FUNCTION</literal>, <literal>SHOW CREATE
- PROCEDURE</literal>, <literal>SHOW CREATE VIEW</literal>,
- <literal>SHOW EVENTS</literal>, <literal>SHOW FUNCTION
- STATUS</literal>, <literal>SHOW PROCEDURE STATUS</literal>,
- <literal>SHOW TRIGGERS</literal>.
- </para>
-
- <para>
- A new statement, <literal>SHOW CREATE TRIGGER</literal> is
- introduced and is used by <command>mysqldump</command> for
- producing <literal>CREATE TRIGGER</literal> statements.
- </para>
-
- <para>
- (Bug #11986, Bug #16291, Bug #19443, Bug #21249, Bug #25212,
- Bug #25221, Bug #30027)
- </para>
-
- <para>
- Subsequent to the patch just described, it was discovered that
- the patch broke <command>mysql_upgrade</command>. (Bug #30029)
- </para>
- </listitem>
-
- <listitem>
- <para>
If a storage engine has its own logging capability, then any
statement using both this engine and some other engine not
having its own logging could not be correctly logged, due to
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r7373 - in trunk: . refman-5.1 | paul | 7 Aug |
