List:Commits« Previous MessageNext Message »
From:paul Date:January 18 2006 7:32pm
Subject:svn commit - mysqldoc@docsrva: r905 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-18 20:32:04 +0100 (Wed, 18 Jan 2006)
New Revision: 905

Log:
 r2298@kite-hub:  paul | 2006-01-18 13:30:09 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/data-types.xml
   trunk/refman-5.0/data-types.xml
   trunk/refman-5.1/data-types.xml


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

Modified: trunk/refman-4.1/data-types.xml
===================================================================
--- trunk/refman-4.1/data-types.xml	2006-01-18 19:31:50 UTC (rev 904)
+++ trunk/refman-4.1/data-types.xml	2006-01-18 19:32:04 UTC (rev 905)
@@ -854,7 +854,7 @@
           <para>
             These types are synonyms for <literal>DECIMAL</literal>. The
             <literal>FIXED</literal> synonym was added in MySQL 4.1.0
-            for compatibility with other servers.
+            for compatibility with other database systems.
           </para>
 
           <remark role="help-description-end"/>
@@ -988,13 +988,15 @@
           <para>
             A <literal>TIMESTAMP</literal> column is useful for
             recording the date and time of an <literal>INSERT</literal>
-            or <literal>UPDATE</literal> operation. The first
-            <literal>TIMESTAMP</literal> column in a table is
+            or <literal>UPDATE</literal> operation. By default, the
+            first <literal>TIMESTAMP</literal> column in a table is
             automatically set to the date and time of the most recent
             operation if you do not assign it a value yourself. You can
             also set any <literal>TIMESTAMP</literal> column to the
             current date and time by assigning it a
-            <literal>NULL</literal> value.
+            <literal>NULL</literal> value. Variations on automatic
+            initialization and update properties are described in
+            <xref linkend="timestamp-4-1"/>.
           </para>
 
           <para>
@@ -1140,7 +1142,9 @@
       </para>
 
       <para>
-        As of MySQL 4.1, several changes affect string data types:
+        In MySQL 4.1 and up, string data types include some features
+        that you may not have encountered in working with previous
+        versions of MySQL (prior to 4.1):
       </para>
 
       <itemizedlist>
@@ -1149,9 +1153,10 @@
           <para>
             Column definitions for many string data types can include a
             <literal>CHARACTER SET</literal> attribute to specify the
-            character set and, optionally, a collation.
-            (<literal>CHARSET</literal> is a synonym for
-            <literal>CHARACTER SET</literal>.) These attributes apply to
+            character set. (<literal>CHARSET</literal> is a synonym for
+            <literal>CHARACTER SET</literal>.) The
+            <literal>COLLATE</literal> attribute specifies a collation
+            for the the character set. These attributes apply to
             <literal>CHAR</literal>, <literal>VARCHAR</literal>, the
             <literal>TEXT</literal> types, <literal>ENUM</literal>, and
             <literal>SET</literal>. For example:
@@ -1160,8 +1165,8 @@
 <programlisting>
 CREATE TABLE t
 (
-    c1 CHAR(20) CHARACTER SET utf8,
-    c2 CHAR(20) CHARACTER SET latin1 COLLATE latin1_bin
+    c1 VARCHAR(20) CHARACTER SET utf8,
+    c2 TEXT CHARACTER SET latin1 COLLATE latin1_general_cs
 );
 </programlisting>
 
@@ -1170,18 +1175,17 @@
             <literal>c1</literal> that has a character set of
             <literal>utf8</literal> with the default collation for that
             character set, and a column named <literal>c2</literal> that
-            has a character set of <literal>latin1</literal> and the
-            binary collation for the character set. The binary collation
-            is not case sensitive.
+            has a character set of <literal>latin1</literal> and a
+            case-sensitive collation.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            <emphasis role="bold">Note</emphasis>: In MySQL 4.1, MySQL
-            interprets length specifications in character column
-            definitions in character units. Earlier versions interpret
-            lengths in byte units.
+            <emphasis role="bold">Note</emphasis>: As of MySQL 4.1,
+            MySQL interprets length specifications in character column
+            definitions in character units. (Previously, MySQL
+            interpreted lengths in bytes.)
           </para>
         </listitem>
 
@@ -1191,31 +1195,32 @@
             the <literal>TEXT</literal> types, the
             <literal>BINARY</literal> attribute causes the column to be
             assigned the binary collation of the column character set.
-            For earlier versions, <literal>BINARY</literal> causes
+            (Previously, <literal>BINARY</literal> caused
             <literal>CHAR</literal> and <literal>VARCHAR</literal> to be
-            treated as binary strings and is disallowed for the
-            <literal>TEXT</literal> types.
+            treated as binary strings and was disallowed for the
+            <literal>TEXT</literal> types.)
           </para>
         </listitem>
 
         <listitem>
           <para>
             Character column sorting and comparison are based on the
-            character set assigned to the column. For earlier versions,
-            sorting and comparison are based on the collation of the
-            server character set. For <literal>CHAR</literal> and
+            character set assigned to the column. (Previously sorting
+            and comparison were based on the collation of the server
+            character set.) For <literal>CHAR</literal> and
             <literal>VARCHAR</literal> columns, you can declare the
-            column with the <literal>BINARY</literal> attribute to cause
-            sorting and comparison to use the underlying character code
-            values rather then a lexical ordering.
+            column with a binary collation or the
+            <literal>BINARY</literal> attribute to cause sorting and
+            comparison to use the underlying character code values
+            rather then a lexical ordering.
           </para>
         </listitem>
 
       </itemizedlist>
 
       <para>
-        For more details about character set support in MySQL 4.1 and
-        up, see <xref linkend="charset"/>.
+        <xref linkend="charset"/>, provides additional information about
+        use of character sets in MySQL 4.1 and up.
       </para>
 
       <itemizedlist>
@@ -1786,7 +1791,7 @@
               <secondary>ENUM</secondary>
             </indexterm>
 
-            <literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal>
+            <literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',&hellip;)</literal>
           </para>
 
           <para>
@@ -1794,7 +1799,7 @@
             value, chosen from the list of values
             <literal>'<replaceable>value1</replaceable>'</literal>,
             <literal>'<replaceable>value2</replaceable>'</literal>,
-            <literal>...</literal>, <literal>NULL</literal> or the
+            <literal>&hellip;</literal>, <literal>NULL</literal> or the
             special <literal>''</literal> error value. An
             <literal>ENUM</literal> column can have a maximum of 65,535
             distinct values. <literal>ENUM</literal> values are
@@ -1819,7 +1824,7 @@
               <secondary>SET</secondary>
             </indexterm>
 
-            <literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal>
+            <literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',&hellip;)</literal>
           </para>
 
           <para>
@@ -1827,9 +1832,9 @@
             each of which must be chosen from the list of values
             <literal>'<replaceable>value1</replaceable>'</literal>,
             <literal>'<replaceable>value2</replaceable>'</literal>,
-            <literal>...</literal> A <literal>SET</literal> column can
-            have a maximum of 64 members. <literal>SET</literal> values
-            are represented internally as integers.
+            <literal>&hellip;</literal> A <literal>SET</literal> column
+            can have a maximum of 64 members. <literal>SET</literal>
+            values are represented internally as integers.
           </para>
 
           <remark role="help-description-end"/>
@@ -1982,7 +1987,7 @@
       All integer types can have an optional (non-standard) attribute
       <literal>UNSIGNED</literal>. Unsigned values can be used when you
       want to allow only non-negative numbers in a column and you need a
-      bigger upper numeric range for the column.
+      larger upper numeric range for the column.
     </para>
 
     <para>
@@ -2265,8 +2270,8 @@
           you specify a value to be assigned to or compared to a date or
           time type). Only the formats described in the following
           sections are supported. It is expected that you supply legal
-          values, and unpredictable results may occur if you use values
-          in other formats.
+          values. Unpredictable results may occur if you use values in
+          other formats.
         </para>
       </listitem>
 
@@ -2344,7 +2349,11 @@
                 <entry><literal>'0000-00-00'</literal></entry>
               </row>
               <row>
-                <entry><literal>TIMESTAMP</literal></entry>
+                <entry><literal>TIMESTAMP</literal> (4.1 and up)</entry>
+                <entry><literal>'0000-00-00 00:00:00'</literal></entry>
+              </row>
+              <row>
+                <entry><literal>TIMESTAMP</literal> (before 4.1)</entry>
                 <entry><literal>00000000000000</literal></entry>
               </row>
               <row>
@@ -3391,7 +3400,7 @@
         <para>
           Otherwise &mdash; that is, if the <literal>TIMESTAMP</literal>
           column is defined using <literal>NULL</literal> but not using
-          <literal>DEFAULT TIMESTAMP</literal>, as shown here:
+          <literal>DEFAULT TIMESTAMP</literal>, as shown here&hellip;
         </para>
 
 <programlisting>
@@ -3400,7 +3409,7 @@
 </programlisting>
 
         <para>
-          &mdash; then you must explicitly insert a value corresponding
+          &hellip;then you must explicitly insert a value corresponding
           to the current date and time, for example:
         </para>
 
@@ -3458,7 +3467,7 @@
             HH:MM'</literal>, <literal>'D HH'</literal>, or
             <literal>'SS'</literal>. Here <literal>D</literal>
             represents days and can have a value from 0 to 34. Note that
-            MySQL does not yet store the fraction part.
+            MySQL does not store the fraction part.
           </para>
         </listitem>
 
@@ -4069,14 +4078,42 @@
 
       <para>
         You should consider the preceding padding and stripping
-        characteristics carefully if you plan to use these data types
-        for storing binary data and you require that the value retrieved
-        be exactly the same as the value stored. It might be preferable
-        to use one of the <literal>BLOB</literal> data types instead.
+        characteristics carefully if you plan to use one of these data
+        types for storing binary data and you require that the value
+        retrieved be exactly the same as the value stored. The following
+        example illustrates how <literal>0x00</literal>-padding of
+        <literal>BINARY</literal> values affects column value
+        comparisons:
       </para>
 
+<programlisting>
+<!--
+mysql> DROP TABLE IF EXISTS t;
+Query OK, 0 rows affected (0.00 sec)
+-->
+mysql&gt; <userinput>CREATE TABLE t (c BINARY(3));</userinput>
+Query OK, 0 rows affected (0.01 sec)
+
+mysql&gt; <userinput>INSERT INTO t SET c = 'a';</userinput>
+Query OK, 1 row affected (0.01 sec)
+
+mysql&gt; <userinput>SELECT HEX(c), c = 'a', c = 'a\0\0' from t;</userinput>
++--------+---------+-------------+
+| HEX(c) | c = 'a' | c = 'a\0\0' |
++--------+---------+-------------+
+| 610000 |       0 |           1 |
++--------+---------+-------------+
+1 row in set (0.09 sec)
+</programlisting>
+
       <para>
-        MySQL may silently change the type of a
+        If the value retrieved must be the same as the value specified
+        for storage with no padding, it might be preferable to use one
+        of the <literal>BLOB</literal> data types instead.
+      </para>
+
+      <para>
+        In some cases, MySQL may silently change the type of a
         <literal>BINARY</literal> or <literal>VARBINARY</literal> column
         at table creation time. See
         <xref linkend="silent-column-changes"/>.
@@ -4222,7 +4259,8 @@
             For indexes on <literal>BLOB</literal> and
             <literal>TEXT</literal> columns, you must specify an index
             prefix length. For <literal>CHAR</literal> and
-            <literal>VARCHAR</literal>, a prefix length is optional.
+            <literal>VARCHAR</literal>, a prefix length is optional. See
+            <xref linkend="indexes"/>.
           </para>
         </listitem>
 
@@ -4432,18 +4470,16 @@
         <listitem>
           <para>
             Values from the list of allowable elements in the column
-            specification are numbered beginning with
-            <literal>1</literal>.
+            specification are numbered beginning with 1.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            The index value of the empty string error value is
-            <literal>0</literal>. This means that you can use the
-            following <literal>SELECT</literal> statement to find rows
-            into which invalid <literal>ENUM</literal> values were
-            assigned:
+            The index value of the empty string error value is 0. This
+            means that you can use the following
+            <literal>SELECT</literal> statement to find rows into which
+            invalid <literal>ENUM</literal> values were assigned:
           </para>
 
 <programlisting>
@@ -5101,12 +5137,12 @@
               &lt; 2<superscript>32</superscript></entry>
           </row>
           <row>
-            <entry><literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal></entry>
+            <entry><literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',&hellip;)</literal></entry>
             <entry>1 or 2 bytes, depending on the number of enumeration values (65,535
               values maximum)</entry>
           </row>
           <row>
-            <entry><literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal></entry>
+            <entry><literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',&hellip;)</literal></entry>
             <entry>1, 2, 3, 4, or 8 bytes, depending on the number of set members (64
               members maximum)</entry>
           </row>

Modified: trunk/refman-5.0/data-types.xml
===================================================================
--- trunk/refman-5.0/data-types.xml	2006-01-18 19:31:50 UTC (rev 904)
+++ trunk/refman-5.0/data-types.xml	2006-01-18 19:32:04 UTC (rev 905)
@@ -463,7 +463,7 @@
 
                 All arithmetic is done using signed
                 <literal>BIGINT</literal> or <literal>DOUBLE</literal>
-                values, so you shouldn't use unsigned big integers
+                values, so you should not use unsigned big integers
                 larger than <literal>9223372036854775807</literal> (63
                 bits) except with bit functions! If you do that, some of
                 the last digits in the result may be wrong because of
@@ -481,8 +481,8 @@
 
                 <listitem>
                   <para>
-                    When using integers to store big unsigned values in
-                    a <literal>BIGINT</literal> column.
+                    When using integers to store large unsigned values
+                    in a <literal>BIGINT</literal> column.
                   </para>
                 </listitem>
 
@@ -835,8 +835,8 @@
           </para>
 
           <para>
-            If <literal>UNSIGNED</literal> is specified, negative values
-            are disallowed.
+            <literal>UNSIGNED</literal>, if specified, disallows
+            negative values.
           </para>
 
           <remark role="help-description-end"/>
@@ -1024,13 +1024,15 @@
           <para>
             A <literal>TIMESTAMP</literal> column is useful for
             recording the date and time of an <literal>INSERT</literal>
-            or <literal>UPDATE</literal> operation. The first
-            <literal>TIMESTAMP</literal> column in a table is
+            or <literal>UPDATE</literal> operation. By default, the
+            first <literal>TIMESTAMP</literal> column in a table is
             automatically set to the date and time of the most recent
-            operation if you don't assign it a value yourself. You can
+            operation if you do not assign it a value yourself. You can
             also set any <literal>TIMESTAMP</literal> column to the
             current date and time by assigning it a
-            <literal>NULL</literal> value.
+            <literal>NULL</literal> value. Variations on automatic
+            initialization and update properties are described in
+            <xref linkend="timestamp-4-1"/>.
           </para>
 
           <para>
@@ -1144,9 +1146,9 @@
       </para>
 
       <para>
-        MySQL &current-series; string data types include some features
-        that you may not have encountered in working with versions of
-        MySQL prior to 4.1:
+        In MySQL 4.1 and up, string data types include some features
+        that you may not have encountered in working with previous
+        versions of MySQL (prior to 4.1):
       </para>
 
       <itemizedlist>
@@ -1155,9 +1157,10 @@
           <para>
             Column definitions for many string data types can include a
             <literal>CHARACTER SET</literal> attribute to specify the
-            character set and, optionally, a collation.
-            (<literal>CHARSET</literal> is a synonym for
-            <literal>CHARACTER SET</literal>.) These attributes apply to
+            character set. (<literal>CHARSET</literal> is a synonym for
+            <literal>CHARACTER SET</literal>.) The
+            <literal>COLLATE</literal> attribute specifies a collation
+            for the the character set. These attributes apply to
             <literal>CHAR</literal>, <literal>VARCHAR</literal>, the
             <literal>TEXT</literal> types, <literal>ENUM</literal>, and
             <literal>SET</literal>. For example:
@@ -1166,8 +1169,8 @@
 <programlisting>
 CREATE TABLE t
 (
-    c1 CHAR(20) CHARACTER SET utf8,
-    c2 CHAR(20) CHARACTER SET latin1 COLLATE latin1_bin
+    c1 VARCHAR(20) CHARACTER SET utf8,
+    c2 TEXT CHARACTER SET latin1 COLLATE latin1_general_cs
 );
 </programlisting>
 
@@ -1176,17 +1179,16 @@
             <literal>c1</literal> that has a character set of
             <literal>utf8</literal> with the default collation for that
             character set, and a column named <literal>c2</literal> that
-            has a character set of <literal>latin1</literal> and the
-            binary collation for the character set. The binary collation
-            is not case sensitive.
+            has a character set of <literal>latin1</literal> and a
+            case-sensitive collation.
           </para>
         </listitem>
 
         <listitem>
           <para>
             MySQL &current-series; interprets length specifications in
-            character column definitions in character units. (Some
-            earlier MySQL versions interpreted lengths in bytes.)
+            character column definitions in character units.
+            (Previously, MySQL interpreted lengths in bytes.)
           </para>
         </listitem>
 
@@ -1196,27 +1198,30 @@
             the <literal>TEXT</literal> types, the
             <literal>BINARY</literal> attribute causes the column to be
             assigned the binary collation of the column character set.
+            (Previously, <literal>BINARY</literal> caused a column to
+            store binary strings.)
           </para>
         </listitem>
 
         <listitem>
           <para>
             Character column sorting and comparison are based on the
-            character set assigned to the column. For earlier versions,
-            sorting and comparison are based on the collation of the
-            server character set. For <literal>CHAR</literal> and
+            character set assigned to the column. (Previously, sorting
+            and comparison were based on the collation of the server
+            character set.) For <literal>CHAR</literal> and
             <literal>VARCHAR</literal> columns, you can declare the
-            column with the <literal>BINARY</literal> attribute to cause
-            sorting and comparison to use the underlying character code
-            values rather then a lexical ordering.
+            column with a binary collation or the
+            <literal>BINARY</literal> attribute to cause sorting and
+            comparison to use the underlying character code values
+            rather than a lexical ordering.
           </para>
         </listitem>
 
       </itemizedlist>
 
       <para>
-        For more about character set support in MySQL &current-series;,
-        see <xref linkend="charset"/>.
+        <xref linkend="charset"/>, provides additional information about
+        use of character sets in MySQL.
       </para>
 
       <itemizedlist>
@@ -1307,7 +1312,8 @@
 
 <programlisting>
 mysql&gt; <userinput>CREATE TABLE c1 (col1 INT, col2 CHAR(500));</userinput>
-ERROR 1074 (42000): Column length too big for column 'col' (max = 255); use BLOB or TEXT instead
+ERROR 1074 (42000): Column length too big for column 'col' (max = 255);
+use BLOB or TEXT instead
 mysql&gt; <userinput>SHOW CREATE TABLE c1;</userinput>
 ERROR 1146 (42S02): Table 'test.c1' doesn't exist
 </programlisting>
@@ -1793,7 +1799,7 @@
               <secondary>ENUM</secondary>
             </indexterm>
 
-            <literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal>
+            <literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',&hellip;)</literal>
           </para>
 
           <para>
@@ -1801,7 +1807,7 @@
             value, chosen from the list of values
             <literal>'<replaceable>value1</replaceable>'</literal>,
             <literal>'<replaceable>value2</replaceable>'</literal>,
-            <literal>...</literal>, <literal>NULL</literal> or the
+            <literal>&hellip;</literal>, <literal>NULL</literal> or the
             special <literal>''</literal> error value. An
             <literal>ENUM</literal> column can have a maximum of 65,535
             distinct values. <literal>ENUM</literal> values are
@@ -1826,7 +1832,7 @@
               <secondary>SET</secondary>
             </indexterm>
 
-            <literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal>
+            <literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',&hellip;)</literal>
           </para>
 
           <para>
@@ -1834,9 +1840,9 @@
             each of which must be chosen from the list of values
             <literal>'<replaceable>value1</replaceable>'</literal>,
             <literal>'<replaceable>value2</replaceable>'</literal>,
-            <literal>...</literal> A <literal>SET</literal> column can
-            have a maximum of 64 members. <literal>SET</literal> values
-            are represented internally as integers.
+            <literal>&hellip;</literal> A <literal>SET</literal> column
+            can have a maximum of 64 members. <literal>SET</literal>
+            values are represented internally as integers.
           </para>
 
           <remark role="help-description-end"/>
@@ -1999,7 +2005,7 @@
       All integer types can have an optional (non-standard) attribute
       <literal>UNSIGNED</literal>. Unsigned values can be used when you
       want to allow only non-negative numbers in a column and you need a
-      bigger upper numeric range for the column.
+      larger upper numeric range for the column.
     </para>
 
     <para>
@@ -2183,8 +2189,7 @@
       <literal>traditional</literal> (<quote>strict mode</quote>), a
       value that is out of range is rejected with an error, and the
       insert fails, in accordance with the SQL standard. See
-      <xref
-        linkend="server-sql-mode"/>.
+      <xref linkend="server-sql-mode"/>.
     </para>
 
     <remark role="todo">
@@ -2280,7 +2285,7 @@
       because MySQL allows you to store dates where the day or month and
       day are zero in a <literal>DATE</literal> or
       <literal>DATETIME</literal> column. This is extremely useful for
-      applications that need to store a birthdate for which you don't
+      applications that need to store a birthdate for which you do not
       know the exact date. In this case, you simply store the date as
       <literal>'1999-00-00'</literal> or
       <literal>'1999-01-00'</literal>. If you store dates such as these,
@@ -2407,7 +2412,7 @@
               </row>
               <row>
                 <entry><literal>TIMESTAMP</literal></entry>
-                <entry><literal>00000000000000</literal></entry>
+                <entry><literal>'0000-00-00 00:00:00'</literal></entry>
               </row>
               <row>
                 <entry><literal>TIME</literal></entry>
@@ -3092,10 +3097,6 @@
 );
 </programlisting>
 
-        <remark>
-          Updated following to fix Bug#10104
-        </remark>
-
         <para>
           If the <literal>NULL</literal> attribute is not specified,
           setting the column to <literal>NULL</literal> sets it to the
@@ -3117,9 +3118,9 @@
 </programlisting>
 
         <para>
-          Otherwise - that is, if the <literal>TIMESTAMP</literal>
+          Otherwise &mdash; that is, if the <literal>TIMESTAMP</literal>
           column is defined using <literal>NULL</literal> but not using
-          <literal>DEFAULT TIMESTAMP</literal>, as shown here...
+          <literal>DEFAULT TIMESTAMP</literal>, as shown here&hellip;
         </para>
 
 <programlisting>
@@ -3128,8 +3129,8 @@
 </programlisting>
 
         <para>
-          ...then you must explicitly insert a value corresponding to
-          the current date and time. For example:
+          &hellip;then you must explicitly insert a value corresponding
+          to the current date and time. For example:
         </para>
 
 <programlisting>
@@ -3186,7 +3187,7 @@
             HH:MM'</literal>, <literal>'D HH'</literal>, or
             <literal>'SS'</literal>. Here <literal>D</literal>
             represents days and can have a value from 0 to 34. Note that
-            MySQL does not (yet) store the fraction.
+            MySQL does not store the fraction part.
           </para>
         </listitem>
 
@@ -3209,8 +3210,8 @@
             <literal>'10:11:12'</literal>. The following alternative
             formats are also understood: <literal>SS</literal>,
             <literal>MMSS</literal>, <literal>HHMMSS</literal>,
-            <literal>HHMMSS.fraction</literal>. Note that MySQL doesn't
-            (yet) store the fraction.
+            <literal>HHMMSS.fraction</literal>. Note that MySQL does not
+            store the fraction part.
           </para>
         </listitem>
 
@@ -3428,19 +3429,16 @@
 
       <para>
         <literal>ORDER BY</literal> properly sorts
-        <literal>TIMESTAMP</literal> or <literal>YEAR</literal> values
-        that have two-digit years.
+        <literal>YEAR</literal> values that have two-digit years.
       </para>
 
       <para>
         Some functions like <literal>MIN()</literal> and
-        <literal>MAX()</literal> convert a <literal>TIMESTAMP</literal>
-        or <literal>YEAR</literal> to a number. This means that a value
-        with a two-digit year does not work properly with these
-        functions. The fix in this case is to convert the
-        <literal>TIMESTAMP</literal> or <literal>YEAR</literal> to
-        four-digit year format or use something like
-        <literal>MIN(DATE_ADD(timestamp,INTERVAL 0 DAY))</literal>.
+        <literal>MAX()</literal> convert a <literal>YEAR</literal> to a
+        number. This means that a value with a two-digit year does not
+        work properly with these functions. The fix in this case is to
+        convert the <literal>TIMESTAMP</literal> or
+        <literal>YEAR</literal> to four-digit year format.
       </para>
 
     </section>
@@ -3864,12 +3862,12 @@
 
       <para>
         You should consider the preceding padding and stripping
-        characteristics carefully if you plan to use these data types
-        for storing binary data and you require that the value retrieved
-        be exactly the same as the value stored. The following example
-        illustrates how <literal>0x00</literal>-padding of
-        <literal>BINARY</literal> values affects column value
-        comparisons:
+        characteristics carefully if you plan to use the
+        <literal>BINARY</literal> data type for storing binary data and
+        you require that the value retrieved be exactly the same as the
+        value stored. The following example illustrates how
+        <literal>0x00</literal>-padding of <literal>BINARY</literal>
+        values affects column value comparisons:
       </para>
 
 <programlisting>
@@ -3894,12 +3892,13 @@
 
       <para>
         If the value retrieved must be the same as the value specified
-        for storage with no padding, it might be preferable to use one
-        of the <literal>BLOB</literal> data types instead.
+        for storage with no padding, it might be preferable to use
+        <literal>VARBINARY</literal> or one of the
+        <literal>BLOB</literal> data types instead.
       </para>
 
       <para>
-        MySQL may silently change the type of a
+        In some cases, MySQL may silently change the type of a
         <literal>BINARY</literal> or <literal>VARBINARY</literal> column
         at table creation time. See
         <xref linkend="silent-column-changes"/>.
@@ -3998,7 +3997,7 @@
         exceeds the data type's maximum length, the value is truncated
         to fit. If the truncated characters are not spaces, a warning is
         generated. You can cause an error to occur and the value to be
-        rejected rather than to be truncated with awarning by using
+        rejected rather than to be truncated with a warning by using
         strict SQL mode. See <xref linkend="server-sql-mode"/>.
       </para>
 
@@ -4951,12 +4950,12 @@
               &lt; 2<superscript>32</superscript></entry>
           </row>
           <row>
-            <entry><literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal></entry>
+            <entry><literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',&hellip;)</literal></entry>
             <entry>1 or 2 bytes, depending on the number of enumeration values (65,535
               values maximum)</entry>
           </row>
           <row>
-            <entry><literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal></entry>
+            <entry><literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',&hellip;)</literal></entry>
             <entry>1, 2, 3, 4, or 8 bytes, depending on the number of set members (64
               members maximum)</entry>
           </row>
@@ -5046,8 +5045,8 @@
 
       <listitem>
         <para>
-          If the size of the column is 256 characters or more,
-          the column requires two bytes extra storage per row.
+          If the size of the column is 256 characters or more, the
+          column requires two bytes extra storage per row.
         </para>
       </listitem>
 

Modified: trunk/refman-5.1/data-types.xml
===================================================================
--- trunk/refman-5.1/data-types.xml	2006-01-18 19:31:50 UTC (rev 904)
+++ trunk/refman-5.1/data-types.xml	2006-01-18 19:32:04 UTC (rev 905)
@@ -455,7 +455,7 @@
 
                 All arithmetic is done using signed
                 <literal>BIGINT</literal> or <literal>DOUBLE</literal>
-                values, so you shouldn't use unsigned big integers
+                values, so you should not use unsigned big integers
                 larger than <literal>9223372036854775807</literal> (63
                 bits) except with bit functions! If you do that, some of
                 the last digits in the result may be wrong because of
@@ -473,8 +473,8 @@
 
                 <listitem>
                   <para>
-                    When using integers to store big unsigned values in
-                    a <literal>BIGINT</literal> column.
+                    When using integers to store large unsigned values
+                    in a <literal>BIGINT</literal> column.
                   </para>
                 </listitem>
 
@@ -980,18 +980,20 @@
           <para>
             A <literal>TIMESTAMP</literal> column is useful for
             recording the date and time of an <literal>INSERT</literal>
-            or <literal>UPDATE</literal> operation. The first
-            <literal>TIMESTAMP</literal> column in a table is
+            or <literal>UPDATE</literal> operation. By default, the
+            first <literal>TIMESTAMP</literal> column in a table is
             automatically set to the date and time of the most recent
-            operation if you don't assign it a value yourself. You can
+            operation if you do not assign it a value yourself. You can
             also set any <literal>TIMESTAMP</literal> column to the
             current date and time by assigning it a
-            <literal>NULL</literal> value.
+            <literal>NULL</literal> value. Variations on automatic
+            initialization and update properties are described in
+            <xref linkend="timestamp-4-1"/>.
           </para>
 
           <para>
             A <literal>TIMESTAMP</literal> value is returned as a string
-            in the format <literal>'YYYY-MM-DD HH:MM:SS'</literal>whose
+            in the format <literal>'YYYY-MM-DD HH:MM:SS'</literal> whose
             display width is fixed at 19 characters. If you want to
             obtain the value as a number, you should add
             <literal>+0</literal> to the timestamp column.
@@ -1100,9 +1102,9 @@
       </para>
 
       <para>
-        MySQL &current-series; string data types include some features
-        that you may not have encountered in working with versions of
-        MySQL prior to 4.1:
+        In MySQL 4.1 and up, string data types include some features
+        that you may not have encountered in working with previous
+        versions of MySQL (prior to 4.1):
       </para>
 
       <itemizedlist>
@@ -1111,9 +1113,10 @@
           <para>
             Column definitions for many string data types can include a
             <literal>CHARACTER SET</literal> attribute to specify the
-            character set and, optionally, a collation.
-            (<literal>CHARSET</literal> is a synonym for
-            <literal>CHARACTER SET</literal>.) These attributes apply to
+            character set. (<literal>CHARSET</literal> is a synonym for
+            <literal>CHARACTER SET</literal>.) The
+            <literal>COLLATE</literal> attribute specifies a collation
+            for the the character set. These attributes apply to
             <literal>CHAR</literal>, <literal>VARCHAR</literal>, the
             <literal>TEXT</literal> types, <literal>ENUM</literal>, and
             <literal>SET</literal>. For example:
@@ -1122,8 +1125,8 @@
 <programlisting>
 CREATE TABLE t
 (
-    c1 CHAR(20) CHARACTER SET utf8,
-    c2 CHAR(20) CHARACTER SET latin1 COLLATE latin1_bin
+    c1 VARCHAR(20) CHARACTER SET utf8,
+    c2 TEXT CHARACTER SET latin1 COLLATE latin1_general_cs
 );
 </programlisting>
 
@@ -1132,17 +1135,16 @@
             <literal>c1</literal> that has a character set of
             <literal>utf8</literal> with the default collation for that
             character set, and a column named <literal>c2</literal> that
-            has a character set of <literal>latin1</literal> and the
-            binary collation for the character set. The binary collation
-            is not case sensitive.
+            has a character set of <literal>latin1</literal> and a
+            case-sensitive collation.
           </para>
         </listitem>
 
         <listitem>
           <para>
             MySQL &current-series; interprets length specifications in
-            character column definitions in character units. (Some
-            earlier MySQL versions interpreted lengths in bytes.)
+            character column definitions in character units.
+            (Previously, MySQL interpreted lengths in bytes.)
           </para>
         </listitem>
 
@@ -1152,27 +1154,30 @@
             the <literal>TEXT</literal> types, the
             <literal>BINARY</literal> attribute causes the column to be
             assigned the binary collation of the column character set.
+            (Previously, <literal>BINARY</literal> caused a column to
+            store binary strings.)
           </para>
         </listitem>
 
         <listitem>
           <para>
             Character column sorting and comparison are based on the
-            character set assigned to the column. For earlier versions,
-            sorting and comparison are based on the collation of the
-            server character set. For <literal>CHAR</literal> and
+            character set assigned to the column. (Previously, sorting
+            and comparison were based on the collation of the server
+            character set.) For <literal>CHAR</literal> and
             <literal>VARCHAR</literal> columns, you can declare the
-            column with the <literal>BINARY</literal> attribute to cause
-            sorting and comparison to use the underlying character code
-            values rather then a lexical ordering.
+            column with a binary collation or the
+            <literal>BINARY</literal> attribute to cause sorting and
+            comparison to use the underlying character code values
+            rather than a lexical ordering.
           </para>
         </listitem>
 
       </itemizedlist>
 
       <para>
-        For more about character set support in MySQL &current-series;,
-        see <xref linkend="charset"/>.
+        <xref linkend="charset"/>, provides additional information about
+        use of character sets in MySQL.
       </para>
 
       <itemizedlist>
@@ -1722,7 +1727,7 @@
               <secondary>ENUM</secondary>
             </indexterm>
 
-            <literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal>
+            <literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',&hellip;)</literal>
           </para>
 
           <para>
@@ -1730,7 +1735,7 @@
             value, chosen from the list of values
             <literal>'<replaceable>value1</replaceable>'</literal>,
             <literal>'<replaceable>value2</replaceable>'</literal>,
-            <literal>...</literal>, <literal>NULL</literal> or the
+            <literal>&hellip;</literal>, <literal>NULL</literal> or the
             special <literal>''</literal> error value. An
             <literal>ENUM</literal> column can have a maximum of 65,535
             distinct values. <literal>ENUM</literal> values are
@@ -1755,7 +1760,7 @@
               <secondary>SET</secondary>
             </indexterm>
 
-            <literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal>
+            <literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',&hellip;)</literal>
           </para>
 
           <para>
@@ -1763,9 +1768,9 @@
             each of which must be chosen from the list of values
             <literal>'<replaceable>value1</replaceable>'</literal>,
             <literal>'<replaceable>value2</replaceable>'</literal>,
-            <literal>...</literal> A <literal>SET</literal> column can
-            have a maximum of 64 members. <literal>SET</literal> values
-            are represented internally as integers.
+            <literal>&hellip;</literal> A <literal>SET</literal> column
+            can have a maximum of 64 members. <literal>SET</literal>
+            values are represented internally as integers.
           </para>
 
           <remark role="help-description-end"/>
@@ -2188,7 +2193,7 @@
       zero because MySQL allows you to store dates where the day or
       month and day are zero in a <literal>DATE</literal> or
       <literal>DATETIME</literal> column. This is extremely useful for
-      applications that need to store a birthdate for which you don't
+      applications that need to store a birthdate for which you do not
       know the exact date. In this case, you simply store the date as
       <literal>'1999-00-00'</literal> or
       <literal>'1999-01-00'</literal>. If you store dates such as these,
@@ -2315,7 +2320,7 @@
               </row>
               <row>
                 <entry><literal>TIMESTAMP</literal></entry>
-                <entry><literal>00000000000000</literal></entry>
+                <entry><literal>'0000-00-00 00:00:00'</literal></entry>
               </row>
               <row>
                 <entry><literal>TIME</literal></entry>
@@ -2988,10 +2993,6 @@
 );
 </programlisting>
 
-        <remark>
-          Updated following to fix Bug#10104
-        </remark>
-
         <para>
           If the <literal>NULL</literal> attribute is not specified,
           setting the column to <literal>NULL</literal> sets it to the
@@ -3013,9 +3014,9 @@
 </programlisting>
 
         <para>
-          Otherwise - that is, if the <literal>TIMESTAMP</literal>
+          Otherwise &mdash; that is, if the <literal>TIMESTAMP</literal>
           column is defined using <literal>NULL</literal> but not using
-          <literal>DEFAULT TIMESTAMP</literal>, as shown here...
+          <literal>DEFAULT TIMESTAMP</literal>, as shown here&hellip;
         </para>
 
 <programlisting>
@@ -3024,8 +3025,8 @@
 </programlisting>
 
         <para>
-          ...then you must explicitly insert a value corresponding to
-          the current date and time. For example:
+          &hellip;then you must explicitly insert a value corresponding
+          to the current date and time. For example:
         </para>
 
 <programlisting>
@@ -3082,7 +3083,7 @@
             HH:MM'</literal>, <literal>'D HH'</literal>, or
             <literal>'SS'</literal>. Here <literal>D</literal>
             represents days and can have a value from 0 to 34. Note that
-            MySQL does not (yet) store the fraction.
+            MySQL does not store the fraction part.
           </para>
         </listitem>
 
@@ -3105,8 +3106,8 @@
             <literal>'10:11:12'</literal>. The following alternative
             formats are also understood: <literal>SS</literal>,
             <literal>MMSS</literal>, <literal>HHMMSS</literal>,
-            <literal>HHMMSS.fraction</literal>. Note that MySQL doesn't
-            (yet) store the fraction.
+            <literal>HHMMSS.fraction</literal>. Note that MySQL does not
+            store the fraction part.
           </para>
         </listitem>
 
@@ -3324,19 +3325,16 @@
 
       <para>
         <literal>ORDER BY</literal> properly sorts
-        <literal>TIMESTAMP</literal> or <literal>YEAR</literal> values
-        that have two-digit years.
+        <literal>YEAR</literal> values that have two-digit years.
       </para>
 
       <para>
         Some functions like <literal>MIN()</literal> and
-        <literal>MAX()</literal> convert a <literal>TIMESTAMP</literal>
-        or <literal>YEAR</literal> to a number. This means that a value
-        with a two-digit year does not work properly with these
-        functions. The fix in this case is to convert the
-        <literal>TIMESTAMP</literal> or <literal>YEAR</literal> to
-        four-digit year format or use something like
-        <literal>MIN(DATE_ADD(timestamp,INTERVAL 0 DAY))</literal>.
+        <literal>MAX()</literal> convert a <literal>YEAR</literal> to a
+        number. This means that a value with a two-digit year does not
+        work properly with these functions. The fix in this case is to
+        convert the <literal>TIMESTAMP</literal> or
+        <literal>YEAR</literal> to four-digit year format.
       </para>
 
     </section>
@@ -3705,12 +3703,12 @@
 
       <para>
         You should consider the preceding padding and stripping
-        characteristics carefully if you plan to use these data types
-        for storing binary data and you require that the value retrieved
-        be exactly the same as the value stored. The following example
-        illustrates how <literal>0x00</literal>-padding of
-        <literal>BINARY</literal> values affects column value
-        comparisons:
+        characteristics carefully if you plan to use the
+        <literal>BINARY</literal> data type for storing binary data and
+        you require that the value retrieved be exactly the same as the
+        value stored. The following example illustrates how
+        <literal>0x00</literal>-padding of <literal>BINARY</literal>
+        values affects column value comparisons:
       </para>
 
 <programlisting>
@@ -3735,17 +3733,11 @@
 
       <para>
         If the value retrieved must be the same as the value specified
-        for storage with no padding, it might be preferable to use one
-        of the <literal>BLOB</literal> data types instead.
+        for storage with no padding, it might be preferable to use
+        <literal>VARBINARY</literal> or one of the
+        <literal>BLOB</literal> data types instead.
       </para>
 
-      <para>
-        MySQL may silently change the type of a
-        <literal>BINARY</literal> or <literal>VARBINARY</literal> column
-        at table creation time. See
-        <xref linkend="silent-column-changes"/>.
-      </para>
-
     </section>
 
     <section id="blob">
@@ -3839,10 +3831,8 @@
         exceeds the data type's maximum length, the value is truncated
         to fit. If the truncated characters are not spaces, a warning is
         generated. You can cause an error to occur and the value to be
-        rejected rather than to be truncated with awarning by using
-        strict SQL mode. See
-        <xref
-          linkend="server-sql-mode"/>.
+        rejected rather than to be truncated with a warning by using
+        strict SQL mode. See <xref linkend="server-sql-mode"/>.
       </para>
 
       <para>
@@ -3859,22 +3849,6 @@
 
         <listitem>
           <para>
-            There is no trailing-space removal for
-            <literal>BLOB</literal> and <literal>TEXT</literal> columns
-            when values are stored or retrieved. (This is the same as
-            with <literal>VARBINARY</literal> and
-            <literal>VARCHAR</literal> columns.)
-          </para>
-
-          <para>
-            Note that <literal>TEXT</literal> is on comparison space
-            extended to fit the compared object, exactly like
-            <literal>CHAR</literal> and <literal>VARCHAR</literal>.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
             For indexes on <literal>BLOB</literal> and
             <literal>TEXT</literal> columns, you must specify an index
             prefix length. For <literal>CHAR</literal> and
@@ -4776,12 +4750,12 @@
               &lt; 2<superscript>32</superscript></entry>
           </row>
           <row>
-            <entry><literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal></entry>
+            <entry><literal>ENUM('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',&hellip;)</literal></entry>
             <entry>1 or 2 bytes, depending on the number of enumeration values (65,535
               values maximum)</entry>
           </row>
           <row>
-            <entry><literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',...)</literal></entry>
+            <entry><literal>SET('<replaceable>value1</replaceable>','<replaceable>value2</replaceable>',&hellip;)</literal></entry>
             <entry>1, 2, 3, 4, or 8 bytes, depending on the number of set members (64
               members maximum)</entry>
           </row>

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