svn commit - mysqldoc@docsrva: r2702 - in trunk: . refman-5.0 refman-5.1

[paul]

Author: paul
Date: 2006-07-11 18:59:40 +0200 (Tue, 11 Jul 2006)
New Revision: 2702

Log:
 r11289@polar:  paul | 2006-07-11 11:40:00 -0500
 Avoid implying that we have "materialized" views in the usual sense.


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

Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:11257
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:12084
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:8441
   + 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:11289
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:12084
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:8441


Modified: trunk/refman-5.0/restrictions.xml
===================================================================
--- trunk/refman-5.0/restrictions.xml	2006-07-11 15:37:28 UTC (rev 2701)
+++ trunk/refman-5.0/restrictions.xml	2006-07-11 16:59:40 UTC (rev 2702)
Changed blocks: 2, Lines Added: 8, Lines Deleted: 8; 1802 bytes

@@ -464,10 +464,10 @@
 </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
+          Here the prohibition does not apply because the result from a
+          subquery in the <literal>FROM</literal> clause is stored 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>
       </listitem>

@@ -798,10 +798,10 @@
       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 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
+      case the view will be stored in a temporary table 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> in the view definition.)
     </para>
 


Modified: trunk/refman-5.1/restrictions.xml
===================================================================
--- trunk/refman-5.1/restrictions.xml	2006-07-11 15:37:28 UTC (rev 2701)
+++ trunk/refman-5.1/restrictions.xml	2006-07-11 16:59:40 UTC (rev 2702)
Changed blocks: 2, Lines Added: 8, Lines Deleted: 8; 1802 bytes

@@ -446,10 +446,10 @@
 </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
+          Here the prohibition does not apply because the result from a
+          subquery in the <literal>FROM</literal> clause is stored 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>
       </listitem>

@@ -780,10 +780,10 @@
       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 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
+      case the view will be stored in a temporary table 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> in the view definition.)
     </para>