| List: | Commits | « Previous MessageNext Message » | |
| From: | paul | Date: | March 2 2007 8:18pm |
| Subject: | svn commit - mysqldoc@docsrva: r5151 - in trunk: . internals refman-4.1 refman-5.0 refman-5.1 | ||
| View as plain text | |||
Author: paul Date: 2007-03-02 20:18:17 +0100 (Fri, 02 Mar 2007) New Revision: 5151 Log: r20850@polar: paul | 2007-03-02 13:00:19 -0600 Minor revisions to subquery-related material. Modified: trunk/internals/transformations.xml trunk/refman-4.1/sql-syntax.xml trunk/refman-5.0/sql-syntax.xml trunk/refman-5.1/sql-syntax.xml Property changes on: trunk ___________________________________________________________________ Name: svk:merge - 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:20810 7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:16997 b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218 bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:14593 + 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:20850 7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:16997 b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218 bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:14593 Modified: trunk/internals/transformations.xml =================================================================== --- trunk/internals/transformations.xml 2007-03-02 16:17:26 UTC (rev 5150) +++ trunk/internals/transformations.xml 2007-03-02 19:18:17 UTC (rev 5151) Changed blocks: 14, Lines Added: 37, Lines Deleted: 36; 7965 bytes @@ -12,11 +12,11 @@ <title>How MySQL Transforms Subqueries</title> <para> - <literal>Item_subselect</literal> virtual method + The <literal>Item_subselect</literal> virtual method <literal>select_transformer</literal> is used to rewrite subqueries. It is called from <literal>Item_subselect::init</literal> (which is - called just after call to <literal>fix_fields()</literal> method for - all items in <literal>JOIN::prepare</literal>). + called just after the call to the <literal>fix_fields()</literal> + method for all items in <literal>JOIN::prepare</literal>). </para> <section id="transformation-in"> @@ -25,8 +25,8 @@ <para> <literal>Item_in_subselect::select_transformer</literal> is - divided into two parts, for the scalar left part and the row left - part. + divided into two parts, one for the scalar left part and one for + the row left part. </para> <section id="transformation-scalar-in"> @@ -34,22 +34,21 @@ <title>Scalar <literal>IN</literal> Subquery</title> <para> - To rewrite a scalar <literal>IN</literal> subquery, the method - used is - <literal>Item_in_subselect::single_value_transformer</literal>. - Scalar <literal>IN</literal> subquery will be replaced with - <literal>Item_in_optimizer</literal>. + To rewrite a scalar <literal>IN</literal> subquery, the + <literal>Item_in_subselect::single_value_transformer</literal> + method is used. The scalar <literal>IN</literal> subquery will + be replaced with an <literal>Item_in_optimizer</literal> item. </para> <para> - <literal>Item_in_optimizer</literal> item is a special boolean - function. On a value request (one of <literal>val</literal>, - <literal>val_int</literal>, or <literal>val_str</literal> - methods) it evaluates left expression of <literal>IN</literal> - by storing its value in cache item (one of - <literal>Item_cache*</literal> items), then it tests the cache - to see whether it is <literal>NULL</literal>. If left expression - (cache) is <literal>NULL</literal>, then + An <literal>Item_in_optimizer</literal> item is a special + boolean function. On a value request (one of + <literal>val</literal>, <literal>val_int</literal>, or + <literal>val_str</literal> methods) it evaluates the left + expression of the <literal>IN</literal> by storing its value in + a cache item (one of <literal>Item_cache*</literal> items), then + it tests the cache to see whether it is <literal>NULL</literal>. + If left expression (cache) is <literal>NULL</literal>, then <literal>Item_in_optimizer</literal> returns <literal>NULL</literal>, else it evaluates <literal>Item_in_subselect</literal>. @@ -93,7 +92,7 @@ <literal>Item_null_helper</literal>). This reference informs <literal>Item_in_optimizer</literal> whether item (<literal>t2.a</literal>) is <literal>NULL</literal> by - setting the 'was_null' flag. + setting the <literal>was_null</literal> flag. </para> </listitem> @@ -119,7 +118,8 @@ <listitem> <para> - If FALSE, and 'was_null' is set, return null + If FALSE, and <literal>was_null</literal> is set, return + null </para> </listitem> @@ -135,8 +135,8 @@ </itemizedlist> <para> - <left_expression> IN (SELECT <item> ...) will be - represented as follows: + <literal><left_expression> IN (SELECT <item> + ...)</literal> will be represented as follows: </para> <programlisting> @@ -169,7 +169,7 @@ <para> <literal>Item_ref</literal> is used to point to <literal><left_expression cache></literal>, because at the - time of transformation we know only the address of variable + time of transformation we know only the address of the variable where the cache pointer will be stored. </para> @@ -192,10 +192,10 @@ NULL)</literal> and <literal>Item_is_not_null_test(item)</literal> will be added to the <literal>HAVING</literal> clause. - <literal>Item_is_not_null_test</literal> registers + <literal>Item_is_not_null_test</literal> registers a <literal>NULL</literal> value the way <literal>Item_ref_null_helper</literal> does it, and returns - FALSE if argument is <literal>NULL</literal>. With the above + FALSE if the argument is <literal>NULL</literal>. With the above trick, we will register <literal>NULL</literal> value of <literal>Item</literal> even for the case of index optimization of a <literal>WHERE</literal> clause (case 'a' in the following @@ -233,7 +233,7 @@ </programlisting> <para> - When subquery is marked as the top item of the + When a subquery is marked as the top item of the <literal>WHERE</literal> clause, it will become: </para> @@ -320,7 +320,7 @@ <para> If subquery contains a <literal>HAVING</literal> clause, <literal>SUM()</literal> function or <literal>GROUP BY</literal> - (example 1), then the item list will be unchanged and + (example 1), then the item list will be unchanged and an <literal>Item_ref_null_helper</literal> reference will be created on item list element. A condition will be added to the <literal>HAVING</literal>. @@ -328,8 +328,8 @@ <para> If the subquery does not contain <literal>HAVING</literal>, - <literal>SUM()</literal> function or <literal>GROUP BY</literal> - (example 2), then: + <literal>SUM()</literal> function, or <literal>GROUP + BY</literal> (example 2), then: </para> <itemizedlist> @@ -380,12 +380,12 @@ It works in almost the same way as the scalar analog, but works with <literal>Item_cache_row</literal> for caching left expression and uses references for elements of - <literal>Item_cache_row</literal>. To refer to item list it uses - <literal>Item_ref_null_helper(ref_array+i)</literal>. + <literal>Item_cache_row</literal>. To refer to the item list, it + uses <literal>Item_ref_null_helper(ref_array+i)</literal>. </para> <para> - Subquery with <literal>HAVING</literal>, + A subquery with <literal>HAVING</literal>, <literal>SUM()</literal> function, or <literal>GROUP BY</literal> will transformed in the following way: </para> @@ -510,7 +510,8 @@ <para> For queries with aggregate function and/or grouping, special <literal>Item_maxmin_subselect</literal> will be used. This - subquery will return maximum (minimum) value of result set. + subquery will return the maximum (minimum) value of the result + set. </para> </section> @@ -524,9 +525,9 @@ if it contains no <literal>FROM</literal> clause, and it is not part of <literal>UNION</literal>, and it is a scalar subquery. For now, there will be no conversion of subqueries with field or - reference on top of item list (on the one hand we can't change the - name of such items, but on the other hand we should assign to it - the name of the whole subquery which will be reduced); + reference on top of item list (on the one hand, we can't change + the name of such items, but on the other hand, we should assign to + it the name of the whole subquery which will be reduced). </para> <para> Modified: trunk/refman-4.1/sql-syntax.xml =================================================================== --- trunk/refman-4.1/sql-syntax.xml 2007-03-02 16:17:26 UTC (rev 5150) +++ trunk/refman-4.1/sql-syntax.xml 2007-03-02 19:18:17 UTC (rev 5151) Changed blocks: 4, Lines Added: 12, Lines Deleted: 10; 2439 bytes @@ -7959,9 +7959,9 @@ <listitem> <para> They are, in many people's opinion, more readable than - complex joins and/or unions. Indeed, it was the innovation - of subqueries that gave people the original idea of calling - the early SQL <quote>Structured Query Language.</quote> + complex joins or unions. Indeed, it was the innovation of + subqueries that gave people the original idea of calling the + early SQL <quote>Structured Query Language.</quote> </para> </listitem> @@ -8214,7 +8214,7 @@ <literal>FALSE</literal> if table <literal>t2</literal> contains <literal>(20,10)</literal>, or if table <literal>t2</literal> is empty. The expression is - <literal>UNKNOWN</literal> if table <literal>t2</literal> + <emphasis>unknown</emphasis> if table <literal>t2</literal> contains <literal>(NULL,NULL,NULL)</literal>. </para> @@ -8691,9 +8691,11 @@ <para> Subqueries in the <literal>FROM</literal> clause are executed even for the <literal>EXPLAIN</literal> statement (that is, - derived temporary tables are built). This occurs because upper - level queries need information about all tables during - optimization phase. + derived temporary tables are built). This occurs because + upper-level queries need information about all tables during + the optimization phase, and the table represented by a + subquery in the <literal>FROM</literal> clause is unavailable + unless the subquery is executed. </para> </section> @@ -8752,9 +8754,9 @@ <para> You may use a subquery that returns multiple columns, if - the purpose is comparison. See - <xref linkend="row-subqueries"/>. However, in other - contexts, the subquery must be a scalar operand. + the purpose is comparison. In other contexts, the subquery + must be a scalar operand. See + <xref linkend="row-subqueries"/>. </para> </listitem> Modified: trunk/refman-5.0/sql-syntax.xml =================================================================== --- trunk/refman-5.0/sql-syntax.xml 2007-03-02 16:17:26 UTC (rev 5150) +++ trunk/refman-5.0/sql-syntax.xml 2007-03-02 19:18:17 UTC (rev 5151) Changed blocks: 5, Lines Added: 14, Lines Deleted: 11; 2840 bytes @@ -8631,9 +8631,9 @@ <listitem> <para> They are, in many people's opinion, more readable than - complex joins and/or unions. Indeed, it was the innovation - of subqueries that gave people the original idea of calling - the early SQL <quote>Structured Query Language.</quote> + complex joins or unions. Indeed, it was the innovation of + subqueries that gave people the original idea of calling the + early SQL <quote>Structured Query Language.</quote> </para> </listitem> @@ -8888,7 +8888,7 @@ <literal>FALSE</literal> if table <literal>t2</literal> contains <literal>(20,10)</literal>, or if table <literal>t2</literal> is empty. The expression is - <literal>UNKNOWN</literal> if table <literal>t2</literal> + <emphasis>unknown</emphasis> if table <literal>t2</literal> contains <literal>(NULL,NULL,NULL)</literal>. </para> @@ -9366,9 +9366,11 @@ <para> Subqueries in the <literal>FROM</literal> clause are executed even for the <literal>EXPLAIN</literal> statement (that is, - derived temporary tables are built). This occurs because upper - level queries need information about all tables during - optimization phase. + derived temporary tables are built). This occurs because + upper-level queries need information about all tables during + the optimization phase, and the table represented by a + subquery in the <literal>FROM</literal> clause is unavailable + unless the subquery is executed. </para> </section> @@ -9427,9 +9429,9 @@ <para> You may use a subquery that returns multiple columns, if - the purpose is comparison. See - <xref linkend="row-subqueries"/>. However, in other - contexts, the subquery must be a scalar operand. + the purpose is comparison. In other contexts, the subquery + must be a scalar operand. See + <xref linkend="row-subqueries"/>. </para> </listitem> @@ -9893,7 +9895,8 @@ statements that can be used to efficiently delete rows based on information from one table or even from many tables at the same time. Multiple-table <literal>UPDATE</literal> statements - are also supported. + are also supported. See <xref linkend="delete"/>, and + <xref linkend="update"/>. </para> </section> Modified: trunk/refman-5.1/sql-syntax.xml =================================================================== --- trunk/refman-5.1/sql-syntax.xml 2007-03-02 16:17:26 UTC (rev 5150) +++ trunk/refman-5.1/sql-syntax.xml 2007-03-02 19:18:17 UTC (rev 5151) Changed blocks: 6, Lines Added: 21, Lines Deleted: 20; 3696 bytes @@ -10266,9 +10266,9 @@ <listitem> <para> They are, in many people's opinion, more readable than - complex joins and/or unions. Indeed, it was the innovation - of subqueries that gave people the original idea of calling - the early SQL <quote>Structured Query Language.</quote> + complex joins or unions. Indeed, it was the innovation of + subqueries that gave people the original idea of calling the + early SQL <quote>Structured Query Language.</quote> </para> </listitem> @@ -10523,7 +10523,7 @@ <literal>FALSE</literal> if table <literal>t2</literal> contains <literal>(20,10)</literal>, or if table <literal>t2</literal> is empty. The expression is - <literal>UNKNOWN</literal> if table <literal>t2</literal> + <emphasis>unknown</emphasis> if table <literal>t2</literal> contains <literal>(NULL,NULL,NULL)</literal>. </para> @@ -11001,9 +11001,11 @@ <para> Subqueries in the <literal>FROM</literal> clause are executed even for the <literal>EXPLAIN</literal> statement (that is, - derived temporary tables are built). This occurs because upper - level queries need information about all tables during - optimization phase. + derived temporary tables are built). This occurs because + upper-level queries need information about all tables during + the optimization phase, and the table represented by a + subquery in the <literal>FROM</literal> clause is unavailable + unless the subquery is executed. </para> </section> @@ -11062,9 +11064,9 @@ <para> You may use a subquery that returns multiple columns, if - the purpose is comparison. See - <xref linkend="row-subqueries"/>. However, in other - contexts, the subquery must be a scalar operand. + the purpose is comparison. In other contexts, the subquery + must be a scalar operand. See + <xref linkend="row-subqueries"/>. </para> </listitem> @@ -11528,7 +11530,8 @@ statements that can be used to efficiently delete rows based on information from one table or even from many tables at the same time. Multiple-table <literal>UPDATE</literal> statements - are also supported. + are also supported. See <xref linkend="delete"/>, and + <xref linkend="update"/>. </para> </section> @@ -13696,22 +13699,20 @@ values in a list of values returned by the <literal>XA RECOVER</literal> statement. </para> - - + <formalpara role="mnmas"> - + <title>MySQL Enterprise</title> - + <para> For expert advice on XA Distributed Transaction Support - subscribe to the MySQL Network Monitoring - and Advisory Service. For more information see, + subscribe to the MySQL Network Monitoring and Advisory + Service. For more information see, <ulink url="&base-url-enterprise;advisors.html"/>. </para> - + </formalpara> - - + <para> <literal>XA START <replaceable>xid</replaceable></literal> starts an XA transaction with the given
| Thread | ||
|---|---|---|
| • svn commit - mysqldoc@docsrva: r5151 - in trunk: . internals refman-4.1 refman-5.0 refman-5.1 | paul | 2 Mar |
© 1995-2008 MySQL AB, 2008-2009 Sun Microsystems, Inc.
Page generated in 0.495 sec. using MySQL 5.1.14-beta-log