svn commit - mysqldoc@docsrva: r10934 - in trunk: . it/refman-5.1 pt/refman-5.1 refman-5.0 refman-5.1 refman-6.0

[paul]

Author: paul
Date: 2008-06-11 22:02:34 +0200 (Wed, 11 Jun 2008)
New Revision: 10934

Log:
 r31653@arctic:  paul | 2008-06-11 15:01:11 -0500
 Correct some terminology on view restrictions ("defintion", not "contents"),
 improve an example.


Modified:
   trunk/it/refman-5.1/restrictions.xml
   trunk/pt/refman-5.1/restrictions.xml
   trunk/refman-5.0/restrictions.xml
   trunk/refman-5.1/restrictions.xml
   trunk/refman-6.0/restrictions.xml

Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:35828
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:31927
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:31613
   + 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:35828
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:31927
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:31653


Modified: trunk/it/refman-5.1/restrictions.xml
===================================================================
--- trunk/it/refman-5.1/restrictions.xml	2008-06-11 15:13:41 UTC (rev 10933)
+++ trunk/it/refman-5.1/restrictions.xml	2008-06-11 20:02:34 UTC (rev 10934)
Changed blocks: 2, Lines Added: 16, Lines Deleted: 15; 2732 bytes

@@ -934,33 +934,33 @@
       <listitem>
         <para>
           If a statement prepared by <literal>PREPARE</literal> refers
-          to a view, the view contents seen each time the statement is
-          executed later will be the contents of the view at the time it
-          was prepared. This is true even if the view definition is
+          to a view, the view definition seen each time the statement is
+          executed later will be the definition of the view at the time
+          it was prepared. This is true even if the view definition is
           changed after the statement is prepared and before it is
           executed. Example:
         </para>
 
 <programlisting>
-CREATE VIEW v AS SELECT 1;
+CREATE VIEW v AS SELECT RAND();
 PREPARE s FROM 'SELECT * FROM v';
-ALTER VIEW v AS SELECT 2;
+ALTER VIEW v AS SELECT NOW();
 EXECUTE s;
 </programlisting>
 
         <para>
           The result returned by the <literal>EXECUTE</literal>
-          statement is 1, not 2.
+          statement is a random number, not the current date and time.
         </para>
       </listitem>
 
       <listitem>
         <para>
           If a statement in a stored routine refers to a view, the view
-          contents seen by the statement are its contents the first time
-          that statement is executed. For example, this means that if
-          the statement is executed in a loop, further iterations of the
-          statement see the same view contents, even if the view
+          definition seen by the statement are its definition the first
+          time that statement is executed. For example, this means that
+          if the statement is executed in a loop, further iterations of
+          the statement see the same view definition, even if the
           definition is changed later in the loop. Example:
         </para>
 

@@ -987,15 +987,16 @@
           loop, even though the view definition is changed within the
           loop.
         </para>
+
+        <para>
+          As of MySQL 5.1.21, <literal>ALTER VIEW</literal> is
+          prohibited within stored routines, so this restriction does
+          not apply.
+        </para>
       </listitem>
 
     </itemizedlist>
 
-    <remark>
-      For SQL prepared statements, this restriction could be lifted when
-      the table definition cache is implemented.
-    </remark>
-
     <para>
       With regard to view updatability, the overall goal for views is
       that if any view is theoretically updatable, it should be


Modified: trunk/pt/refman-5.1/restrictions.xml
===================================================================
--- trunk/pt/refman-5.1/restrictions.xml	2008-06-11 15:13:41 UTC (rev 10933)
+++ trunk/pt/refman-5.1/restrictions.xml	2008-06-11 20:02:34 UTC (rev 10934)
Changed blocks: 2, Lines Added: 16, Lines Deleted: 15; 2732 bytes

@@ -934,33 +934,33 @@
       <listitem>
         <para>
           If a statement prepared by <literal>PREPARE</literal> refers
-          to a view, the view contents seen each time the statement is
-          executed later will be the contents of the view at the time it
-          was prepared. This is true even if the view definition is
+          to a view, the view definition seen each time the statement is
+          executed later will be the definition of the view at the time
+          it was prepared. This is true even if the view definition is
           changed after the statement is prepared and before it is
           executed. Example:
         </para>
 
 <programlisting>
-CREATE VIEW v AS SELECT 1;
+CREATE VIEW v AS SELECT RAND();
 PREPARE s FROM 'SELECT * FROM v';
-ALTER VIEW v AS SELECT 2;
+ALTER VIEW v AS SELECT NOW();
 EXECUTE s;
 </programlisting>
 
         <para>
           The result returned by the <literal>EXECUTE</literal>
-          statement is 1, not 2.
+          statement is a random number, not the current date and time.
         </para>
       </listitem>
 
       <listitem>
         <para>
           If a statement in a stored routine refers to a view, the view
-          contents seen by the statement are its contents the first time
-          that statement is executed. For example, this means that if
-          the statement is executed in a loop, further iterations of the
-          statement see the same view contents, even if the view
+          definition seen by the statement are its definition the first
+          time that statement is executed. For example, this means that
+          if the statement is executed in a loop, further iterations of
+          the statement see the same view definition, even if the
           definition is changed later in the loop. Example:
         </para>
 

@@ -987,15 +987,16 @@
           loop, even though the view definition is changed within the
           loop.
         </para>
+
+        <para>
+          As of MySQL 5.1.21, <literal>ALTER VIEW</literal> is
+          prohibited within stored routines, so this restriction does
+          not apply.
+        </para>
       </listitem>
 
     </itemizedlist>
 
-    <remark>
-      For SQL prepared statements, this restriction could be lifted when
-      the table definition cache is implemented.
-    </remark>
-
     <para>
       With regard to view updatability, the overall goal for views is
       that if any view is theoretically updatable, it should be


Modified: trunk/refman-5.0/restrictions.xml
===================================================================
--- trunk/refman-5.0/restrictions.xml	2008-06-11 15:13:41 UTC (rev 10933)
+++ trunk/refman-5.0/restrictions.xml	2008-06-11 20:02:34 UTC (rev 10934)
Changed blocks: 2, Lines Added: 16, Lines Deleted: 15; 2723 bytes

@@ -879,33 +879,33 @@
       <listitem>
         <para>
           If a statement prepared by <literal>PREPARE</literal> refers
-          to a view, the view contents seen each time the statement is
-          executed later will be the contents of the view at the time it
-          was prepared. This is true even if the view definition is
+          to a view, the view definition seen each time the statement is
+          executed later will be the definition of the view at the time
+          it was prepared. This is true even if the view definition is
           changed after the statement is prepared and before it is
           executed. Example:
         </para>
 
 <programlisting>
-CREATE VIEW v AS SELECT 1;
+CREATE VIEW v AS SELECT RAND();
 PREPARE s FROM 'SELECT * FROM v';
-ALTER VIEW v AS SELECT 2;
+ALTER VIEW v AS SELECT NOW();
 EXECUTE s;
 </programlisting>
 
         <para>
           The result returned by the <literal>EXECUTE</literal>
-          statement is 1, not 2.
+          statement is a random number, not the current date and time.
         </para>
       </listitem>
 
       <listitem>
         <para>
           If a statement in a stored routine refers to a view, the view
-          contents seen by the statement are its contents the first time
-          that statement is executed. For example, this means that if
-          the statement is executed in a loop, further iterations of the
-          statement see the same view contents, even if the view
+          definition seen by the statement are its definition the first
+          time that statement is executed. For example, this means that
+          if the statement is executed in a loop, further iterations of
+          the statement see the same view definition, even if the
           definition is changed later in the loop. Example:
         </para>
 

@@ -932,15 +932,16 @@
           loop, even though the view definition is changed within the
           loop.
         </para>
+
+        <para>
+          As of MySQL 5.0.46, <literal>ALTER VIEW</literal> is
+          prohibited within stored routines, so this restriction does
+          not apply.
+        </para>
       </listitem>
 
     </itemizedlist>
 
-    <remark>
-      For SQL prepared statements, this restriction could be lifted when
-      the table definition cache is implemented.
-    </remark>
-
     <para>
       With regard to view updatability, the overall goal for views is
       that if any view is theoretically updatable, it should be


Modified: trunk/refman-5.1/restrictions.xml
===================================================================
--- trunk/refman-5.1/restrictions.xml	2008-06-11 15:13:41 UTC (rev 10933)
+++ trunk/refman-5.1/restrictions.xml	2008-06-11 20:02:34 UTC (rev 10934)
Changed blocks: 2, Lines Added: 16, Lines Deleted: 15; 2723 bytes

@@ -934,33 +934,33 @@
       <listitem>
         <para>
           If a statement prepared by <literal>PREPARE</literal> refers
-          to a view, the view contents seen each time the statement is
-          executed later will be the contents of the view at the time it
-          was prepared. This is true even if the view definition is
+          to a view, the view definition seen each time the statement is
+          executed later will be the definition of the view at the time
+          it was prepared. This is true even if the view definition is
           changed after the statement is prepared and before it is
           executed. Example:
         </para>
 
 <programlisting>
-CREATE VIEW v AS SELECT 1;
+CREATE VIEW v AS SELECT RAND();
 PREPARE s FROM 'SELECT * FROM v';
-ALTER VIEW v AS SELECT 2;
+ALTER VIEW v AS SELECT NOW();
 EXECUTE s;
 </programlisting>
 
         <para>
           The result returned by the <literal>EXECUTE</literal>
-          statement is 1, not 2.
+          statement is a random number, not the current date and time.
         </para>
       </listitem>
 
       <listitem>
         <para>
           If a statement in a stored routine refers to a view, the view
-          contents seen by the statement are its contents the first time
-          that statement is executed. For example, this means that if
-          the statement is executed in a loop, further iterations of the
-          statement see the same view contents, even if the view
+          definition seen by the statement are its definition the first
+          time that statement is executed. For example, this means that
+          if the statement is executed in a loop, further iterations of
+          the statement see the same view definition, even if the
           definition is changed later in the loop. Example:
         </para>
 

@@ -987,15 +987,16 @@
           loop, even though the view definition is changed within the
           loop.
         </para>
+
+        <para>
+          As of MySQL 5.1.21, <literal>ALTER VIEW</literal> is
+          prohibited within stored routines, so this restriction does
+          not apply.
+        </para>
       </listitem>
 
     </itemizedlist>
 
-    <remark>
-      For SQL prepared statements, this restriction could be lifted when
-      the table definition cache is implemented.
-    </remark>
-
     <para>
       With regard to view updatability, the overall goal for views is
       that if any view is theoretically updatable, it should be


Modified: trunk/refman-6.0/restrictions.xml
===================================================================
--- trunk/refman-6.0/restrictions.xml	2008-06-11 15:13:41 UTC (rev 10933)
+++ trunk/refman-6.0/restrictions.xml	2008-06-11 20:02:34 UTC (rev 10934)
Changed blocks: 1, Lines Added: 6, Lines Deleted: 46; 2648 bytes

@@ -911,68 +911,28 @@
       <listitem>
         <para>
           If a statement prepared by <literal>PREPARE</literal> refers
-          to a view, the view contents seen each time the statement is
-          executed later will be the contents of the view at the time it
-          was prepared. This is true even if the view definition is
+          to a view, the view definition seen each time the statement is
+          executed later will be the definition of the view at the time
+          it was prepared. This is true even if the view definition is
           changed after the statement is prepared and before it is
           executed. Example:
         </para>
 
 <programlisting>
-CREATE VIEW v AS SELECT 1;
+CREATE VIEW v AS SELECT RAND();
 PREPARE s FROM 'SELECT * FROM v';
-ALTER VIEW v AS SELECT 2;
+ALTER VIEW v AS SELECT NOW();
 EXECUTE s;
 </programlisting>
 
         <para>
           The result returned by the <literal>EXECUTE</literal>
-          statement is 1, not 2.
+          statement is a random number, not the current date and time.
         </para>
       </listitem>
 
-      <listitem>
-        <para>
-          If a statement in a stored routine refers to a view, the view
-          contents seen by the statement are its contents the first time
-          that statement is executed. For example, this means that if
-          the statement is executed in a loop, further iterations of the
-          statement see the same view contents, even if the view
-          definition is changed later in the loop. Example:
-        </para>
-
-<programlisting>
-CREATE VIEW v AS SELECT 1;
-delimiter //
-CREATE PROCEDURE p ()
-BEGIN
-  DECLARE i INT DEFAULT 0;
-  WHILE i &lt; 5 DO
-    SELECT * FROM v;
-    SET i = i + 1;
-    ALTER VIEW v AS SELECT 2;
-  END WHILE;
-END;
-//
-delimiter ;
-CALL p();
-</programlisting>
-
-        <para>
-          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>
-
     </itemizedlist>
 
-    <remark>
-      For SQL prepared statements, this restriction could be lifted when
-      the table definition cache is implemented.
-    </remark>
-
     <para>
       With regard to view updatability, the overall goal for views is
       that if any view is theoretically updatable, it should be