List:Commits« Previous MessageNext Message »
From:paul Date:January 19 2006 5:47pm
Subject:svn commit - mysqldoc@docsrva: r933 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-19 18:47:39 +0100 (Thu, 19 Jan 2006)
New Revision: 933

Log:
 r6439@frost:  paul | 2006-01-19 11:47:04 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/data-types.xml
   trunk/refman-5.0/data-types.xml
   trunk/refman-5.0/sql-syntax.xml
   trunk/refman-5.0/stored-procedures.xml
   trunk/refman-5.1/data-types.xml
   trunk/refman-5.1/optimization.xml
   trunk/refman-5.1/partitioning.xml
   trunk/refman-5.1/sql-syntax.xml
   trunk/refman-5.1/stored-procedures.xml


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

Modified: trunk/refman-4.1/data-types.xml
===================================================================
--- trunk/refman-4.1/data-types.xml	2006-01-19 17:47:24 UTC (rev 932)
+++ trunk/refman-4.1/data-types.xml	2006-01-19 17:47:39 UTC (rev 933)
@@ -4179,30 +4179,26 @@
       <para>
         A <literal>BLOB</literal> is a binary large object that can hold
         a variable amount of data. The four <literal>BLOB</literal>
-        types, <literal>TINYBLOB</literal>, <literal>BLOB</literal>,
-        <literal>MEDIUMBLOB</literal>, and <literal>LONGBLOB</literal>,
-        differ only in the maximum length of the values they can hold.
+        types are <literal>TINYBLOB</literal>, <literal>BLOB</literal>,
+        <literal>MEDIUMBLOB</literal>, and <literal>LONGBLOB</literal>.
+        These differ only in the maximum length of the values they can
+        hold. The four <literal>TEXT</literal> types are
+        <literal>TINYTEXT</literal>, <literal>TEXT</literal>,
+        <literal>MEDIUMTEXT</literal>, and <literal>LONGTEXT</literal>.
+        These correspond to the four <literal>BLOB</literal> types and
+        have the same maximum lengths and storage requirements. See
+        <xref linkend="storage-requirements"/>. No lettercase conversion
+        for <literal>TEXT</literal> or <literal>BLOB</literal> columns
+        takes place during storage or retrieval.
       </para>
 
       <remark role="help-description-end"/>
 
       <para>
-        See <xref linkend="storage-requirements"/>.
-      </para>
-
-      <para>
-        The four <literal>TEXT</literal> types,
-        <literal>TINYTEXT</literal>, <literal>TEXT</literal>,
-        <literal>MEDIUMTEXT</literal>, and <literal>LONGTEXT</literal>,
-        correspond to the four <literal>BLOB</literal> types and have
-        the same maximum lengths and storage requirements.
-      </para>
-
-      <para>
         <literal>BLOB</literal> columns are treated as binary strings
         (byte strings). <literal>TEXT</literal> columns are treated as
         non-binary strings (character strings). <literal>BLOB</literal>
-        columns have no character set, and sorting and comparison is
+        columns have no character set, and sorting and comparison are
         based on the numeric values of the bytes in column values.
         <literal>TEXT</literal> columns have a character set, and values
         are sorted and compared based on the collation of the character
@@ -4216,18 +4212,13 @@
         comparisons are space-padded at the end. This means that, if the
         index requires unique values, duplicate-key errors will occur
         for values that differ only in the number of trailing spaces.
-        For example, inserting <literal>'a'</literal> and <literal>'a
-        '</literal> causes a duplicate-key error. This is not true for
+        For example, if a table contains <literal>'a'</literal>, an
+        attempt to store <literal>'a&nbsp;'</literal> causes a
+        duplicate-key error. This is not true for
         <literal>BLOB</literal> columns.
       </para>
 
       <para>
-        No lettercase conversion for <literal>TEXT</literal> or
-        <literal>BLOB</literal> columns takes place during storage or
-        retrieval.
-      </para>
-
-      <para>
         If you assign a value to a <literal>BLOB</literal> or
         <literal>TEXT</literal> column that exceeds the data type's
         maximum length, the value is truncated to fit. If the truncated
@@ -4242,7 +4233,7 @@
         <literal>TEXT</literal> column as a <literal>VARCHAR</literal>
         column. <literal>BLOB</literal> and <literal>TEXT</literal>
         differ from <literal>VARBINARY</literal> and
-        <literal>VARCHAR</literal> in the following ways::
+        <literal>VARCHAR</literal> in the following ways:
       </para>
 
       <itemizedlist>
@@ -4325,8 +4316,8 @@
 
       <para>
         Because <literal>BLOB</literal> and <literal>TEXT</literal>
-        values may be extremely long, you may encounter some constraints
-        in using them:
+        values can be extremely long, you might encounter some
+        constraints in using them:
       </para>
 
       <itemizedlist>
@@ -4335,8 +4326,9 @@
           <para>
             Only the first <literal>max_sort_length</literal> bytes of
             the column are used when sorting. The default value of
-            <literal>max_sort_length</literal> is 1024; this value can
-            be changed using the <option>--max_sort_length</option>
+            <literal>max_sort_length</literal> is 1024. This value can
+            be changed using the
+            <option>--max_sort_length=<replaceable>N</replaceable></option>
             option when starting the <command>mysqld</command> server.
             See <xref linkend="server-system-variables"/>.
           </para>
@@ -4351,7 +4343,7 @@
 
 <programlisting>
 mysql&gt; <userinput>SET max_sort_length = 2000;</userinput>
-mysql&gt; <userinput>SELECT id, comment FROM <replaceable>tbl_name</replaceable></userinput>
+mysql&gt; <userinput>SELECT id, comment FROM t</userinput>
     -&gt; <userinput>ORDER BY comment;</userinput>
 </programlisting>
 
@@ -4369,7 +4361,7 @@
           </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT id, SUBSTRING(comment,1,2000) FROM <replaceable>tbl_name</replaceable></userinput>
+mysql&gt; <userinput>SELECT id, SUBSTRING(comment,1,2000) FROM t</userinput>
     -&gt; <userinput>ORDER BY SUBSTRING(comment,1,2000);</userinput>
 </programlisting>
 
@@ -4466,6 +4458,11 @@
             the fact that this string has the numerical value 0. More
             about this later.
           </para>
+
+          <para>
+            If strict SQL mode is enabled, attempts to insert invalid
+            <literal>ENUM</literal> values result in an error.
+          </para>
         </listitem>
 
         <listitem>
@@ -4514,6 +4511,14 @@
           </para>
         </listitem>
 
+        <listitem>
+          <para>
+            The term <quote>index</quote> here refers only to position
+            within the list of enumeration values. It has nothing to do
+            with table indexes.
+          </para>
+        </listitem>
+
       </itemizedlist>
 
       <para>
@@ -4561,8 +4566,8 @@
 
       <para>
         Starting from MySQL 3.23.51, trailing spaces are automatically
-        deleted from <literal>ENUM</literal> member values when the
-        table is created.
+        deleted from <literal>ENUM</literal> member values in the table
+        definition when a table is created.
       </para>
 
       <para>
@@ -4655,7 +4660,7 @@
         <literal>SET</literal> column values that consist of multiple
         set members are specified with members separated by commas
         (&lsquo;<literal>,</literal>&rsquo;). A consequence of this is
-        that <literal>SET</literal> member values cannot themselves
+        that <literal>SET</literal> member values should not themselves
         contain commas.
       </para>
 
@@ -4678,8 +4683,8 @@
 
       <para>
         Starting from MySQL 3.23.51, trailing spaces are automatically
-        deleted from <literal>SET</literal> member values when the table
-        is created.
+        deleted from <literal>SET</literal> member values in the table
+        definition when a table is created.
       </para>
 
       <para>
@@ -4765,8 +4770,8 @@
         times a given element is listed in the value. When the value is
         retrieved later, each element in the value appears once, with
         elements listed according to the order in which they were
-        specified at table creation time. For example, suppose a column
-        is specified as <literal>SET('a','b','c','d')</literal>:
+        specified at table creation time. For example, suppose that a
+        column is specified as <literal>SET('a','b','c','d')</literal>:
       </para>
 
 <programlisting>
@@ -4774,7 +4779,7 @@
 </programlisting>
 
       <para>
-        and insert the values <literal>'a,d'</literal>,
+        If you insert the values <literal>'a,d'</literal>,
         <literal>'d,a'</literal>, <literal>'a,d,d'</literal>,
         <literal>'a,d,a'</literal>, and <literal>'d,a,d'</literal>:
       </para>
@@ -4787,7 +4792,7 @@
 </programlisting>
 
       <para>
-        then all of these values appear as <literal>'a,d'</literal> when
+        Then all of these values appear as <literal>'a,d'</literal> when
         retrieved:
       </para>
 
@@ -4837,6 +4842,11 @@
 </programlisting>
 
       <para>
+        If strict SQL mode is enabled, attempts to insert invalid
+        <literal>SET</literal> values result in an error.
+      </para>
+
+      <para>
         <literal>SET</literal> values are sorted numerically.
         <literal>NULL</literal> values sort before
         non-<literal>NULL</literal> <literal>SET</literal> values.

Modified: trunk/refman-5.0/data-types.xml
===================================================================
--- trunk/refman-5.0/data-types.xml	2006-01-19 17:47:24 UTC (rev 932)
+++ trunk/refman-5.0/data-types.xml	2006-01-19 17:47:39 UTC (rev 933)
@@ -3948,28 +3948,23 @@
         types are <literal>TINYBLOB</literal>, <literal>BLOB</literal>,
         <literal>MEDIUMBLOB</literal>, and <literal>LONGBLOB</literal>.
         These differ only in the maximum length of the values they can
-        hold.
-      </para>
-
-      <remark role="help-description-end"/>
-
-      <para>
-        The four <literal>TEXT</literal> types are
+        hold. The four <literal>TEXT</literal> types are
         <literal>TINYTEXT</literal>, <literal>TEXT</literal>,
         <literal>MEDIUMTEXT</literal>, and <literal>LONGTEXT</literal>.
         These correspond to the four <literal>BLOB</literal> types and
-        have the same maximum lengths and storage requirements.
+        have the same maximum lengths and storage requirements. See
+        <xref linkend="storage-requirements"/>. No lettercase conversion
+        for <literal>TEXT</literal> or <literal>BLOB</literal> columns
+        takes place during storage or retrieval.
       </para>
 
-      <para>
-        See <xref linkend="storage-requirements"/>.
-      </para>
+      <remark role="help-description-end"/>
 
       <para>
         <literal>BLOB</literal> columns are treated as binary strings
         (byte strings). <literal>TEXT</literal> columns are treated as
         non-binary strings (character strings). <literal>BLOB</literal>
-        columns have no character set, and sorting and comparison is
+        columns have no character set, and sorting and comparison are
         based on the numeric values of the bytes in column values.
         <literal>TEXT</literal> columns have a character set, and values
         are sorted and compared based on the collation of the character
@@ -3981,18 +3976,13 @@
         comparisons are space-padded at the end. This means that, if the
         index requires unique values, duplicate-key errors will occur
         for values that differ only in the number of trailing spaces.
-        For example, inserting <literal>'a'</literal> and <literal>'a
-        '</literal> causes a duplicate-key error. This is not true for
+        For example, if a table contains <literal>'a'</literal>, an
+        attempt to store <literal>'a&nbsp;'</literal> causes a
+        duplicate-key error. This is not true for
         <literal>BLOB</literal> columns.
       </para>
 
       <para>
-        No lettercase conversion for <literal>TEXT</literal> or
-        <literal>BLOB</literal> columns takes place during storage or
-        retrieval.
-      </para>
-
-      <para>
         When not running in strict mode, if you assign a value to a
         <literal>BLOB</literal> or <literal>TEXT</literal> column that
         exceeds the data type's maximum length, the value is truncated
@@ -4009,7 +3999,7 @@
         <literal>TEXT</literal> column as a <literal>VARCHAR</literal>
         column. <literal>BLOB</literal> and <literal>TEXT</literal>
         differ from <literal>VARBINARY</literal> and
-        <literal>VARCHAR</literal> in the following ways::
+        <literal>VARCHAR</literal> in the following ways:
       </para>
 
       <itemizedlist>
@@ -4081,8 +4071,8 @@
 
       <para>
         Because <literal>BLOB</literal> and <literal>TEXT</literal>
-        values may be extremely long, you may encounter some constraints
-        in using them:
+        values can be extremely long, you might encounter some
+        constraints in using them:
       </para>
 
       <itemizedlist>
@@ -4091,8 +4081,9 @@
           <para>
             Only the first <literal>max_sort_length</literal> bytes of
             the column are used when sorting. The default value of
-            <literal>max_sort_length</literal> is 1024; this value can
-            be changed using the <option>--max_sort_length</option>
+            <literal>max_sort_length</literal> is 1024. This value can
+            be changed using the
+            <option>--max_sort_length=<replaceable>N</replaceable></option>
             option when starting the <command>mysqld</command> server.
             See <xref linkend="server-system-variables"/>.
           </para>
@@ -4107,7 +4098,7 @@
 
 <programlisting>
 mysql&gt; <userinput>SET max_sort_length = 2000;</userinput>
-mysql&gt; <userinput>SELECT id, comment FROM <replaceable>tbl_name</replaceable></userinput>
+mysql&gt; <userinput>SELECT id, comment FROM t</userinput>
     -&gt; <userinput>ORDER BY comment;</userinput>
 </programlisting>
 
@@ -4125,7 +4116,7 @@
           </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT id, SUBSTRING(comment,1,2000) FROM <replaceable>tbl_name</replaceable></userinput>
+mysql&gt; <userinput>SELECT id, SUBSTRING(comment,1,2000) FROM t</userinput>
     -&gt; <userinput>ORDER BY SUBSTRING(comment,1,2000);</userinput>
 </programlisting>
         </listitem>
@@ -4208,6 +4199,11 @@
             the fact that this string has the numerical value 0. More
             about this later.
           </para>
+
+          <para>
+            If strict SQL mode is enabled, attempts to insert invalid
+            <literal>ENUM</literal> values result in an error.
+          </para>
         </listitem>
 
         <listitem>
@@ -4256,6 +4252,14 @@
           </para>
         </listitem>
 
+        <listitem>
+          <para>
+            The term <quote>index</quote> here refers only to position
+            within the list of enumeration values. It has nothing to do
+            with table indexes.
+          </para>
+        </listitem>
+
       </itemizedlist>
 
       <para>
@@ -4303,7 +4307,8 @@
 
       <para>
         Trailing spaces are automatically deleted from
-        <literal>ENUM</literal> member values when the table is created.
+        <literal>ENUM</literal> member values in the table definition
+        when a table is created.
       </para>
 
       <para>
@@ -4393,7 +4398,7 @@
         <literal>SET</literal> column values that consist of multiple
         set members are specified with members separated by commas
         (&lsquo;<literal>,</literal>&rsquo;). A consequence of this is
-        that <literal>SET</literal> member values cannot themselves
+        that <literal>SET</literal> member values should not themselves
         contain commas.
       </para>
 
@@ -4416,7 +4421,8 @@
 
       <para>
         Trailing spaces are automatically deleted from
-        <literal>SET</literal> member values when the table is created.
+        <literal>SET</literal> member values in the table definition
+        when a table is created.
       </para>
 
       <para>
@@ -4500,8 +4506,8 @@
         times a given element is listed in the value. When the value is
         retrieved later, each element in the value appears once, with
         elements listed according to the order in which they were
-        specified at table creation time. For example, suppose a column
-        is specified as <literal>SET('a','b','c','d')</literal>:
+        specified at table creation time. For example, suppose that a
+        column is specified as <literal>SET('a','b','c','d')</literal>:
       </para>
 
 <programlisting>
@@ -4509,7 +4515,7 @@
 </programlisting>
 
       <para>
-        and insert the values <literal>'a,d'</literal>,
+        If you insert the values <literal>'a,d'</literal>,
         <literal>'d,a'</literal>, <literal>'a,d,d'</literal>,
         <literal>'a,d,a'</literal>, and <literal>'d,a,d'</literal>:
       </para>
@@ -4522,7 +4528,7 @@
 </programlisting>
 
       <para>
-        then all of these values appear as <literal>'a,d'</literal> when
+        Then all of these values appear as <literal>'a,d'</literal> when
         retrieved:
       </para>
 
@@ -4572,6 +4578,11 @@
 </programlisting>
 
       <para>
+        If strict SQL mode is enabled, attempts to insert invalid
+        <literal>SET</literal> values result in an error.
+      </para>
+
+      <para>
         <literal>SET</literal> values are sorted numerically.
         <literal>NULL</literal> values sort before
         non-<literal>NULL</literal> <literal>SET</literal> values.

Modified: trunk/refman-5.0/sql-syntax.xml
===================================================================
--- trunk/refman-5.0/sql-syntax.xml	2006-01-19 17:47:24 UTC (rev 932)
+++ trunk/refman-5.0/sql-syntax.xml	2006-01-19 17:47:39 UTC (rev 933)
@@ -7441,8 +7441,8 @@
           <listitem>
             <para>
               The evaluation of multi-way natural joins differs in a way
-              that can require query rewriting. Suppose you have three
-              tables <literal>t1(a,b)</literal>,
+              that can require query rewriting. Suppose that you have
+              three tables <literal>t1(a,b)</literal>,
               <literal>t2(c,b)</literal>, and <literal>t3(a,c)</literal>
               that each have one row: <literal>t1(1,2)</literal>,
               <literal>t2(10,2)</literal>, and

Modified: trunk/refman-5.0/stored-procedures.xml
===================================================================
--- trunk/refman-5.0/stored-procedures.xml	2006-01-19 17:47:24 UTC (rev 932)
+++ trunk/refman-5.0/stored-procedures.xml	2006-01-19 17:47:39 UTC (rev 933)
@@ -428,7 +428,9 @@
         <literal>MODIFIES SQL DATA</literal> indicates that the routine
         contains statements that may write data. <literal>CONTAINS
         SQL</literal> is the default if none of these characteristics is
-        given explicitly.
+        given explicitly. These characteristics are advisory only. The
+        server does not use them to constrain what kinds of statements a
+        routine will be allowed to execute.
       </para>
 
       <para>

Modified: trunk/refman-5.1/data-types.xml
===================================================================
--- trunk/refman-5.1/data-types.xml	2006-01-19 17:47:24 UTC (rev 932)
+++ trunk/refman-5.1/data-types.xml	2006-01-19 17:47:39 UTC (rev 933)
@@ -3595,7 +3595,8 @@
         unique values, inserting into the column values that differ only
         in number of trailing pad characters will result in a
         duplicate-key error. For example, if a table contains
-        <literal>'a'</literal>, an attempt to store <literal>'a&nbsp;'</literal> causes a duplicate-key error.
+        <literal>'a'</literal>, an attempt to store
+        <literal>'a&nbsp;'</literal> causes a duplicate-key error.
       </para>
 
     </section>
@@ -3691,9 +3692,9 @@
         comparisons ignore them, if a column has an index that requires
         unique values, inserting into the column values that differ only
         in number of trailing pad bytes will result in a duplicate-key
-        error.
-        For example, if a table contains
-        <literal>'a'</literal>, an attempt to store <literal>'a\0'</literal> causes a duplicate-key error.
+        error. For example, if a table contains <literal>'a'</literal>,
+        an attempt to store <literal>'a\0'</literal> causes a
+        duplicate-key error.
       </para>
 
       <para>
@@ -3776,28 +3777,23 @@
         types are <literal>TINYBLOB</literal>, <literal>BLOB</literal>,
         <literal>MEDIUMBLOB</literal>, and <literal>LONGBLOB</literal>.
         These differ only in the maximum length of the values they can
-        hold.
-      </para>
-
-      <remark role="help-description-end"/>
-
-      <para>
-        The four <literal>TEXT</literal> types are
+        hold. The four <literal>TEXT</literal> types are
         <literal>TINYTEXT</literal>, <literal>TEXT</literal>,
         <literal>MEDIUMTEXT</literal>, and <literal>LONGTEXT</literal>.
         These correspond to the four <literal>BLOB</literal> types and
-        have the same maximum lengths and storage requirements.
+        have the same maximum lengths and storage requirements. See
+        <xref linkend="storage-requirements"/>. No lettercase conversion
+        for <literal>TEXT</literal> or <literal>BLOB</literal> columns
+        takes place during storage or retrieval.
       </para>
 
-      <para>
-        See <xref linkend="storage-requirements"/>.
-      </para>
+      <remark role="help-description-end"/>
 
       <para>
         <literal>BLOB</literal> columns are treated as binary strings
         (byte strings). <literal>TEXT</literal> columns are treated as
         non-binary strings (character strings). <literal>BLOB</literal>
-        columns have no character set, and sorting and comparison is
+        columns have no character set, and sorting and comparison are
         based on the numeric values of the bytes in column values.
         <literal>TEXT</literal> columns have a character set, and values
         are sorted and compared based on the collation of the character
@@ -3809,18 +3805,13 @@
         comparisons are space-padded at the end. This means that, if the
         index requires unique values, duplicate-key errors will occur
         for values that differ only in the number of trailing spaces.
-        For example, inserting <literal>'a'</literal> and <literal>'a
-        '</literal> causes a duplicate-key error. This is not true for
+        For example, if a table contains <literal>'a'</literal>, an
+        attempt to store <literal>'a&nbsp;'</literal> causes a
+        duplicate-key error. This is not true for
         <literal>BLOB</literal> columns.
       </para>
 
       <para>
-        No lettercase conversion for <literal>TEXT</literal> or
-        <literal>BLOB</literal> columns takes place during storage or
-        retrieval.
-      </para>
-
-      <para>
         When not running in strict mode, if you assign a value to a
         <literal>BLOB</literal> or <literal>TEXT</literal> column that
         exceeds the data type's maximum length, the value is truncated
@@ -3837,7 +3828,7 @@
         <literal>TEXT</literal> column as a <literal>VARCHAR</literal>
         column. <literal>BLOB</literal> and <literal>TEXT</literal>
         differ from <literal>VARBINARY</literal> and
-        <literal>VARCHAR</literal> in the following ways::
+        <literal>VARCHAR</literal> in the following ways:
       </para>
 
       <itemizedlist>
@@ -3892,8 +3883,8 @@
 
       <para>
         Because <literal>BLOB</literal> and <literal>TEXT</literal>
-        values may be extremely long, you may encounter some constraints
-        in using them:
+        values can be extremely long, you might encounter some
+        constraints in using them:
       </para>
 
       <itemizedlist>
@@ -3902,8 +3893,9 @@
           <para>
             Only the first <literal>max_sort_length</literal> bytes of
             the column are used when sorting. The default value of
-            <literal>max_sort_length</literal> is 1024; this value can
-            be changed using the <option>--max_sort_length</option>
+            <literal>max_sort_length</literal> is 1024. This value can
+            be changed using the
+            <option>--max_sort_length=<replaceable>N</replaceable></option>
             option when starting the <command>mysqld</command> server.
             See <xref linkend="server-system-variables"/>.
           </para>
@@ -3918,7 +3910,7 @@
 
 <programlisting>
 mysql&gt; <userinput>SET max_sort_length = 2000;</userinput>
-mysql&gt; <userinput>SELECT id, comment FROM <replaceable>tbl_name</replaceable></userinput>
+mysql&gt; <userinput>SELECT id, comment FROM t</userinput>
     -&gt; <userinput>ORDER BY comment;</userinput>
 </programlisting>
 
@@ -3936,7 +3928,7 @@
           </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT id, SUBSTRING(comment,1,2000) FROM <replaceable>tbl_name</replaceable></userinput>
+mysql&gt; <userinput>SELECT id, SUBSTRING(comment,1,2000) FROM t</userinput>
     -&gt; <userinput>ORDER BY SUBSTRING(comment,1,2000);</userinput>
 </programlisting>
         </listitem>
@@ -4019,6 +4011,11 @@
             the fact that this string has the numerical value 0. More
             about this later.
           </para>
+
+          <para>
+            If strict SQL mode is enabled, attempts to insert invalid
+            <literal>ENUM</literal> values result in an error.
+          </para>
         </listitem>
 
         <listitem>
@@ -4067,6 +4064,14 @@
           </para>
         </listitem>
 
+        <listitem>
+          <para>
+            The term <quote>index</quote> here refers only to position
+            within the list of enumeration values. It has nothing to do
+            with table indexes.
+          </para>
+        </listitem>
+
       </itemizedlist>
 
       <para>
@@ -4114,7 +4119,8 @@
 
       <para>
         Trailing spaces are automatically deleted from
-        <literal>ENUM</literal> member values when the table is created.
+        <literal>ENUM</literal> member values in the table definition
+        when a table is created.
       </para>
 
       <para>
@@ -4204,7 +4210,7 @@
         <literal>SET</literal> column values that consist of multiple
         set members are specified with members separated by commas
         (&lsquo;<literal>,</literal>&rsquo;). A consequence of this is
-        that <literal>SET</literal> member values cannot themselves
+        that <literal>SET</literal> member values should not themselves
         contain commas.
       </para>
 
@@ -4227,7 +4233,8 @@
 
       <para>
         Trailing spaces are automatically deleted from
-        <literal>SET</literal> member values when the table is created.
+        <literal>SET</literal> member values in the table definition
+        when a table is created.
       </para>
 
       <para>
@@ -4311,8 +4318,8 @@
         times a given element is listed in the value. When the value is
         retrieved later, each element in the value appears once, with
         elements listed according to the order in which they were
-        specified at table creation time. For example, suppose a column
-        is specified as <literal>SET('a','b','c','d')</literal>:
+        specified at table creation time. For example, suppose that a
+        column is specified as <literal>SET('a','b','c','d')</literal>:
       </para>
 
 <programlisting>
@@ -4320,7 +4327,7 @@
 </programlisting>
 
       <para>
-        and insert the values <literal>'a,d'</literal>,
+        If you insert the values <literal>'a,d'</literal>,
         <literal>'d,a'</literal>, <literal>'a,d,d'</literal>,
         <literal>'a,d,a'</literal>, and <literal>'d,a,d'</literal>:
       </para>
@@ -4333,7 +4340,7 @@
 </programlisting>
 
       <para>
-        then all of these values appear as <literal>'a,d'</literal> when
+        Then all of these values appear as <literal>'a,d'</literal> when
         retrieved:
       </para>
 
@@ -4383,6 +4390,11 @@
 </programlisting>
 
       <para>
+        If strict SQL mode is enabled, attempts to insert invalid
+        <literal>SET</literal> values result in an error.
+      </para>
+
+      <para>
         <literal>SET</literal> values are sorted numerically.
         <literal>NULL</literal> values sort before
         non-<literal>NULL</literal> <literal>SET</literal> values.

Modified: trunk/refman-5.1/optimization.xml
===================================================================
--- trunk/refman-5.1/optimization.xml	2006-01-19 17:47:24 UTC (rev 932)
+++ trunk/refman-5.1/optimization.xml	2006-01-19 17:47:39 UTC (rev 933)
@@ -726,12 +726,12 @@
             tables are joined and in which order.
           </para>
         </listitem>
-        
+
         <listitem>
           <para>
             <literal>EXPLAIN PARTITIONS</literal> is available beginning
             with MySQL 5.1.5. It is useful only when examining queries
-            involving partitioned tables. For details, see 
+            involving partitioned tables. For details, see
             <xref linkend="partitioning-info"/>.
           </para>
         </listitem>
@@ -796,7 +796,7 @@
         of rewriting and optimization rules, and possibly other notes
         about the optimization process.
       </para>
-      
+
       <para>
         <emphasis role="bold">Note</emphasis>: You cannot use the
         <literal>EXTENDED</literal> and <literal>PARTITIONS</literal>

Modified: trunk/refman-5.1/partitioning.xml
===================================================================
--- trunk/refman-5.1/partitioning.xml	2006-01-19 17:47:24 UTC (rev 932)
+++ trunk/refman-5.1/partitioning.xml	2006-01-19 17:47:39 UTC (rev 933)
@@ -1078,7 +1078,7 @@
       </para>
 
       <para>
-        By way of contrast, suppose you have a column named
+        By way of contrast, suppose that you have a column named
         <literal>int_col</literal> whose type is <literal>INT</literal>.
         Now consider the expression <literal>POW(5-int_col,3) +
         6</literal>. This would be a poor choice for a hashing function
@@ -1860,7 +1860,7 @@
         value were zero. We can verify this behavior by examining the
         effects on the filesystem of creating a table partitioned by
         <literal>HASH</literal> and populating it with a record
-        containing appropriate values. Suppose you have a table
+        containing appropriate values. Suppose that you have a table
         <literal>tnhash</literal>, created in the
         <literal>test</literal> database, using this statement:
       </para>
@@ -1933,7 +1933,7 @@
       </para>
 
       <para>
-        Suppose we have a table such as this one:
+        Suppose that we have a table such as this one:
       </para>
 
 <programlisting>
@@ -2055,8 +2055,8 @@
       has the same syntax as that as used with <literal>CREATE
       TABLE</literal> for creating a partitioned table, and always
       begins with the keywords <literal>PARTITION BY</literal>. For
-      example, suppose you have a table partitioned by range using the
-      following <literal>CREATE TABLE</literal> statement:
+      example, suppose that you have a table partitioned by range using
+      the following <literal>CREATE TABLE</literal> statement:
     </para>
 
 <programlisting>
@@ -2692,8 +2692,8 @@
         <literal>RANGE</literal> or <literal>LIST</literal>. However,
         you can merge <literal>HASH</literal> or <literal>KEY</literal>
         partitions using the <literal>ALTER TABLE ... COALESCE
-        PARTITION</literal> command. For example, suppose you have a
-        table containing data about clients, which is divided into
+        PARTITION</literal> command. For example, suppose that you have
+        a table containing data about clients, which is divided into
         twelve partitions. The <literal>clients</literal> table is
         defined as shown here:
       </para>
@@ -2949,15 +2949,15 @@
       <indexterm>
         <primary>partitioning information commands</primary>
       </indexterm>
-      
+
       <indexterm>
         <primary>information about partitions, obtaining</primary>
       </indexterm>
-      
+
       <indexterm>
         <primary>EXPLAIN used with partitioned tables</primary>
       </indexterm>
-      
+
       <indexterm>
         <primary>EXPLAIN PARTITIONS</primary>
       </indexterm>
@@ -2998,13 +2998,13 @@
         <emphasis role="bold">Note</emphasis>: In early MySQL 5.1
         releases, the <literal>PARTITIONS</literal> clause was not shown
         for tables partitioned by <literal>HASH</literal> or
-        <literal>KEY</literal>. This issue was fixed in MySQL 5.1.6. 
+        <literal>KEY</literal>. This issue was fixed in MySQL 5.1.6.
       </para>
-      
+
       <remark role="note">
         [js] Last sentence of following para commented out until its
         determined whether we will actually implement SHOW PARTITION
-        STATUS. 
+        STATUS.
       </remark>
 
       <para>
@@ -3013,23 +3013,25 @@
         tables, except that the <literal>Engine</literal> column always
         contains the value <literal>'PARTITION'</literal>. (See
         <xref linkend="show-table-status"/>, for more information about
-        this command.) <!-- To obtain status information for individual
+        this command.)
+
+<!-- To obtain status information for individual
         partitions, we plan to implement a <literal>SHOW PARTITION
         STATUS</literal> command (see below). -->
       </para>
-      
+
       <para>
         You can also obtain information about partitions from
         <literal>INFORMATION_SCHEMA</literal>, which contains a
         <literal>PARTITIONS</literal> table. See
         <xref linkend="partitions-table"/>.
       </para>
-      
+
       <remark role="note">
         [js] The following is commented out until it is determined
         whether these two statements will actually be implemented.
       </remark>
-      
+
 <!--
       <para>
         Two additional <literal>SHOW</literal> commands are planned for
@@ -3082,22 +3084,22 @@
 
       </itemizedlist>
 -->
-      
+
       <para>
         Beginning with MySQL 5.1.5, it is possible to determine which
         partitions of a partitioned table are involved in a given
         <literal>SELECT</literal> query using <literal>EXPLAIN
-          PARTITIONS</literal>. The <literal>PARTITIONS</literal>
-        keyword adds a <literal>partitions</literal> column to the
-        output of <literal>EXPLAIN</literal> listing the partitions from
-        which records would be matched by the query.
+        PARTITIONS</literal>. The <literal>PARTITIONS</literal> keyword
+        adds a <literal>partitions</literal> column to the output of
+        <literal>EXPLAIN</literal> listing the partitions from which
+        records would be matched by the query.
       </para>
-      
+
       <para>
-        Suppose you have a table <literal>trb1</literal> defined and
-        populated as follows:
+        Suppose that you have a table <literal>trb1</literal> defined
+        and populated as follows:
       </para>
-      
+
 <programlisting>
 CREATE TABLE trb1 (id INT, name VARCHAR(50), purchased DATE)
     PARTITION BY RANGE(id)
@@ -3123,9 +3125,9 @@
 
       <para>
         You can see which partitions are used in a query such as
-        <literal>SELECT * FROM trb1;</literal>, as shown here:   
+        <literal>SELECT * FROM trb1;</literal>, as shown here:
       </para>
-      
+
 <programlisting>
 mysql&gt; <userinput>EXPLAIN PARTITIONS SELECT * FROM trb1\G</userinput>
 *************************** 1. row ***************************
@@ -3141,14 +3143,14 @@
          rows: 10
         Extra: Using filesort
 </programlisting>
-      
+
       <para>
         In this case, all four partitions are searched. However, when a
         limiting condition making use of the partitioning key is added
         to the query, you can see that only those partitions containing
         matching values are scanned, as shown here:
       </para>
-      
+
 <programlisting>
 mysql&gt; <userinput>EXPLAIN PARTITIONS SELECT * FROM trb1 WHERE id &lt; 5\G</userinput>
 *************************** 1. row ***************************
@@ -3164,7 +3166,7 @@
          rows: 10
         Extra: Using where
 </programlisting>
-      
+
       <para>
         <literal>EXPLAIN PARTITIONS</literal> provides information about
         keys used and possible keys, just as with the standard
@@ -3190,13 +3192,14 @@
          rows: 7
         Extra: Using where
 </programlisting>
-      
+
       <para>
         You should take note of the following restrictions and
         limitations:
       </para>
-      
+
       <itemizedlist>
+
         <listitem>
           <para>
             You cannot use the <literal>PARTITIONS</literal> and
@@ -3205,7 +3208,7 @@
             to do so produces a syntax error.
           </para>
         </listitem>
-        
+
         <listitem>
           <para>
             <literal>EXPLAIN PARTITIONS</literal> provides meaningful
@@ -3216,15 +3219,15 @@
             partitions in the table are listed in the
             <literal>partitions</literal> column of the output.)
           </para>
-          
+
           <para>
             If <literal>EXPLAIN PARTITIONS</literal> is used to examine
             a query against a non-partitioned table, no error is
             produced, but the value of the <literal>partitions</literal>
-            column is always <literal>NULL</literal>. 
+            column is always <literal>NULL</literal>.
           </para>
         </listitem>
-        
+
         <listitem>
           <para>
             <literal>EXPLAIN PARTITIONS</literal> currently works
@@ -3232,8 +3235,9 @@
             of an integer datatype.
           </para>
         </listitem>
+
       </itemizedlist>
-      
+
     </section>
 
   </section>

Modified: trunk/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/refman-5.1/sql-syntax.xml	2006-01-19 17:47:24 UTC (rev 932)
+++ trunk/refman-5.1/sql-syntax.xml	2006-01-19 17:47:39 UTC (rev 933)
@@ -801,7 +801,7 @@
             the same options as the clause of the same name does for the
             <literal>CREATE TABLE</literal> statement clause of the same
             name. (See <xref linkend="create-table"/>, for the syntax
-            and description.) For example, suppose you have the
+            and description.) For example, suppose that you have the
             partitioned table created as shown here:
           </para>
 
@@ -2872,9 +2872,9 @@
               </para>
 
               <para>
-                For example, suppose you have a table that you wish to
-                partition on a column containing year values, according
-                to the following scheme:
+                For example, suppose that you have a table that you wish
+                to partition on a column containing year values,
+                according to the following scheme:
               </para>
 
               <informaltable>
@@ -2892,19 +2892,19 @@
                     </row>
                     <row>
                       <entry>1</entry>
-                      <entry>1991 - 1994</entry>
+                      <entry>1991 &minus; 1994</entry>
                     </row>
                     <row>
                       <entry>2</entry>
-                      <entry>1995 - 1998</entry>
+                      <entry>1995 &minus; 1998</entry>
                     </row>
                     <row>
                       <entry>3</entry>
-                      <entry>1999 - 2002</entry>
+                      <entry>1999 &minus; 2002</entry>
                     </row>
                     <row>
                       <entry>4</entry>
-                      <entry>2003 - 2005</entry>
+                      <entry>2003 &minus; 2005</entry>
                     </row>
                     <row>
                       <entry>5</entry>
@@ -8006,8 +8006,8 @@
           <listitem>
             <para>
               The evaluation of multi-way natural joins differs in a way
-              that can require query rewriting. Suppose you have three
-              tables <literal>t1(a,b)</literal>,
+              that can require query rewriting. Suppose that you have
+              three tables <literal>t1(a,b)</literal>,
               <literal>t2(c,b)</literal>, and <literal>t3(a,c)</literal>
               that each have one row: <literal>t1(1,2)</literal>,
               <literal>t2(10,2)</literal>, and

Modified: trunk/refman-5.1/stored-procedures.xml
===================================================================
--- trunk/refman-5.1/stored-procedures.xml	2006-01-19 17:47:24 UTC (rev 932)
+++ trunk/refman-5.1/stored-procedures.xml	2006-01-19 17:47:39 UTC (rev 933)
@@ -418,7 +418,9 @@
         <literal>MODIFIES SQL DATA</literal> indicates that the routine
         contains statements that may write data. <literal>CONTAINS
         SQL</literal> is the default if none of these characteristics is
-        given explicitly.
+        given explicitly. These characteristics are advisory only. The
+        server does not use them to constrain what kinds of statements a
+        routine will be allowed to execute.
       </para>
 
       <para>

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