From: Date: June 11 2008 10:02pm Subject: svn commit - mysqldoc@docsrva: r10934 - in trunk: . it/refman-5.1 pt/refman-5.1 refman-5.0 refman-5.1 refman-6.0 List-Archive: http://lists.mysql.com/commits/47757 Message-Id: <200806112002.m5BK2Y3p027317@docsrva.mysql.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 @@ If a statement prepared by PREPARE 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: -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; The result returned by the EXECUTE - statement is 1, not 2. + statement is a random number, not the current date and time. 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: @@ -987,15 +987,16 @@ loop, even though the view definition is changed within the loop. + + + As of MySQL 5.1.21, ALTER VIEW is + prohibited within stored routines, so this restriction does + not apply. + - - For SQL prepared statements, this restriction could be lifted when - the table definition cache is implemented. - - 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 @@ If a statement prepared by PREPARE 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: -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; The result returned by the EXECUTE - statement is 1, not 2. + statement is a random number, not the current date and time. 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: @@ -987,15 +987,16 @@ loop, even though the view definition is changed within the loop. + + + As of MySQL 5.1.21, ALTER VIEW is + prohibited within stored routines, so this restriction does + not apply. + - - For SQL prepared statements, this restriction could be lifted when - the table definition cache is implemented. - - 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 @@ If a statement prepared by PREPARE 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: -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; The result returned by the EXECUTE - statement is 1, not 2. + statement is a random number, not the current date and time. 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: @@ -932,15 +932,16 @@ loop, even though the view definition is changed within the loop. + + + As of MySQL 5.0.46, ALTER VIEW is + prohibited within stored routines, so this restriction does + not apply. + - - For SQL prepared statements, this restriction could be lifted when - the table definition cache is implemented. - - 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 @@ If a statement prepared by PREPARE 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: -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; The result returned by the EXECUTE - statement is 1, not 2. + statement is a random number, not the current date and time. 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: @@ -987,15 +987,16 @@ loop, even though the view definition is changed within the loop. + + + As of MySQL 5.1.21, ALTER VIEW is + prohibited within stored routines, so this restriction does + not apply. + - - For SQL prepared statements, this restriction could be lifted when - the table definition cache is implemented. - - 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 @@ If a statement prepared by PREPARE 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: -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; The result returned by the EXECUTE - statement is 1, not 2. + statement is a random number, not the current date and time. - - - 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: - - - -CREATE VIEW v AS SELECT 1; -delimiter // -CREATE PROCEDURE p () -BEGIN - DECLARE i INT DEFAULT 0; - WHILE i < 5 DO - SELECT * FROM v; - SET i = i + 1; - ALTER VIEW v AS SELECT 2; - END WHILE; -END; -// -delimiter ; -CALL p(); - - - - 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. - - - - - For SQL prepared statements, this restriction could be lifted when - the table definition cache is implemented. - - With regard to view updatability, the overall goal for views is that if any view is theoretically updatable, it should be