List:Commits« Previous MessageNext Message »
From:paul Date:January 15 2006 4:56am
Subject:svn commit - mysqldoc@docsrva: r834 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-common
View as plain text  
Author: paul
Date: 2006-01-15 05:56:50 +0100 (Sun, 15 Jan 2006)
New Revision: 834

Log:
 r6210@frost:  paul | 2006-01-14 19:55:11 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/charset.xml
   trunk/refman-4.1/installing.xml
   trunk/refman-4.1/language-structure.xml
   trunk/refman-5.0/charset.xml
   trunk/refman-5.0/installing.xml
   trunk/refman-5.0/language-structure.xml
   trunk/refman-5.1/charset.xml
   trunk/refman-5.1/installing.xml
   trunk/refman-5.1/language-structure.xml
   trunk/refman-common/titles.en.ent


Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6209
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2175
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6210
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2175

Modified: trunk/refman-4.1/charset.xml
===================================================================
--- trunk/refman-4.1/charset.xml	2006-01-15 04:56:33 UTC (rev 833)
+++ trunk/refman-4.1/charset.xml	2006-01-15 04:56:50 UTC (rev 834)
@@ -22,10 +22,6 @@
   </indexterm>
 
   <indexterm>
-    <primary>UTF8</primary>
-  </indexterm>
-
-  <indexterm>
     <primary>UTF-8</primary>
   </indexterm>
 
@@ -508,6 +504,12 @@
       </para>
 
       <para>
+        All database options are stored in a text file named
+        <filename>db.opt</filename> that can be found in the database
+        directory.
+      </para>
+
+      <para>
         The <literal>CHARACTER SET</literal> and
         <literal>COLLATE</literal> clauses make it possible to create
         databases with different character sets and collations on the
@@ -820,7 +822,8 @@
 </programlisting>
 
       <para>
-        MySQL determines a literal's character set and collation thus:
+        MySQL determines a literal's character set and collation in the
+        following manner:
       </para>
 
       <itemizedlist>
@@ -1464,6 +1467,26 @@
 SELECT * FROM t1 ORDER BY a COLLATE latin1_bin;
 </programlisting>
 
+      <para>
+        The <literal>BINARY</literal> attribute in character column
+        definitions has a similar effect. A character column defined
+        with the <literal>BINARY</literal> attribute is assigned the
+        binary collation of the column's character set.
+      </para>
+
+      <para>
+        The effect of <literal>BINARY</literal> in both contexts differs
+        from its effect prior to MySQL 4.1. Formerly,
+        <literal>BINARY</literal> resulted in binary string comparisons
+        or binary string column definitions. A binary string is a string
+        of bytes that has no character set or collation, which differs
+        from a non-binary character string that has a binary collation.
+        For both types of strings, comparisons are based on the numeric
+        values of the string unit, but for non-binary strings the unit
+        is the character and some character sets allow multi-byte
+        characters. <xref linkend="binary-varbinary"/>.
+      </para>
+
     </section>
 
     <section id="charset-collate-tricky">
@@ -1471,11 +1494,10 @@
       <title>&title-charset-collate-tricky;</title>
 
       <para>
-        In the great majority of queries, it is obvious what collation
-        MySQL uses to resolve a comparison operation. For example, in
-        the following cases, it should be clear that the collation is
-        <quote>the column collation of column
-        <literal>x</literal></quote>:
+        In the great majority of statements, it is obvious what
+        collation MySQL uses to resolve a comparison operation. For
+        example, in the following cases, it should be clear that the
+        collation is the collation of column <literal>x</literal>:
       </para>
 
 <programlisting>
@@ -1504,7 +1526,7 @@
         called <quote>coercibility</quote> rules. Basically, this means:
         Both <literal>x</literal> and <literal>'Y'</literal> have
         collations, so which collation takes precedence? This can be
-        difficult to resolve, but the following rules take care of most
+        difficult to resolve, but the following rules cover most
         situations:
       </para>
 
@@ -1560,7 +1582,7 @@
       </para>
 
       <para>
-        Those rules resolve ambiguities thus:
+        Those rules resolve ambiguities in the following manner:
       </para>
 
       <itemizedlist>
@@ -1637,9 +1659,9 @@
       <title>&title-charset-collation-charset;</title>
 
       <para>
-        Recall that each character set has one or more collations, and
-        each collation is associated with one and only one character
-        set. Therefore, the following statement causes an error message
+        Cach character set has one or more collations, but each
+        collation is associated with one and only one character set.
+        Therefore, the following statement causes an error message
         because the <literal>latin2_bin</literal> collation is not legal
         with the <literal>latin1</literal> character set:
       </para>
@@ -1760,8 +1782,8 @@
 </programlisting>
 
       <para>
-        The resulting order of the values for different collations is
-        shown in this table:
+        The following table shows the resulting order of the values if
+        we use <literal>ORDER BY</literal> with different collations:
       </para>
 
       <informaltable>
@@ -1800,10 +1822,8 @@
       </informaltable>
 
       <para>
-        The table is an example that shows what the effect would be if
-        we used different collations in an <literal>ORDER BY</literal>
-        clause. The character that causes the different sort orders in
-        this example is the U with two dots over it
+        The character that causes the different sort orders in this
+        example is the U with two dots over it
         (<literal>&uuml;</literal>), which the Germans call "U-umlaut".
       </para>
 
@@ -1873,15 +1893,18 @@
         <literal>RTRIM()</literal>, <literal>SOUNDEX()</literal>,
         <literal>SUBSTRING()</literal>, <literal>TRIM()</literal>,
         <literal>UCASE()</literal>, and <literal>UPPER()</literal>.
-        (Also note: The <literal>REPLACE()</literal> function, unlike
-        all other functions, always ignores the collation of the string
-        input and performs a case-sensitive comparison.)
       </para>
 
       <para>
+        Note: The <literal>REPLACE()</literal> function, unlike all
+        other functions, always ignores the collation of the string
+        input and performs a case-sensitive comparison.
+      </para>
+
+      <para>
         For operations that combine multiple string inputs and return a
         single string output, the <quote>aggregation rules</quote> of
-        standard SQL apply:
+        standard SQL apply for determining the collation of the result:
       </para>
 
       <itemizedlist>
@@ -1889,7 +1912,7 @@
         <listitem>
           <para>
             If an explicit <literal>COLLATE
-            <replaceable>X</replaceable></literal> occurs, then use
+            <replaceable>X</replaceable></literal> occurs, use
             <replaceable>X</replaceable>.
           </para>
         </listitem>
@@ -1898,7 +1921,7 @@
           <para>
             If explicit <literal>COLLATE
             <replaceable>X</replaceable></literal> and <literal>COLLATE
-            <replaceable>Y</replaceable></literal> occur, then raise an
+            <replaceable>Y</replaceable></literal> occur, raise an
             error.
           </para>
         </listitem>
@@ -1906,7 +1929,7 @@
         <listitem>
           <para>
             Otherwise, if all collations are
-            <replaceable>X</replaceable>, then use
+            <replaceable>X</replaceable>, use
             <replaceable>X</replaceable>.
           </para>
         </listitem>
@@ -1920,8 +1943,8 @@
       </itemizedlist>
 
       <para>
-        For example, with <literal>CASE ... WHEN a THEN b WHEN b THEN c
-        COLLATE <replaceable>X</replaceable> END</literal>, the
+        For example, with <literal>CASE &hellip; WHEN a THEN b WHEN b
+        THEN c COLLATE <replaceable>X</replaceable> END</literal>, the
         resulting collation is <replaceable>X</replaceable>. The same
         applies for <literal>CASE</literal>, <literal>UNION</literal>,
         <literal>||</literal>, <literal>CONCAT()</literal>,
@@ -1970,8 +1993,8 @@
 </programlisting>
 
       <para>
-        <literal>CONVERT(... USING ...)</literal> is implemented
-        according to the standard SQL specification.
+        <literal>CONVERT(&hellip; USING &hellip;)</literal> is
+        implemented according to the standard SQL specification.
       </para>
 
       <para>
@@ -1998,7 +2021,7 @@
         <literal>character_set_connection</literal> and
         <literal>collation_connection</literal> system variables. If you
         use <literal>CAST()</literal> with <literal>CHARACTER SET
-        X</literal>, then the resulting character set and collation are
+        X</literal>, the resulting character set and collation are
         <literal>X</literal> and the default collation of
         <literal>X</literal>.
       </para>
@@ -2006,8 +2029,8 @@
       <para>
         You may not use a <literal>COLLATE</literal> clause inside a
         <literal>CAST()</literal>, but you may use it outside. That is,
-        <literal>CAST(... COLLATE ...)</literal> is illegal, but
-        <literal>CAST(...) COLLATE ...</literal> is legal.
+        <literal>CAST(&hellip; COLLATE &hellip;)</literal> is illegal,
+        but <literal>CAST(&hellip;) COLLATE &hellip;</literal> is legal.
       </para>
 
       <para>
@@ -2030,7 +2053,8 @@
         <literal>SHOW CHARACTER SET</literal>, <literal>SHOW
         COLLATION</literal>, and <literal>SHOW CREATE DATABASE</literal>
         are new. <literal>SHOW CREATE TABLE</literal> and <literal>SHOW
-        COLUMNS</literal> are modified.
+        COLUMNS</literal> are modified. These statements are described
+        here briefly. For more information, see <xref linkend="show"/>.
       </para>
 
       <para>
@@ -2053,10 +2077,6 @@
 </programlisting>
 
       <para>
-        See <xref linkend="show-character-set"/>.
-      </para>
-
-      <para>
         The output from <literal>SHOW COLLATION</literal> includes all
         available character sets. It takes an optional
         <literal>LIKE</literal> clause that indicates which collation
@@ -2080,17 +2100,9 @@
 </programlisting>
 
       <para>
-        See <xref linkend="show-collation"/>.
-      </para>
-
-      <para>
         <literal>SHOW CREATE DATABASE</literal> displays the
         <literal>CREATE DATABASE</literal> statement that creates a
-        given database. The result includes all database options.
-        <literal>DEFAULT CHARACTER SET</literal> and
-        <literal>COLLATE</literal> are supported. All database options
-        are stored in a text file named <filename>db.opt</filename> that
-        can be found in the database directory.
+        given database:
       </para>
 
 <programlisting>
@@ -2103,7 +2115,8 @@
 </programlisting>
 
       <para>
-        See <xref linkend="show-create-database"/>.
+        If no <literal>COLLATE</literal> clause is shown, the default
+        collation for the character set applies.
       </para>
 
       <para>
@@ -2115,17 +2128,13 @@
       </para>
 
       <para>
-        See <xref linkend="show-create-table"/>.
-      </para>
-
-      <para>
         The <literal>SHOW COLUMNS</literal> statement displays the
         collations of a table's columns when invoked as <literal>SHOW
         FULL COLUMNS</literal>. Columns with <literal>CHAR</literal>,
         <literal>VARCHAR</literal>, or <literal>TEXT</literal> data
-        types have non-<literal>NULL</literal> collations. Numeric and
-        other non-character types have <literal>NULL</literal>
-        collations. For example:
+        types have collations. Numeric and other non-character types
+        have no collation (indicated by <literal>NULL</literal> as the
+        <literal>Collation</literal> value). For example:
       </para>
 
 <programlisting>
@@ -2154,14 +2163,10 @@
 </programlisting>
 
       <para>
-        The character set is not part of the display. (The character set
-        name is implied by the collation name.)
+        The character set is not part of the display but is implied by
+        the collation name.
       </para>
 
-      <para>
-        See <xref linkend="show-columns"/>.
-      </para>
-
     </section>
 
   </section>
@@ -2185,7 +2190,7 @@
 
       <listitem>
         <para>
-          <literal>utf8</literal>, the UTF8 encoding of the Unicode
+          <literal>utf8</literal>, the UTF-8 encoding of the Unicode
           character set.
         </para>
       </listitem>
@@ -2196,10 +2201,11 @@
       In UCS-2 (binary Unicode representation), every character is
       represented by a two-byte Unicode code with the most significant
       byte first. For example: "LATIN CAPITAL LETTER A" has the code
-      0x0041 and it's stored as a two-byte sequence: 0x00 0x41.
-      "CYRILLIC SMALL LETTER YERU" (Unicode 0x044B) is stored as a
-      two-byte sequence: 0x04 0x4B. For Unicode characters and their
-      codes, please refer to the
+      <literal>0x0041</literal> and it is stored as a two-byte sequence:
+      <literal>0x00 0x41</literal>. "CYRILLIC SMALL LETTER YERU"
+      (Unicode <literal>0x044B</literal>) is stored as a two-byte
+      sequence: <literal>0x04 0x4B</literal>. For Unicode characters and
+      their codes, please refer to the
       <ulink url="http://www.unicode.org/">Unicode Home Page</ulink>.
     </para>
 
@@ -2209,9 +2215,9 @@
     </para>
 
     <para>
-      The UTF8 character set (transform Unicode representation) is an
+      The UTF-8 character set (transform Unicode representation) is an
       alternative way to store Unicode data. It is implemented according
-      to RFC 3629. The idea of the UTF8 character set is that various
+      to RFC 3629. The idea of the UTF-8 character set is that various
       Unicode characters are encoded using byte sequences of different
       lengths:
     </para>
@@ -2245,19 +2251,20 @@
 
     <para>
       RFC 3629 describes encoding sequences that take from one to four
-      bytes. Currently, MySQL UTF8 support does not include four-byte
-      sequences. (An older standard for UTF8 encoding is given by RFC
-      2279, which describes UTF8 sequences that take from one to six
-      bytes. RFC 3629 renders RFC 2279 obsolete; for this reason,
-      sequences with five and six bytes are no longer used.)
+      bytes. Currently, MySQL support for UTF-8 does not include
+      four-byte sequences. (An older standard for UTF-8 encoding is
+      given by RFC 2279, which describes UTF-8 sequences that take from
+      one to six bytes. RFC 3629 renders RFC 2279 obsolete; for this
+      reason, sequences with five and six bytes are no longer used.)
     </para>
 
     <para>
-      <emphasis role="bold">Tip</emphasis>: To save space with UTF8, use
-      <literal>VARCHAR</literal> instead of <literal>CHAR</literal>.
-      Otherwise, MySQL has to reserve 30 bytes for a <literal>CHAR(10)
-      CHARACTER SET utf8</literal> column, because this is the maximum
-      possible length.
+      <emphasis role="bold">Tip</emphasis>: To save space with UTF-8,
+      use <literal>VARCHAR</literal> instead of <literal>CHAR</literal>.
+      Otherwise, MySQL must reserve three bytes for each character in a
+      <literal>CHAR CHARACTER SET utf8</literal> column because that is
+      the maximum possible length. For example, MySQL must reserve 30
+      bytes for a <literal>CHAR(10) CHARACTER SET utf8</literal> column.
     </para>
 
   </section>
@@ -2303,16 +2310,16 @@
 
     <para>
       In order to satisfy both requirements, MySQL stores metadata in a
-      Unicode character set, namely UTF8. This does not cause any
+      Unicode character set, namely UTF-8. This does not cause any
       disruption if you never use accented characters. But if you do,
-      you should be aware that metadata is in UTF8.
+      you should be aware that metadata is in UTF-8.
     </para>
 
     <para>
       This means that the return values of the
       <literal>USER()</literal>, <literal>CURRENT_USER()</literal>,
       <literal>DATABASE()</literal>, and <literal>VERSION()</literal>
-      functions have the UTF8 character set by default, as do synonyms
+      functions have the UTF-8 character set by default, as do synonyms
       such as <literal>SESSION_USER()</literal> and
       <literal>SYSTEM_USER()</literal>.
     </para>
@@ -2349,9 +2356,9 @@
     </para>
 
     <para>
-      If you want the server to pass metadata results back in a non-UTF8
-      character set, then use <literal>SET NAMES</literal> to force the
-      server to perform character set conversion (see
+      If you want the server to pass metadata results back in a
+      non-UTF-8 character set, then use <literal>SET NAMES</literal> to
+      force the server to perform character set conversion (see
       <xref linkend="charset-connection"/>), or else set the client to
       do the conversion. It is always more efficient to set the client
       to do the conversion, but this option is not available for many
@@ -2371,7 +2378,7 @@
     <para>
       This works because the contents of
       <literal>latin1_column</literal> are automatically converted to
-      UTF8 before the comparison.
+      UTF-8 before the comparison.
     </para>
 
 <programlisting>
@@ -2397,8 +2404,9 @@
 
     <para>
       <emphasis role="bold">Note</emphasis>: Beginning with MySQL 4.1.1,
-      the <filename>errmsg.txt</filename> files all use UTF8. Conversion
-      to the client character set is automatic, as with metadata.
+      the <filename>errmsg.txt</filename> files all use UTF-8.
+      Conversion to the client character set is automatic, as with
+      metadata.
     </para>
 
   </section>

Modified: trunk/refman-4.1/installing.xml
===================================================================
--- trunk/refman-4.1/installing.xml	2006-01-15 04:56:33 UTC (rev 833)
+++ trunk/refman-4.1/installing.xml	2006-01-15 04:56:50 UTC (rev 834)
@@ -3855,8 +3855,8 @@
             <para>
               <guimenuitem>Best Support For
               Multilingualism</guimenuitem>: Choose this option if you
-              want to use <literal>UTF8</literal> as the default server
-              character set. <literal>UTF8</literal> can store
+              want to use <literal>utf8</literal> as the default server
+              character set. <literal>utf8</literal> can store
               characters from many different languages in a single
               character set.
             </para>
@@ -12302,7 +12302,7 @@
 
             <listitem>
               <para>
-                If you have used column prefix indexes on UTF8 columns
+                If you have used column prefix indexes on UTF-8 columns
                 or other multi-byte character set columns in MySQL 4.1.0
                 to 4.1.5, you must rebuild the tables when you upgrade
                 to MySQL 4.1.6 or later.
@@ -12315,9 +12315,9 @@
                 values of 128 to 255) in database names, table names,
                 constraint names, or column names in versions of MySQL
                 earlier than 4.1, you cannot upgrade to MySQL 4.1
-                directly, because 4.1 uses UTF8 to store metadata names.
-                Use <literal>RENAME TABLE</literal> to overcome this if
-                the accent character is in the table name or the
+                directly, because 4.1 uses UTF-8 to store metadata
+                names. Use <literal>RENAME TABLE</literal> to overcome
+                this if the accent character is in the table name or the
                 database name, or rebuild the table.
               </para>
             </listitem>
@@ -12429,7 +12429,7 @@
           <para>
             <emphasis role="bold">Important note:</emphasis> MySQL 4.1
             stores table names and column names in
-            <literal>UTF8</literal>. If you have table names or column
+            <literal>utf8</literal>. If you have table names or column
             names that use characters outside of the standard 7-bit
             US-ASCII range, you may have to do a
             <command>mysqldump</command> of your tables in MySQL 4.0 and
@@ -12490,7 +12490,7 @@
             character set using the instructions in
             <xref linkend="charset-conversion"/>. Also, database, table,
             and column identifiers are stored internally using Unicode
-            (UTF8) regardless of the default character set. See
+            (UTF-8) regardless of the default character set. See
             <xref linkend="legal-names"/>.
           </para>
         </listitem>

Modified: trunk/refman-4.1/language-structure.xml
===================================================================
--- trunk/refman-4.1/language-structure.xml	2006-01-15 04:56:33 UTC (rev 833)
+++ trunk/refman-4.1/language-structure.xml	2006-01-15 04:56:50 UTC (rev 834)
@@ -809,7 +809,7 @@
 
     <para>
       Beginning with MySQL 4.1, identifiers are stored using Unicode
-      (UTF8). This applies to identifiers in table definitions that
+      (UTF-8). This applies to identifiers in table definitions that
       stored in <filename>.frm</filename> files and to identifiers
       stored in the grant tables in the <literal>mysql</literal>
       database. Although Unicode identifiers can include multi-byte

Modified: trunk/refman-5.0/charset.xml
===================================================================
--- trunk/refman-5.0/charset.xml	2006-01-15 04:56:33 UTC (rev 833)
+++ trunk/refman-5.0/charset.xml	2006-01-15 04:56:50 UTC (rev 834)
@@ -22,10 +22,6 @@
   </indexterm>
 
   <indexterm>
-    <primary>UTF8</primary>
-  </indexterm>
-
-  <indexterm>
     <primary>UTF-8</primary>
   </indexterm>
 
@@ -495,6 +491,12 @@
       </para>
 
       <para>
+        All database options are stored in a text file named
+        <filename>db.opt</filename> that can be found in the database
+        directory.
+      </para>
+
+      <para>
         The <literal>CHARACTER SET</literal> and
         <literal>COLLATE</literal> clauses make it possible to create
         databases with different character sets and collations on the
@@ -807,7 +809,8 @@
 </programlisting>
 
       <para>
-        MySQL determines a literal's character set and collation thus:
+        MySQL determines a literal's character set and collation in the
+        following manner:
       </para>
 
       <itemizedlist>
@@ -1456,6 +1459,26 @@
 SELECT * FROM t1 ORDER BY a COLLATE latin1_bin;
 </programlisting>
 
+      <para>
+        The <literal>BINARY</literal> attribute in character column
+        definitions has a similar effect. A character column defined
+        with the <literal>BINARY</literal> attribute is assigned the
+        binary collation of the column's character set.
+      </para>
+
+      <para>
+        The effect of <literal>BINARY</literal> in both contexts differs
+        from its effect prior to MySQL 4.1. Formerly,
+        <literal>BINARY</literal> resulted in binary string comparisons
+        or binary string column definitions. A binary string is a string
+        of bytes that has no character set or collation, which differs
+        from a non-binary character string that has a binary collation.
+        For both types of strings, comparisons are based on the numeric
+        values of the string unit, but for non-binary strings the unit
+        is the character and some character sets allow multi-byte
+        characters. <xref linkend="binary-varbinary"/>.
+      </para>
+
     </section>
 
     <section id="charset-collate-tricky">
@@ -1463,11 +1486,10 @@
       <title>&title-charset-collate-tricky;</title>
 
       <para>
-        In the great majority of queries, it is obvious what collation
-        MySQL uses to resolve a comparison operation. For example, in
-        the following cases, it should be clear that the collation is
-        <quote>the column collation of column
-        <literal>x</literal></quote>:
+        In the great majority of statements, it is obvious what
+        collation MySQL uses to resolve a comparison operation. For
+        example, in the following cases, it should be clear that the
+        collation is the collation of column <literal>x</literal>:
       </para>
 
 <programlisting>
@@ -1496,7 +1518,7 @@
         called <quote>coercibility</quote> rules. Basically, this means:
         Both <literal>x</literal> and <literal>'Y'</literal> have
         collations, so which collation takes precedence? This can be
-        difficult to resolve, but the following rules take care of most
+        difficult to resolve, but the following rules cover most
         situations:
       </para>
 
@@ -1552,7 +1574,7 @@
       </para>
 
       <para>
-        Those rules resolve ambiguities thus:
+        Those rules resolve ambiguities in the following manner:
       </para>
 
       <itemizedlist>
@@ -1629,9 +1651,9 @@
       <title>&title-charset-collation-charset;</title>
 
       <para>
-        Recall that each character set has one or more collations, and
-        each collation is associated with one and only one character
-        set. Therefore, the following statement causes an error message
+        Cach character set has one or more collations, but each
+        collation is associated with one and only one character set.
+        Therefore, the following statement causes an error message
         because the <literal>latin2_bin</literal> collation is not legal
         with the <literal>latin1</literal> character set:
       </para>
@@ -1671,8 +1693,8 @@
 </programlisting>
 
       <para>
-        The resulting order of the values for different collations is
-        shown in this table:
+        The following table shows the resulting order of the values if
+        we use <literal>ORDER BY</literal> with different collations:
       </para>
 
       <informaltable>
@@ -1711,10 +1733,8 @@
       </informaltable>
 
       <para>
-        The table is an example that shows what the effect would be if
-        we used different collations in an <literal>ORDER BY</literal>
-        clause. The character that causes the different sort orders in
-        this example is the U with two dots over it
+        The character that causes the different sort orders in this
+        example is the U with two dots over it
         (<literal>&uuml;</literal>), which the Germans call "U-umlaut".
       </para>
 
@@ -1756,7 +1776,7 @@
 
     <para>
       This section describes operations that take character set
-      information into account in MySQL &current-series;.
+      information into account.
     </para>
 
     <section id="charset-result">
@@ -1784,15 +1804,18 @@
         <literal>RTRIM()</literal>, <literal>SOUNDEX()</literal>,
         <literal>SUBSTRING()</literal>, <literal>TRIM()</literal>,
         <literal>UCASE()</literal>, and <literal>UPPER()</literal>.
-        (Also note: The <literal>REPLACE()</literal> function, unlike
-        all other functions, always ignores the collation of the string
-        input and performs a case-sensitive comparison.)
       </para>
 
       <para>
+        Note: The <literal>REPLACE()</literal> function, unlike all
+        other functions, always ignores the collation of the string
+        input and performs a case-sensitive comparison.
+      </para>
+
+      <para>
         For operations that combine multiple string inputs and return a
         single string output, the <quote>aggregation rules</quote> of
-        standard SQL apply:
+        standard SQL apply for determining the collation of the result:
       </para>
 
       <itemizedlist>
@@ -1800,7 +1823,7 @@
         <listitem>
           <para>
             If an explicit <literal>COLLATE
-            <replaceable>X</replaceable></literal> occurs, then use
+            <replaceable>X</replaceable></literal> occurs, use
             <replaceable>X</replaceable>.
           </para>
         </listitem>
@@ -1809,7 +1832,7 @@
           <para>
             If explicit <literal>COLLATE
             <replaceable>X</replaceable></literal> and <literal>COLLATE
-            <replaceable>Y</replaceable></literal> occur, then raise an
+            <replaceable>Y</replaceable></literal> occur, raise an
             error.
           </para>
         </listitem>
@@ -1817,7 +1840,7 @@
         <listitem>
           <para>
             Otherwise, if all collations are
-            <replaceable>X</replaceable>, then use
+            <replaceable>X</replaceable>, use
             <replaceable>X</replaceable>.
           </para>
         </listitem>
@@ -1831,8 +1854,8 @@
       </itemizedlist>
 
       <para>
-        For example, with <literal>CASE ... WHEN a THEN b WHEN b THEN c
-        COLLATE <replaceable>X</replaceable> END</literal>, the
+        For example, with <literal>CASE &hellip; WHEN a THEN b WHEN b
+        THEN c COLLATE <replaceable>X</replaceable> END</literal>, the
         resulting collation is <replaceable>X</replaceable>. The same
         applies for <literal>CASE</literal>, <literal>UNION</literal>,
         <literal>||</literal>, <literal>CONCAT()</literal>,
@@ -1881,8 +1904,8 @@
 </programlisting>
 
       <para>
-        <literal>CONVERT(... USING ...)</literal> is implemented
-        according to the standard SQL specification.
+        <literal>CONVERT(&hellip; USING &hellip;)</literal> is
+        implemented according to the standard SQL specification.
       </para>
 
       <para>
@@ -1909,7 +1932,7 @@
         <literal>character_set_connection</literal> and
         <literal>collation_connection</literal> system variables. If you
         use <literal>CAST()</literal> with <literal>CHARACTER SET
-        X</literal>, then the resulting character set and collation are
+        X</literal>, the resulting character set and collation are
         <literal>X</literal> and the default collation of
         <literal>X</literal>.
       </para>
@@ -1917,8 +1940,8 @@
       <para>
         You may not use a <literal>COLLATE</literal> clause inside a
         <literal>CAST()</literal>, but you may use it outside. That is,
-        <literal>CAST(... COLLATE ...)</literal> is illegal, but
-        <literal>CAST(...) COLLATE ...</literal> is legal.
+        <literal>CAST(&hellip; COLLATE &hellip;)</literal> is illegal,
+        but <literal>CAST(&hellip;) COLLATE &hellip;</literal> is legal.
       </para>
 
       <para>
@@ -1940,10 +1963,23 @@
         character set information. These include <literal>SHOW CHARACTER
         SET</literal>, <literal>SHOW COLLATION</literal>, <literal>SHOW
         CREATE DATABASE</literal>, <literal>SHOW CREATE TABLE</literal>
-        and <literal>SHOW COLUMNS</literal>.
+        and <literal>SHOW COLUMNS</literal>. These statements are
+        described here briefly. For more information, see
+        <xref linkend="show"/>.
       </para>
 
       <para>
+        <literal>INFORMATION_SCHEMA</literal> has several tables that
+        contain information information similar to that displayed by the
+        <literal>SHOW</literal> statements. For example, the
+        <literal>CHARACTER_SETS</literal> and
+        <literal>COLLATIONS</literal> tables contain the information
+        displayed by <literal>SHOW CHARACTER SET</literal> and
+        <literal>SHOW COLLATION</literal>.
+        <xref linkend="information-schema"/>.
+      </para>
+
+      <para>
         The <literal>SHOW CHARACTER SET</literal> command shows all
         available character sets. It takes an optional
         <literal>LIKE</literal> clause that indicates which character
@@ -1963,10 +1999,6 @@
 </programlisting>
 
       <para>
-        See <xref linkend="show-character-set"/>.
-      </para>
-
-      <para>
         The output from <literal>SHOW COLLATION</literal> includes all
         available character sets. It takes an optional
         <literal>LIKE</literal> clause that indicates which collation
@@ -1990,17 +2022,9 @@
 </programlisting>
 
       <para>
-        See <xref linkend="show-collation"/>.
-      </para>
-
-      <para>
         <literal>SHOW CREATE DATABASE</literal> displays the
         <literal>CREATE DATABASE</literal> statement that creates a
-        given database. The result includes all database options.
-        <literal>DEFAULT CHARACTER SET</literal> and
-        <literal>COLLATE</literal> are supported. All database options
-        are stored in a text file named <filename>db.opt</filename> that
-        can be found in the database directory.
+        given database:
       </para>
 
 <programlisting>
@@ -2013,7 +2037,8 @@
 </programlisting>
 
       <para>
-        See <xref linkend="show-create-database"/>.
+        If no <literal>COLLATE</literal> clause is shown, the default
+        collation for the character set applies.
       </para>
 
       <para>
@@ -2025,17 +2050,13 @@
       </para>
 
       <para>
-        See <xref linkend="show-create-table"/>.
-      </para>
-
-      <para>
         The <literal>SHOW COLUMNS</literal> statement displays the
         collations of a table's columns when invoked as <literal>SHOW
         FULL COLUMNS</literal>. Columns with <literal>CHAR</literal>,
         <literal>VARCHAR</literal>, or <literal>TEXT</literal> data
-        types have non-<literal>NULL</literal> collations. Numeric and
-        other non-character types have <literal>NULL</literal>
-        collations. For example:
+        types have collations. Numeric and other non-character types
+        have no collation (indicated by <literal>NULL</literal> as the
+        <literal>Collation</literal> value). For example:
       </para>
 
 <programlisting>
@@ -2064,14 +2085,10 @@
 </programlisting>
 
       <para>
-        The character set is not part of the display. (The character set
-        name is implied by the collation name.)
+        The character set is not part of the display but is implied by
+        the collation name.
       </para>
 
-      <para>
-        See <xref linkend="show-columns"/>.
-      </para>
-
     </section>
 
   </section>
@@ -2095,7 +2112,7 @@
 
       <listitem>
         <para>
-          <literal>utf8</literal>, the UTF8 encoding of the Unicode
+          <literal>utf8</literal>, the UTF-8 encoding of the Unicode
           character set.
         </para>
       </listitem>
@@ -2106,10 +2123,11 @@
       In UCS-2 (binary Unicode representation), every character is
       represented by a two-byte Unicode code with the most significant
       byte first. For example: "LATIN CAPITAL LETTER A" has the code
-      0x0041 and it's stored as a two-byte sequence: 0x00 0x41.
-      "CYRILLIC SMALL LETTER YERU" (Unicode 0x044B) is stored as a
-      two-byte sequence: 0x04 0x4B. For Unicode characters and their
-      codes, please refer to the
+      <literal>0x0041</literal> and it is stored as a two-byte sequence:
+      <literal>0x00 0x41</literal>. "CYRILLIC SMALL LETTER YERU"
+      (Unicode <literal>0x044B</literal>) is stored as a two-byte
+      sequence: <literal>0x04 0x4B</literal>. For Unicode characters and
+      their codes, please refer to the
       <ulink url="http://www.unicode.org/">Unicode Home Page</ulink>.
     </para>
 
@@ -2119,9 +2137,9 @@
     </para>
 
     <para>
-      The UTF8 character set (transform Unicode representation) is an
+      The UTF-8 character set (transform Unicode representation) is an
       alternative way to store Unicode data. It is implemented according
-      to RFC 3629. The idea of the UTF8 character set is that various
+      to RFC 3629. The idea of the UTF-8 character set is that various
       Unicode characters are encoded using byte sequences of different
       lengths:
     </para>
@@ -2155,19 +2173,20 @@
 
     <para>
       RFC 3629 describes encoding sequences that take from one to four
-      bytes. Currently, MySQL UTF8 support does not include four-byte
-      sequences. (An older standard for UTF8 encoding is given by RFC
-      2279, which describes UTF8 sequences that take from one to six
-      bytes. RFC 3629 renders RFC 2279 obsolete; for this reason,
-      sequences with five and six bytes are no longer used.)
+      bytes. Currently, MySQL support for UTF-8 does not include
+      four-byte sequences. (An older standard for UTF-8 encoding is
+      given by RFC 2279, which describes UTF-8 sequences that take from
+      one to six bytes. RFC 3629 renders RFC 2279 obsolete; for this
+      reason, sequences with five and six bytes are no longer used.)
     </para>
 
     <para>
-      <emphasis role="bold">Tip</emphasis>: To save space with UTF8, use
-      <literal>VARCHAR</literal> instead of <literal>CHAR</literal>.
-      Otherwise, MySQL has to reserve 30 bytes for a <literal>CHAR(10)
-      CHARACTER SET utf8</literal> column, because this is the maximum
-      possible length.
+      <emphasis role="bold">Tip</emphasis>: To save space with UTF-8,
+      use <literal>VARCHAR</literal> instead of <literal>CHAR</literal>.
+      Otherwise, MySQL must reserve three bytes for each character in a
+      <literal>CHAR CHARACTER SET utf8</literal> column because that is
+      the maximum possible length. For example, MySQL must reserve 30
+      bytes for a <literal>CHAR(10) CHARACTER SET utf8</literal> column.
     </para>
 
   </section>
@@ -2218,16 +2237,16 @@
 
     <para>
       In order to satisfy both requirements, MySQL stores metadata in a
-      Unicode character set, namely UTF8. This does not cause any
+      Unicode character set, namely UTF-8. This does not cause any
       disruption if you never use accented characters. But if you do,
-      you should be aware that metadata is in UTF8.
+      you should be aware that metadata is in UTF-8.
     </para>
 
     <para>
       This means that the return values of the
       <literal>USER()</literal>, <literal>CURRENT_USER()</literal>,
       <literal>DATABASE()</literal>, and <literal>VERSION()</literal>
-      functions have the UTF8 character set by default, as do synonyms
+      functions have the UTF-8 character set by default, as do synonyms
       such as <literal>SESSION_USER()</literal> and
       <literal>SYSTEM_USER()</literal>.
     </para>
@@ -2264,9 +2283,9 @@
     </para>
 
     <para>
-      If you want the server to pass metadata results back in a non-UTF8
-      character set, then use <literal>SET NAMES</literal> to force the
-      server to perform character set conversion (see
+      If you want the server to pass metadata results back in a
+      non-UTF-8 character set, then use <literal>SET NAMES</literal> to
+      force the server to perform character set conversion (see
       <xref linkend="charset-connection"/>), or else cause the client to
       perform the conversion. It is more efficient to have the client
       perform the conversion, but this option is not always available
@@ -2286,7 +2305,7 @@
     <para>
       This works because the contents of
       <literal>latin1_column</literal> are automatically converted to
-      UTF8 before the comparison.
+      UTF-8 before the comparison.
     </para>
 
 <programlisting>
@@ -2312,8 +2331,9 @@
 
     <para>
       <emphasis role="bold">Note</emphasis>: In MySQL &current-series;,
-      the <filename>errmsg.txt</filename> files all use UTF8. Conversion
-      to the client character set is automatic, as with metadata.
+      the <filename>errmsg.txt</filename> files all use UTF-8.
+      Conversion to the client character set is automatic, as with
+      metadata.
     </para>
 
   </section>

Modified: trunk/refman-5.0/installing.xml
===================================================================
--- trunk/refman-5.0/installing.xml	2006-01-15 04:56:33 UTC (rev 833)
+++ trunk/refman-5.0/installing.xml	2006-01-15 04:56:50 UTC (rev 834)
@@ -3893,8 +3893,8 @@
             <para>
               <guimenuitem>Best Support For
               Multilingualism</guimenuitem>: Choose this option if you
-              want to use <literal>UTF8</literal> as the default server
-              character set. <literal>UTF8</literal> can store
+              want to use <literal>utf8</literal> as the default server
+              character set. <literal>utf8</literal> can store
               characters from many different languages in a single
               character set.
             </para>

Modified: trunk/refman-5.0/language-structure.xml
===================================================================
--- trunk/refman-5.0/language-structure.xml	2006-01-15 04:56:33 UTC (rev 833)
+++ trunk/refman-5.0/language-structure.xml	2006-01-15 04:56:50 UTC (rev 834)
@@ -834,7 +834,7 @@
     </para>
 
     <para>
-      Identifiers are stored using Unicode (UTF8). This applies to
+      Identifiers are stored using Unicode (UTF-8). This applies to
       identifiers in table definitions that stored in
       <filename>.frm</filename> files and to identifiers stored in the
       grant tables in the <literal>mysql</literal> database. The sizes

Modified: trunk/refman-5.1/charset.xml
===================================================================
--- trunk/refman-5.1/charset.xml	2006-01-15 04:56:33 UTC (rev 833)
+++ trunk/refman-5.1/charset.xml	2006-01-15 04:56:50 UTC (rev 834)
@@ -22,10 +22,6 @@
   </indexterm>
 
   <indexterm>
-    <primary>UTF8</primary>
-  </indexterm>
-
-  <indexterm>
     <primary>UTF-8</primary>
   </indexterm>
 
@@ -495,6 +491,12 @@
       </para>
 
       <para>
+        All database options are stored in a text file named
+        <filename>db.opt</filename> that can be found in the database
+        directory.
+      </para>
+
+      <para>
         The <literal>CHARACTER SET</literal> and
         <literal>COLLATE</literal> clauses make it possible to create
         databases with different character sets and collations on the
@@ -807,7 +809,8 @@
 </programlisting>
 
       <para>
-        MySQL determines a literal's character set and collation thus:
+        MySQL determines a literal's character set and collation in the
+        following manner:
       </para>
 
       <itemizedlist>
@@ -1456,6 +1459,26 @@
 SELECT * FROM t1 ORDER BY a COLLATE latin1_bin;
 </programlisting>
 
+      <para>
+        The <literal>BINARY</literal> attribute in character column
+        definitions has a similar effect. A character column defined
+        with the <literal>BINARY</literal> attribute is assigned the
+        binary collation of the column's character set.
+      </para>
+
+      <para>
+        The effect of <literal>BINARY</literal> in both contexts differs
+        from its effect prior to MySQL 4.1. Formerly,
+        <literal>BINARY</literal> resulted in binary string comparisons
+        or binary string column definitions. A binary string is a string
+        of bytes that has no character set or collation, which differs
+        from a non-binary character string that has a binary collation.
+        For both types of strings, comparisons are based on the numeric
+        values of the string unit, but for non-binary strings the unit
+        is the character and some character sets allow multi-byte
+        characters. <xref linkend="binary-varbinary"/>.
+      </para>
+
     </section>
 
     <section id="charset-collate-tricky">
@@ -1463,11 +1486,10 @@
       <title>&title-charset-collate-tricky;</title>
 
       <para>
-        In the great majority of queries, it is obvious what collation
-        MySQL uses to resolve a comparison operation. For example, in
-        the following cases, it should be clear that the collation is
-        <quote>the column collation of column
-        <literal>x</literal></quote>:
+        In the great majority of statements, it is obvious what
+        collation MySQL uses to resolve a comparison operation. For
+        example, in the following cases, it should be clear that the
+        collation is the collation of column <literal>x</literal>:
       </para>
 
 <programlisting>
@@ -1496,7 +1518,7 @@
         called <quote>coercibility</quote> rules. Basically, this means:
         Both <literal>x</literal> and <literal>'Y'</literal> have
         collations, so which collation takes precedence? This can be
-        difficult to resolve, but the following rules take care of most
+        difficult to resolve, but the following rules cover most
         situations:
       </para>
 
@@ -1551,7 +1573,7 @@
       </para>
 
       <para>
-        Those rules resolve ambiguities thus:
+        Those rules resolve ambiguities in the following manner:
       </para>
 
       <itemizedlist>
@@ -1614,13 +1636,6 @@
         See <xref linkend="information-functions"/>.
       </para>
 
-      <para>
-        There is no system constant or ignorable coercibility. Functions
-        such as <literal>USER()</literal> have a coercibility of 2
-        rather than 3, and literals have a coercibility of 3 rather than
-        4.
-      </para>
-
     </section>
 
     <section id="charset-collation-charset">
@@ -1628,9 +1643,9 @@
       <title>&title-charset-collation-charset;</title>
 
       <para>
-        Recall that each character set has one or more collations, and
-        each collation is associated with one and only one character
-        set. Therefore, the following statement causes an error message
+        Cach character set has one or more collations, but each
+        collation is associated with one and only one character set.
+        Therefore, the following statement causes an error message
         because the <literal>latin2_bin</literal> collation is not legal
         with the <literal>latin1</literal> character set:
       </para>
@@ -1670,8 +1685,8 @@
 </programlisting>
 
       <para>
-        The resulting order of the values for different collations is
-        shown in this table:
+        The following table shows the resulting order of the values if
+        we use <literal>ORDER BY</literal> with different collations:
       </para>
 
       <informaltable>
@@ -1710,10 +1725,8 @@
       </informaltable>
 
       <para>
-        The table is an example that shows what the effect would be if
-        we used different collations in an <literal>ORDER BY</literal>
-        clause. The character that causes the different sort orders in
-        this example is the U with two dots over it
+        The character that causes the different sort orders in this
+        example is the U with two dots over it
         (<literal>&uuml;</literal>), which the Germans call "U-umlaut".
       </para>
 
@@ -1755,7 +1768,7 @@
 
     <para>
       This section describes operations that take character set
-      information into account in MySQL &current-series;.
+      information into account.
     </para>
 
     <section id="charset-result">
@@ -1783,15 +1796,18 @@
         <literal>RTRIM()</literal>, <literal>SOUNDEX()</literal>,
         <literal>SUBSTRING()</literal>, <literal>TRIM()</literal>,
         <literal>UCASE()</literal>, and <literal>UPPER()</literal>.
-        (Also note: The <literal>REPLACE()</literal> function, unlike
-        all other functions, always ignores the collation of the string
-        input and performs a case-sensitive comparison.)
       </para>
 
       <para>
+        Note: The <literal>REPLACE()</literal> function, unlike all
+        other functions, always ignores the collation of the string
+        input and performs a case-sensitive comparison.
+      </para>
+
+      <para>
         For operations that combine multiple string inputs and return a
         single string output, the <quote>aggregation rules</quote> of
-        standard SQL apply:
+        standard SQL apply for determining the collation of the result:
       </para>
 
       <itemizedlist>
@@ -1799,7 +1815,7 @@
         <listitem>
           <para>
             If an explicit <literal>COLLATE
-            <replaceable>X</replaceable></literal> occurs, then use
+            <replaceable>X</replaceable></literal> occurs, use
             <replaceable>X</replaceable>.
           </para>
         </listitem>
@@ -1808,7 +1824,7 @@
           <para>
             If explicit <literal>COLLATE
             <replaceable>X</replaceable></literal> and <literal>COLLATE
-            <replaceable>Y</replaceable></literal> occur, then raise an
+            <replaceable>Y</replaceable></literal> occur, raise an
             error.
           </para>
         </listitem>
@@ -1816,7 +1832,7 @@
         <listitem>
           <para>
             Otherwise, if all collations are
-            <replaceable>X</replaceable>, then use
+            <replaceable>X</replaceable>, use
             <replaceable>X</replaceable>.
           </para>
         </listitem>
@@ -1830,8 +1846,8 @@
       </itemizedlist>
 
       <para>
-        For example, with <literal>CASE ... WHEN a THEN b WHEN b THEN c
-        COLLATE <replaceable>X</replaceable> END</literal>, the
+        For example, with <literal>CASE &hellip; WHEN a THEN b WHEN b
+        THEN c COLLATE <replaceable>X</replaceable> END</literal>, the
         resulting collation is <replaceable>X</replaceable>. The same
         applies for <literal>CASE</literal>, <literal>UNION</literal>,
         <literal>||</literal>, <literal>CONCAT()</literal>,
@@ -1880,8 +1896,8 @@
 </programlisting>
 
       <para>
-        <literal>CONVERT(... USING ...)</literal> is implemented
-        according to the standard SQL specification.
+        <literal>CONVERT(&hellip; USING &hellip;)</literal> is
+        implemented according to the standard SQL specification.
       </para>
 
       <para>
@@ -1908,7 +1924,7 @@
         <literal>character_set_connection</literal> and
         <literal>collation_connection</literal> system variables. If you
         use <literal>CAST()</literal> with <literal>CHARACTER SET
-        X</literal>, then the resulting character set and collation are
+        X</literal>, the resulting character set and collation are
         <literal>X</literal> and the default collation of
         <literal>X</literal>.
       </para>
@@ -1916,8 +1932,8 @@
       <para>
         You may not use a <literal>COLLATE</literal> clause inside a
         <literal>CAST()</literal>, but you may use it outside. That is,
-        <literal>CAST(... COLLATE ...)</literal> is illegal, but
-        <literal>CAST(...) COLLATE ...</literal> is legal.
+        <literal>CAST(&hellip; COLLATE &hellip;)</literal> is illegal,
+        but <literal>CAST(&hellip;) COLLATE &hellip;</literal> is legal.
       </para>
 
       <para>
@@ -1939,10 +1955,23 @@
         character set information. These include <literal>SHOW CHARACTER
         SET</literal>, <literal>SHOW COLLATION</literal>, <literal>SHOW
         CREATE DATABASE</literal>, <literal>SHOW CREATE TABLE</literal>
-        and <literal>SHOW COLUMNS</literal>.
+        and <literal>SHOW COLUMNS</literal>. These statements are
+        described here briefly. For more information, see
+        <xref linkend="show"/>.
       </para>
 
       <para>
+        <literal>INFORMATION_SCHEMA</literal> has several tables that
+        contain information information similar to that displayed by the
+        <literal>SHOW</literal> statements. For example, the
+        <literal>CHARACTER_SETS</literal> and
+        <literal>COLLATIONS</literal> tables contain the information
+        displayed by <literal>SHOW CHARACTER SET</literal> and
+        <literal>SHOW COLLATION</literal>.
+        <xref linkend="information-schema"/>.
+      </para>
+
+      <para>
         The <literal>SHOW CHARACTER SET</literal> command shows all
         available character sets. It takes an optional
         <literal>LIKE</literal> clause that indicates which character
@@ -1962,10 +1991,6 @@
 </programlisting>
 
       <para>
-        See <xref linkend="show-character-set"/>.
-      </para>
-
-      <para>
         The output from <literal>SHOW COLLATION</literal> includes all
         available character sets. It takes an optional
         <literal>LIKE</literal> clause that indicates which collation
@@ -1989,17 +2014,9 @@
 </programlisting>
 
       <para>
-        See <xref linkend="show-collation"/>.
-      </para>
-
-      <para>
         <literal>SHOW CREATE DATABASE</literal> displays the
         <literal>CREATE DATABASE</literal> statement that creates a
-        given database. The result includes all database options.
-        <literal>DEFAULT CHARACTER SET</literal> and
-        <literal>COLLATE</literal> are supported. All database options
-        are stored in a text file named <filename>db.opt</filename> that
-        can be found in the database directory.
+        given database:
       </para>
 
 <programlisting>
@@ -2012,7 +2029,8 @@
 </programlisting>
 
       <para>
-        See <xref linkend="show-create-database"/>.
+        If no <literal>COLLATE</literal> clause is shown, the default
+        collation for the character set applies.
       </para>
 
       <para>
@@ -2024,17 +2042,13 @@
       </para>
 
       <para>
-        See <xref linkend="show-create-table"/>.
-      </para>
-
-      <para>
         The <literal>SHOW COLUMNS</literal> statement displays the
         collations of a table's columns when invoked as <literal>SHOW
         FULL COLUMNS</literal>. Columns with <literal>CHAR</literal>,
         <literal>VARCHAR</literal>, or <literal>TEXT</literal> data
-        types have non-<literal>NULL</literal> collations. Numeric and
-        other non-character types have <literal>NULL</literal>
-        collations. For example:
+        types have collations. Numeric and other non-character types
+        have no collation (indicated by <literal>NULL</literal> as the
+        <literal>Collation</literal> value). For example:
       </para>
 
 <programlisting>
@@ -2063,14 +2077,10 @@
 </programlisting>
 
       <para>
-        The character set is not part of the display. (The character set
-        name is implied by the collation name.)
+        The character set is not part of the display but is implied by
+        the collation name.
       </para>
 
-      <para>
-        See <xref linkend="show-columns"/>.
-      </para>
-
     </section>
 
   </section>
@@ -2094,7 +2104,7 @@
 
       <listitem>
         <para>
-          <literal>utf8</literal>, the UTF8 encoding of the Unicode
+          <literal>utf8</literal>, the UTF-8 encoding of the Unicode
           character set.
         </para>
       </listitem>
@@ -2105,10 +2115,11 @@
       In UCS-2 (binary Unicode representation), every character is
       represented by a two-byte Unicode code with the most significant
       byte first. For example: "LATIN CAPITAL LETTER A" has the code
-      0x0041 and it's stored as a two-byte sequence: 0x00 0x41.
-      "CYRILLIC SMALL LETTER YERU" (Unicode 0x044B) is stored as a
-      two-byte sequence: 0x04 0x4B. For Unicode characters and their
-      codes, please refer to the
+      <literal>0x0041</literal> and it is stored as a two-byte sequence:
+      <literal>0x00 0x41</literal>. "CYRILLIC SMALL LETTER YERU"
+      (Unicode <literal>0x044B</literal>) is stored as a two-byte
+      sequence: <literal>0x04 0x4B</literal>. For Unicode characters and
+      their codes, please refer to the
       <ulink url="http://www.unicode.org/">Unicode Home Page</ulink>.
     </para>
 
@@ -2118,9 +2129,9 @@
     </para>
 
     <para>
-      The UTF8 character set (transform Unicode representation) is an
+      The UTF-8 character set (transform Unicode representation) is an
       alternative way to store Unicode data. It is implemented according
-      to RFC 3629. The idea of the UTF8 character set is that various
+      to RFC 3629. The idea of the UTF-8 character set is that various
       Unicode characters are encoded using byte sequences of different
       lengths:
     </para>
@@ -2154,19 +2165,20 @@
 
     <para>
       RFC 3629 describes encoding sequences that take from one to four
-      bytes. Currently, MySQL UTF8 support does not include four-byte
-      sequences. (An older standard for UTF8 encoding is given by RFC
-      2279, which describes UTF8 sequences that take from one to six
-      bytes. RFC 3629 renders RFC 2279 obsolete; for this reason,
-      sequences with five and six bytes are no longer used.)
+      bytes. Currently, MySQL support for UTF-8 does not include
+      four-byte sequences. (An older standard for UTF-8 encoding is
+      given by RFC 2279, which describes UTF-8 sequences that take from
+      one to six bytes. RFC 3629 renders RFC 2279 obsolete; for this
+      reason, sequences with five and six bytes are no longer used.)
     </para>
 
     <para>
-      <emphasis role="bold">Tip</emphasis>: To save space with UTF8, use
-      <literal>VARCHAR</literal> instead of <literal>CHAR</literal>.
-      Otherwise, MySQL has to reserve 30 bytes for a <literal>CHAR(10)
-      CHARACTER SET utf8</literal> column, because this is the maximum
-      possible length.
+      <emphasis role="bold">Tip</emphasis>: To save space with UTF-8,
+      use <literal>VARCHAR</literal> instead of <literal>CHAR</literal>.
+      Otherwise, MySQL must reserve three bytes for each character in a
+      <literal>CHAR CHARACTER SET utf8</literal> column because that is
+      the maximum possible length. For example, MySQL must reserve 30
+      bytes for a <literal>CHAR(10) CHARACTER SET utf8</literal> column.
     </para>
 
   </section>
@@ -2217,16 +2229,16 @@
 
     <para>
       In order to satisfy both requirements, MySQL stores metadata in a
-      Unicode character set, namely UTF8. This does not cause any
+      Unicode character set, namely UTF-8. This does not cause any
       disruption if you never use accented characters. But if you do,
-      you should be aware that metadata is in UTF8.
+      you should be aware that metadata is in UTF-8.
     </para>
 
     <para>
       This means that the return values of the
       <literal>USER()</literal>, <literal>CURRENT_USER()</literal>,
       <literal>DATABASE()</literal>, and <literal>VERSION()</literal>
-      functions have the UTF8 character set by default, as do synonyms
+      functions have the UTF-8 character set by default, as do synonyms
       such as <literal>SESSION_USER()</literal> and
       <literal>SYSTEM_USER()</literal>.
     </para>
@@ -2263,9 +2275,9 @@
     </para>
 
     <para>
-      If you want the server to pass metadata results back in a non-UTF8
-      character set, then use <literal>SET NAMES</literal> to force the
-      server to perform character set conversion (see
+      If you want the server to pass metadata results back in a
+      non-UTF-8 character set, then use <literal>SET NAMES</literal> to
+      force the server to perform character set conversion (see
       <xref linkend="charset-connection"/>), or else cause the client to
       perform the conversion. It is more efficient to have the client
       perform the conversion, but this option is not always available
@@ -2285,7 +2297,7 @@
     <para>
       This works because the contents of
       <literal>latin1_column</literal> are automatically converted to
-      UTF8 before the comparison.
+      UTF-8 before the comparison.
     </para>
 
 <programlisting>
@@ -2311,8 +2323,9 @@
 
     <para>
       <emphasis role="bold">Note</emphasis>: In MySQL &current-series;,
-      the <filename>errmsg.txt</filename> files all use UTF8. Conversion
-      to the client character set is automatic, as with metadata.
+      the <filename>errmsg.txt</filename> files all use UTF-8.
+      Conversion to the client character set is automatic, as with
+      metadata.
     </para>
 
   </section>

Modified: trunk/refman-5.1/installing.xml
===================================================================
--- trunk/refman-5.1/installing.xml	2006-01-15 04:56:33 UTC (rev 833)
+++ trunk/refman-5.1/installing.xml	2006-01-15 04:56:50 UTC (rev 834)
@@ -3890,8 +3890,8 @@
             <para>
               <guimenuitem>Best Support For
               Multilingualism</guimenuitem>: Choose this option if you
-              want to use <literal>UTF8</literal> as the default server
-              character set. <literal>UTF8</literal> can store
+              want to use <literal>utf8</literal> as the default server
+              character set. <literal>utf8</literal> can store
               characters from many different languages in a single
               character set.
             </para>

Modified: trunk/refman-5.1/language-structure.xml
===================================================================
--- trunk/refman-5.1/language-structure.xml	2006-01-15 04:56:33 UTC (rev 833)
+++ trunk/refman-5.1/language-structure.xml	2006-01-15 04:56:50 UTC (rev 834)
@@ -834,7 +834,7 @@
     </para>
 
     <para>
-      Identifiers are stored using Unicode (UTF8). This applies to
+      Identifiers are stored using Unicode (UTF-8). This applies to
       identifiers in table definitions that stored in
       <filename>.frm</filename> files and to identifiers stored in the
       grant tables in the <literal>mysql</literal> database. The sizes

Modified: trunk/refman-common/titles.en.ent
===================================================================
--- trunk/refman-common/titles.en.ent	2006-01-15 04:56:33 UTC (rev 833)
+++ trunk/refman-common/titles.en.ent	2006-01-15 04:56:50 UTC (rev 834)
@@ -155,7 +155,7 @@
 <!ENTITY title-charset-result "Result Strings">
 <!ENTITY title-charset-se-me-sets "South European and Middle East Character Sets">
 <!ENTITY title-charset-server "Server Character Set and Collation">
-<!ENTITY title-charset-show "<literal>SHOW</literal> Statements">
+<!ENTITY title-charset-show "<literal>SHOW</literal> Statements and <literal>INFORMATION_SCHEMA</literal>">
 <!ENTITY title-charset-syntax "Specifying Character Sets and Collations">
 <!ENTITY title-charset-table "Table Character Set and Collation">
 <!ENTITY title-charset-unicode "Unicode Support">

Thread
svn commit - mysqldoc@docsrva: r834 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-commonpaul15 Jan