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.1 | paul | 30 Jan |
