List:Commits« Previous MessageNext Message »
From:paul Date:January 30 2006 3:37pm
Subject:svn commit - mysqldoc@docsrva: r1127 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-30 16:37:06 +0100 (Mon, 30 Jan 2006)
New Revision: 1127

Log:
 r6915@frost:  paul | 2006-01-30 09:25:17 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/restrictions.xml
   trunk/refman-5.0/restrictions.xml
   trunk/refman-5.1/restrictions.xml


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

Modified: trunk/refman-4.1/restrictions.xml
===================================================================
--- trunk/refman-4.1/restrictions.xml	2006-01-30 15:36:40 UTC (rev 1126)
+++ trunk/refman-4.1/restrictions.xml	2006-01-30 15:37:06 UTC (rev 1127)
@@ -49,6 +49,36 @@
     </para>
 
     <para>
+      In general, you cannot modify a table and select from the same
+      table in a subquery. For example, this limitation applies to
+      statements of the following forms:
+    </para>
+
+<programlisting>
+DELETE FROM t WHERE ... (SELECT ... FROM t ...);
+UPDATE t ... WHERE col = (SELECT ... FROM t ...);
+{INSERT|REPLACE} INTO t (SELECT ... FROM t ...);
+</programlisting>
+
+    <para>
+      Exception: The preceding prohibition does not apply if you are
+      using a subquery for the modified table in the
+      <literal>FROM</literal> clause. Example:
+    </para>
+
+<programlisting>
+UPDATE t ... WHERE col = (SELECT (SELECT ... FROM t...) AS _t ...);
+</programlisting>
+
+    <para>
+      Here the prohibition does not apply because a subquery in the
+      <literal>FROM</literal> clause is materialized as a temporary
+      table, so the relevant rows in <literal>t</literal> have already
+      been selected by the time the update to <literal>t</literal> takes
+      place.
+    </para>
+
+    <para>
       Row comparison operations are only partially supported:
     </para>
 
@@ -98,10 +128,10 @@
     <para>
       The reason for supporting row comparisons for
       <literal>IN</literal> but not for the others is that
-      <literal>IN</literal> was implemented by rewriting it as a
-      sequence of <literal>=</literal> comparisons and
-      <literal>AND</literal> operations. This approach cannot be used
-      for <literal>ALL</literal>, <literal>ANY</literal>, or
+      <literal>IN</literal> is implemented by rewriting it as a sequence
+      of <literal>=</literal> comparisons and <literal>AND</literal>
+      operations. This approach cannot be used for
+      <literal>ALL</literal>, <literal>ANY</literal>, or
       <literal>SOME</literal>.
     </para>
 
@@ -117,7 +147,7 @@
 
     <para>
       Subquery optimization for <literal>IN</literal> is not as
-      effective as for <literal>=</literal>.
+      effective as for the <literal>=</literal> operator.
     </para>
 
     <para>
@@ -135,36 +165,6 @@
     </para>
 
     <para>
-      In general, you cannot modify a table and select from the same
-      table in a subquery. For example, this limitation applies to
-      statements of the following forms:
-    </para>
-
-<programlisting>
-DELETE FROM t WHERE ... (SELECT ... FROM t ...);
-UPDATE t ... WHERE col = (SELECT ... FROM t ...);
-{INSERT|REPLACE} INTO t (SELECT ... FROM t ...);
-</programlisting>
-
-    <para>
-      Exception: The preceding prohibition does not apply if you are
-      using a subquery for the modified table in the
-      <literal>FROM</literal> clause. Example:
-    </para>
-
-<programlisting>
-UPDATE t ... WHERE col = (SELECT (SELECT ... FROM t...) AS _t ...);
-</programlisting>
-
-    <para>
-      Here the prohibition does not apply because a subquery in the
-      <literal>FROM</literal> clause is materialized as a temporary
-      table, so the relevant rows in <literal>t</literal> have already
-      been selected by the time the update to <literal>t</literal> takes
-      place.
-    </para>
-
-    <para>
       The optimizer is more mature for joins than for subqueries, so in
       many cases a statement that uses a subquery can be executed more
       efficiently if you rewrite it as a join.
@@ -195,12 +195,12 @@
     </para>
 
     <para>
-      Possible future optimization: MySQL doesn't rewrite the join order
-      for subquery evaluation. In some cases, a subquery could be
+      Possible future optimization: MySQL does not rewrite the join
+      order for subquery evaluation. In some cases, a subquery could be
       executed more efficiently if MySQL rewrote it as a join. This
       would give the optimizer a chance to choose between more execution
-      plans. For example, it can decide whether to read one table or the
-      other first.
+      plans. For example, it could decide whether to read one table or
+      the other first.
     </para>
 
     <para>
@@ -241,7 +241,7 @@
       Possible future optimization: A correlated subquery is evaluated
       for each row of the outer query. A better approach is that if the
       outer row values do not change from the previous row, do not
-      evaluate the subquery again. Instead use its previous result.
+      evaluate the subquery again. Instead, use its previous result.
     </para>
 
     <para>
@@ -276,7 +276,7 @@
       This type of rewriting would provide two benefits:
     </para>
 
-    <orderedlist>
+    <itemizedlist>
 
       <listitem>
         <para>
@@ -295,7 +295,7 @@
         </para>
       </listitem>
 
-    </orderedlist>
+    </itemizedlist>
 
     <para>
       Possible future optimization: For <literal>IN</literal>,

Modified: trunk/refman-5.0/restrictions.xml
===================================================================
--- trunk/refman-5.0/restrictions.xml	2006-01-30 15:36:40 UTC (rev 1126)
+++ trunk/refman-5.0/restrictions.xml	2006-01-30 15:37:06 UTC (rev 1127)
@@ -54,18 +54,8 @@
     </para>
 
     <para>
-      <emphasis role="bold">Note</emphasis>: If an SQL statement, such
-      as a <literal>SELECT ... INTO</literal> statement, contains a
-      reference to a column and a declared local variable with the same
-      name, MySQL interprets the reference as the name of a variable.
-      This is non-standard behavior; the order of precedence is usually
-      column names, then SQL variables and parameters. See
-      <xref linkend="select-into-statement"/>.
-    </para>
-
-    <para>
       Stored routines cannot contain arbitrary SQL statements. The
-      following statements are disallowed within stored routines:
+      following statements are disallowed:
     </para>
 
     <itemizedlist>
@@ -124,19 +114,18 @@
         <para>
           Statements that return a result set. This includes
           <literal>SELECT</literal> statements that do not have an
-          <literal>INTO</literal> clause and <literal>SHOW</literal>
-          statements. A function can process a result set either with
-          <literal>SELECT ... INTO</literal> or by using a cursor and
-          <literal>FETCH</literal> statements.
+          <literal>INTO <replaceable>var_list</replaceable></literal>
+          clause and <literal>SHOW</literal> statements. A function can
+          process a result set either with <literal>SELECT ... INTO
+          <replaceable>var_list</replaceable></literal> or by using a
+          cursor and <literal>FETCH</literal> statements. See
+          <xref linkend="select-into-statement"/>.
         </para>
       </listitem>
 
       <listitem>
         <para>
-          <literal>FLUSH</literal> statements. Note that while you may
-          use <literal>FLUSH</literal> in a stored procedure, such a
-          stored procedure cannot be called from a stored function or
-          trigger.
+          <literal>FLUSH</literal> statements.
         </para>
       </listitem>
 
@@ -167,7 +156,10 @@
       Note that although some restrictions normally apply to stored
       functions and triggers but not to stored procedures, those
       restrictions do apply to stored procedures if they are invoked
-      from within a stored function or trigger.
+      from within a stored function or trigger. For example, although
+      you can use <literal>FLUSH</literal> in a stored procedure, such a
+      stored procedure cannot be called from a stored function or
+      trigger.
     </para>
 
     <para>
@@ -219,7 +211,7 @@
 
     <para>
       The behavior that table columns do not take precedence over
-      variable s is non-standard.
+      variables is non-standard.
     </para>
 
     <para>
@@ -247,6 +239,14 @@
     </para>
 
     <para>
+      <literal>UNDO</literal> handlers are not supported.
+    </para>
+
+    <para>
+      <literal>FOR</literal> loops are not supported.
+    </para>
+
+    <para>
       To prevent problems of interaction between server threads, when a
       client issues a statement, the server uses a snapshot of routines
       and triggers available for execution of the statement. That is,
@@ -257,14 +257,6 @@
       performed by other threads.
     </para>
 
-    <para>
-      <literal>UNDO</literal> handlers are not supported.
-    </para>
-
-    <para>
-      <literal>FOR</literal> loops are not supported.
-    </para>
-
   </section>
 
   <section id="cursor-restrictions">
@@ -291,14 +283,15 @@
     </para>
 
     <para>
-      A server-side cursor is materialized into a temporary table.
-      Initially, this is a <literal>MEMORY</literal> table, but is
-      converted to a <literal>MyISAM</literal> table if its size reaches
-      the value of the <literal>max_heap_table_size</literal> system
-      variable. (Beginning with MySQL 5.0.14, the same temporary-table
-      implementation also is used for cursors in stored routines.) One
-      limitation of the implementation is that for a large result set,
-      retrieving its rows through a cursor might be slow.
+      In MySQL, a server-side cursor is materialized into a temporary
+      table. Initially, this is a <literal>MEMORY</literal> table, but
+      is converted to a <literal>MyISAM</literal> table if its size
+      reaches the value of the <literal>max_heap_table_size</literal>
+      system variable. (Beginning with MySQL 5.0.14, the same
+      temporary-table implementation also is used for cursors in stored
+      routines.) One limitation of the implementation is that for a
+      large result set, retrieving its rows through a cursor might be
+      slow.
     </para>
 
     <para>
@@ -374,6 +367,36 @@
     </para>
 
     <para>
+      In general, you cannot modify a table and select from the same
+      table in a subquery. For example, this limitation applies to
+      statements of the following forms:
+    </para>
+
+<programlisting>
+DELETE FROM t WHERE ... (SELECT ... FROM t ...);
+UPDATE t ... WHERE col = (SELECT ... FROM t ...);
+{INSERT|REPLACE} INTO t (SELECT ... FROM t ...);
+</programlisting>
+
+    <para>
+      Exception: The preceding prohibition does not apply if you are
+      using a subquery for the modified table in the
+      <literal>FROM</literal> clause. Example:
+    </para>
+
+<programlisting>
+UPDATE t ... WHERE col = (SELECT (SELECT ... FROM t...) AS _t ...);
+</programlisting>
+
+    <para>
+      Here the prohibition does not apply because a subquery in the
+      <literal>FROM</literal> clause is materialized as a temporary
+      table, so the relevant rows in <literal>t</literal> have already
+      been selected by the time the update to <literal>t</literal> takes
+      place.
+    </para>
+
+    <para>
       Row comparison operations are only partially supported:
     </para>
 
@@ -423,10 +446,10 @@
     <para>
       The reason for supporting row comparisons for
       <literal>IN</literal> but not for the others is that
-      <literal>IN</literal> was implemented by rewriting it as a
-      sequence of <literal>=</literal> comparisons and
-      <literal>AND</literal> operations. This approach cannot be used
-      for <literal>ALL</literal>, <literal>ANY</literal>, or
+      <literal>IN</literal> is implemented by rewriting it as a sequence
+      of <literal>=</literal> comparisons and <literal>AND</literal>
+      operations. This approach cannot be used for
+      <literal>ALL</literal>, <literal>ANY</literal>, or
       <literal>SOME</literal>.
     </para>
 
@@ -442,7 +465,7 @@
 
     <para>
       Subquery optimization for <literal>IN</literal> is not as
-      effective as for <literal>=</literal>.
+      effective as for the <literal>=</literal> operator.
     </para>
 
     <para>
@@ -460,36 +483,6 @@
     </para>
 
     <para>
-      In general, you cannot modify a table and select from the same
-      table in a subquery. For example, this limitation applies to
-      statements of the following forms:
-    </para>
-
-<programlisting>
-DELETE FROM t WHERE ... (SELECT ... FROM t ...);
-UPDATE t ... WHERE col = (SELECT ... FROM t ...);
-{INSERT|REPLACE} INTO t (SELECT ... FROM t ...);
-</programlisting>
-
-    <para>
-      Exception: The preceding prohibition does not apply if you are
-      using a subquery for the modified table in the
-      <literal>FROM</literal> clause. Example:
-    </para>
-
-<programlisting>
-UPDATE t ... WHERE col = (SELECT (SELECT ... FROM t...) AS _t ...);
-</programlisting>
-
-    <para>
-      Here the prohibition does not apply because a subquery in the
-      <literal>FROM</literal> clause is materialized as a temporary
-      table, so the relevant rows in <literal>t</literal> have already
-      been selected by the time the update to <literal>t</literal> takes
-      place.
-    </para>
-
-    <para>
       The optimizer is more mature for joins than for subqueries, so in
       many cases a statement that uses a subquery can be executed more
       efficiently if you rewrite it as a join.
@@ -520,12 +513,12 @@
     </para>
 
     <para>
-      Possible future optimization: MySQL doesn't rewrite the join order
-      for subquery evaluation. In some cases, a subquery could be
+      Possible future optimization: MySQL does not rewrite the join
+      order for subquery evaluation. In some cases, a subquery could be
       executed more efficiently if MySQL rewrote it as a join. This
       would give the optimizer a chance to choose between more execution
-      plans. For example, it can decide whether to read one table or the
-      other first.
+      plans. For example, it could decide whether to read one table or
+      the other first.
     </para>
 
     <para>
@@ -566,7 +559,7 @@
       Possible future optimization: A correlated subquery is evaluated
       for each row of the outer query. A better approach is that if the
       outer row values do not change from the previous row, do not
-      evaluate the subquery again. Instead use its previous result.
+      evaluate the subquery again. Instead, use its previous result.
     </para>
 
     <para>
@@ -601,7 +594,7 @@
       This type of rewriting would provide two benefits:
     </para>
 
-    <orderedlist>
+    <itemizedlist>
 
       <listitem>
         <para>
@@ -620,7 +613,7 @@
         </para>
       </listitem>
 
-    </orderedlist>
+    </itemizedlist>
 
     <para>
       Possible future optimization: For <literal>IN</literal>,
@@ -719,12 +712,11 @@
       If the view is evaluated using a temporary table, you
       <emphasis>can</emphasis> select from the table in the view
       subquery and still modify that table in the outer query. In this
-      case the view will be materialized and thus you aren't really
+      case the view will be materialized and thus you are not really
       selecting from the table in a subquery and modifying it <quote>at
       the same time.</quote> (This is another reason you might wish to
       force MySQL to use the temptable algorithm by specifying
-      <literal>ALGORITHM = TEMPTABLE</literal> keyword in the view
-      definition.)
+      <literal>ALGORITHM = TEMPTABLE</literal> in the view definition.)
     </para>
 
     <para>
@@ -792,9 +784,10 @@
 </programlisting>
 
         <para>
-          When the procedure p() is called, the SELECT returns 1 each
-          time through the loop, even though the view definition is
-          changed within the loop.
+          When the procedure <literal>p()</literal> is called, the
+          <literal>SELECT</literal> returns 1 each time through the
+          loop, even though the view definition is changed within the
+          loop.
         </para>
       </listitem>
 
@@ -856,17 +849,16 @@
     </para>
 
     <para>
-      The MySQL XA implementation is for <literal>external
-      XA,</literal>, where a MySQL server acts as a Resource Manager and
-      client programs act as Transaction Managers. <quote>Internal
-      XA</quote> is not implemented. This would allow individual storage
-      engines within a MySQL server to act as RMs, and the server itself
-      to act as a TM. Internal XA is required for handling XA
-      transactions that involve more than one storage engine. The
-      implementation of internal XA is incomplete because it requires
-      that a storage engine support two-phase commit at the table
-      handler level, and currently this is true only for
-      <literal>InnoDB</literal>.
+      The MySQL XA implementation is for <quote>external XA,</quote>
+      where a MySQL server acts as a Resource Manager and client
+      programs act as Transaction Managers. <quote>Internal XA</quote>
+      is not implemented. This would allow individual storage engines
+      within a MySQL server to act as RMs, and the server itself to act
+      as a TM. Internal XA is required for handling XA transactions that
+      involve more than one storage engine. The implementation of
+      internal XA is incomplete because it requires that a storage
+      engine support two-phase commit at the table handler level, and
+      currently this is true only for <literal>InnoDB</literal>.
     </para>
 
     <para>
@@ -875,7 +867,7 @@
     </para>
 
     <para>
-      For <literal>XA END</literal> the <literal>SUSPEND [FOR
+      For <literal>XA END</literal>, the <literal>SUSPEND [FOR
       MIGRATE]</literal> clause is not supported.
     </para>
 

Modified: trunk/refman-5.1/restrictions.xml
===================================================================
--- trunk/refman-5.1/restrictions.xml	2006-01-30 15:36:40 UTC (rev 1126)
+++ trunk/refman-5.1/restrictions.xml	2006-01-30 15:37:06 UTC (rev 1127)
@@ -54,18 +54,8 @@
     </para>
 
     <para>
-      <emphasis role="bold">Note</emphasis>: If an SQL statement, such
-      as a <literal>SELECT ... INTO</literal> statement, contains a
-      reference to a column and a declared local variable with the same
-      name, MySQL interprets the reference as the name of a variable.
-      This is non-standard behavior; the order of precedence is usually
-      column names, then SQL variables and parameters. See
-      <xref linkend="select-into-statement"/>.
-    </para>
-
-    <para>
       Stored routines cannot contain arbitrary SQL statements. The
-      following statements are disallowed within stored routines:
+      following statements are disallowed:
     </para>
 
     <itemizedlist>
@@ -115,19 +105,18 @@
         <para>
           Statements that return a result set. This includes
           <literal>SELECT</literal> statements that do not have an
-          <literal>INTO</literal> clause and <literal>SHOW</literal>
-          statements. A function can process a result set either with
-          <literal>SELECT ... INTO</literal> or by using a cursor and
-          <literal>FETCH</literal> statements.
+          <literal>INTO <replaceable>var_list</replaceable></literal>
+          clause and <literal>SHOW</literal> statements. A function can
+          process a result set either with <literal>SELECT ... INTO
+          <replaceable>var_list</replaceable></literal> or by using a
+          cursor and <literal>FETCH</literal> statements. See
+          <xref linkend="select-into-statement"/>.
         </para>
       </listitem>
 
       <listitem>
         <para>
-          <literal>FLUSH</literal> statements. Note that while you may
-          use <literal>FLUSH</literal> in a stored procedure, such a
-          stored procedure cannot be called from a stored function or
-          trigger.
+          <literal>FLUSH</literal> statements.
         </para>
       </listitem>
 
@@ -144,7 +133,10 @@
       Note that although some restrictions normally apply to stored
       functions and triggers but not to stored procedures, those
       restrictions do apply to stored procedures if they are invoked
-      from within a stored function or trigger.
+      from within a stored function or trigger. For example, although
+      you can use <literal>FLUSH</literal> in a stored procedure, such a
+      stored procedure cannot be called from a stored function or
+      trigger.
     </para>
 
     <para>
@@ -196,7 +188,7 @@
 
     <para>
       The behavior that table columns do not take precedence over
-      variable s is non-standard.
+      variables is non-standard.
     </para>
 
     <para>
@@ -224,6 +216,14 @@
     </para>
 
     <para>
+      <literal>UNDO</literal> handlers are not supported.
+    </para>
+
+    <para>
+      <literal>FOR</literal> loops are not supported.
+    </para>
+
+    <para>
       To prevent problems of interaction between server threads, when a
       client issues a statement, the server uses a snapshot of routines
       and triggers available for execution of the statement. That is,
@@ -234,14 +234,6 @@
       performed by other threads.
     </para>
 
-    <para>
-      <literal>UNDO</literal> handlers are not supported.
-    </para>
-
-    <para>
-      <literal>FOR</literal> loops are not supported.
-    </para>
-
   </section>
 
   <section id="cursor-restrictions">
@@ -269,12 +261,13 @@
     </para>
 
     <para>
-      A server-side cursor is materialized into a temporary table.
-      Initially, this is a <literal>MEMORY</literal> table, but is
-      converted to a <literal>MyISAM</literal> table if its size reaches
-      the value of the <literal>max_heap_table_size</literal> system
-      variable. One limitation of the implementation is that for a large
-      result set, retrieving its rows through a cursor might be slow.
+      In MySQL, a server-side cursor is materialized into a temporary
+      table. Initially, this is a <literal>MEMORY</literal> table, but
+      is converted to a <literal>MyISAM</literal> table if its size
+      reaches the value of the <literal>max_heap_table_size</literal>
+      system variable. One limitation of the implementation is that for
+      a large result set, retrieving its rows through a cursor might be
+      slow.
     </para>
 
     <para>
@@ -350,6 +343,36 @@
     </para>
 
     <para>
+      In general, you cannot modify a table and select from the same
+      table in a subquery. For example, this limitation applies to
+      statements of the following forms:
+    </para>
+
+<programlisting>
+DELETE FROM t WHERE ... (SELECT ... FROM t ...);
+UPDATE t ... WHERE col = (SELECT ... FROM t ...);
+{INSERT|REPLACE} INTO t (SELECT ... FROM t ...);
+</programlisting>
+
+    <para>
+      Exception: The preceding prohibition does not apply if you are
+      using a subquery for the modified table in the
+      <literal>FROM</literal> clause. Example:
+    </para>
+
+<programlisting>
+UPDATE t ... WHERE col = (SELECT (SELECT ... FROM t...) AS _t ...);
+</programlisting>
+
+    <para>
+      Here the prohibition does not apply because a subquery in the
+      <literal>FROM</literal> clause is materialized as a temporary
+      table, so the relevant rows in <literal>t</literal> have already
+      been selected by the time the update to <literal>t</literal> takes
+      place.
+    </para>
+
+    <para>
       Row comparison operations are only partially supported:
     </para>
 
@@ -399,10 +422,10 @@
     <para>
       The reason for supporting row comparisons for
       <literal>IN</literal> but not for the others is that
-      <literal>IN</literal> was implemented by rewriting it as a
-      sequence of <literal>=</literal> comparisons and
-      <literal>AND</literal> operations. This approach cannot be used
-      for <literal>ALL</literal>, <literal>ANY</literal>, or
+      <literal>IN</literal> is implemented by rewriting it as a sequence
+      of <literal>=</literal> comparisons and <literal>AND</literal>
+      operations. This approach cannot be used for
+      <literal>ALL</literal>, <literal>ANY</literal>, or
       <literal>SOME</literal>.
     </para>
 
@@ -418,7 +441,7 @@
 
     <para>
       Subquery optimization for <literal>IN</literal> is not as
-      effective as for <literal>=</literal>.
+      effective as for the <literal>=</literal> operator.
     </para>
 
     <para>
@@ -436,36 +459,6 @@
     </para>
 
     <para>
-      In general, you cannot modify a table and select from the same
-      table in a subquery. For example, this limitation applies to
-      statements of the following forms:
-    </para>
-
-<programlisting>
-DELETE FROM t WHERE ... (SELECT ... FROM t ...);
-UPDATE t ... WHERE col = (SELECT ... FROM t ...);
-{INSERT|REPLACE} INTO t (SELECT ... FROM t ...);
-</programlisting>
-
-    <para>
-      Exception: The preceding prohibition does not apply if you are
-      using a subquery for the modified table in the
-      <literal>FROM</literal> clause. Example:
-    </para>
-
-<programlisting>
-UPDATE t ... WHERE col = (SELECT (SELECT ... FROM t...) AS _t ...);
-</programlisting>
-
-    <para>
-      Here the prohibition does not apply because a subquery in the
-      <literal>FROM</literal> clause is materialized as a temporary
-      table, so the relevant rows in <literal>t</literal> have already
-      been selected by the time the update to <literal>t</literal> takes
-      place.
-    </para>
-
-    <para>
       The optimizer is more mature for joins than for subqueries, so in
       many cases a statement that uses a subquery can be executed more
       efficiently if you rewrite it as a join.
@@ -496,12 +489,12 @@
     </para>
 
     <para>
-      Possible future optimization: MySQL doesn't rewrite the join order
-      for subquery evaluation. In some cases, a subquery could be
+      Possible future optimization: MySQL does not rewrite the join
+      order for subquery evaluation. In some cases, a subquery could be
       executed more efficiently if MySQL rewrote it as a join. This
       would give the optimizer a chance to choose between more execution
-      plans. For example, it can decide whether to read one table or the
-      other first.
+      plans. For example, it could decide whether to read one table or
+      the other first.
     </para>
 
     <para>
@@ -542,7 +535,7 @@
       Possible future optimization: A correlated subquery is evaluated
       for each row of the outer query. A better approach is that if the
       outer row values do not change from the previous row, do not
-      evaluate the subquery again. Instead use its previous result.
+      evaluate the subquery again. Instead, use its previous result.
     </para>
 
     <para>
@@ -577,7 +570,7 @@
       This type of rewriting would provide two benefits:
     </para>
 
-    <orderedlist>
+    <itemizedlist>
 
       <listitem>
         <para>
@@ -596,7 +589,7 @@
         </para>
       </listitem>
 
-    </orderedlist>
+    </itemizedlist>
 
     <para>
       Possible future optimization: For <literal>IN</literal>,
@@ -695,12 +688,11 @@
       If the view is evaluated using a temporary table, you
       <emphasis>can</emphasis> select from the table in the view
       subquery and still modify that table in the outer query. In this
-      case the view will be materialized and thus you aren't really
+      case the view will be materialized and thus you are not really
       selecting from the table in a subquery and modifying it <quote>at
       the same time.</quote> (This is another reason you might wish to
       force MySQL to use the temptable algorithm by specifying
-      <literal>ALGORITHM = TEMPTABLE</literal> keyword in the view
-      definition.)
+      <literal>ALGORITHM = TEMPTABLE</literal> in the view definition.)
     </para>
 
     <para>
@@ -768,9 +760,10 @@
 </programlisting>
 
         <para>
-          When the procedure p() is called, the SELECT returns 1 each
-          time through the loop, even though the view definition is
-          changed within the loop.
+          When the procedure <literal>p()</literal> is called, the
+          <literal>SELECT</literal> returns 1 each time through the
+          loop, even though the view definition is changed within the
+          loop.
         </para>
       </listitem>
 
@@ -832,17 +825,16 @@
     </para>
 
     <para>
-      The MySQL XA implementation is for <literal>external
-      XA,</literal>, where a MySQL server acts as a Resource Manager and
-      client programs act as Transaction Managers. <quote>Internal
-      XA</quote> is not implemented. This would allow individual storage
-      engines within a MySQL server to act as RMs, and the server itself
-      to act as a TM. Internal XA is required for handling XA
-      transactions that involve more than one storage engine. The
-      implementation of internal XA is incomplete because it requires
-      that a storage engine support two-phase commit at the table
-      handler level, and currently this is true only for
-      <literal>InnoDB</literal>.
+      The MySQL XA implementation is for <quote>external XA,</quote>
+      where a MySQL server acts as a Resource Manager and client
+      programs act as Transaction Managers. <quote>Internal XA</quote>
+      is not implemented. This would allow individual storage engines
+      within a MySQL server to act as RMs, and the server itself to act
+      as a TM. Internal XA is required for handling XA transactions that
+      involve more than one storage engine. The implementation of
+      internal XA is incomplete because it requires that a storage
+      engine support two-phase commit at the table handler level, and
+      currently this is true only for <literal>InnoDB</literal>.
     </para>
 
     <para>
@@ -851,7 +843,7 @@
     </para>
 
     <para>
-      For <literal>XA END</literal> the <literal>SUSPEND [FOR
+      For <literal>XA END</literal>, the <literal>SUSPEND [FOR
       MIGRATE]</literal> clause is not supported.
     </para>
 

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