Author: paul
Date: 2007-12-03 05:00:46 +0100 (Mon, 03 Dec 2007)
New Revision: 9060
Log:
r27673@frost: paul | 2007-12-02 21:57:23 -0600
Add markup.
Modified:
trunk/refman-4.1/functions-core.xml
trunk/refman-4.1/introduction.xml
trunk/refman-4.1/news-3.20.xml
trunk/refman-4.1/news-3.21.xml
trunk/refman-4.1/news-3.23.xml
trunk/refman-4.1/news-4.0.xml
trunk/refman-4.1/optimization.xml
trunk/refman-4.1/restrictions.xml
trunk/refman-4.1/tutorial.xml
trunk/refman-5.0/dba-core.xml
trunk/refman-5.0/functions-core.xml
trunk/refman-5.0/introduction.xml
trunk/refman-5.0/optimization.xml
trunk/refman-5.0/restrictions.xml
trunk/refman-5.0/tutorial.xml
trunk/refman-5.0/views.xml
trunk/refman-5.1/ccsg-temp.xml
trunk/refman-5.1/dba-core.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:33675
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:27672
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:22582
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:33675
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:27673
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:22582
Modified: trunk/refman-4.1/functions-core.xml
===================================================================
--- trunk/refman-4.1/functions-core.xml 2007-12-03 04:00:27 UTC (rev 9059)
+++ trunk/refman-4.1/functions-core.xml 2007-12-03 04:00:46 UTC (rev 9060)
Changed blocks: 8, Lines Added: 14, Lines Deleted: 10; 3548 bytes
@@ -1194,7 +1194,7 @@
<primary>ISNULL()</primary>
</indexterm>
- <literal>ISNULL(<replaceable>expr</replaceable>)</literal>
+ <function role="sql">ISNULL(<replaceable>expr</replaceable>)</function>
</para>
<remark role="help-syntax-end"/>
@@ -1203,7 +1203,8 @@
<para>
If <replaceable>expr</replaceable> is
- <literal>NULL</literal>, <literal>ISNULL()</literal> returns
+ <literal>NULL</literal>,
+ <function role="sql">ISNULL()</function> returns
<literal>1</literal>, otherwise it returns
<literal>0</literal>.
</para>
@@ -1220,7 +1221,8 @@
</programlisting>
<para>
- <literal>ISNULL()</literal> can be used instead of
+ <function role="sql">ISNULL()</function> can be used instead
+ of
<function role="sqlop" condition="operator_equal">=</function>
to test whether a value is <literal>NULL</literal>.
(Comparing a value to <literal>NULL</literal> using
@@ -1229,8 +1231,8 @@
</para>
<para>
- The <literal>ISNULL()</literal> function shares some special
- behaviors with the
+ The <function role="sql">ISNULL()</function> function shares
+ some special behaviors with the
<function role="sqlop" condition="operator_is-null">IS
NULL</function> comparison operator. See the description of
<function role="sqlop" condition="operator_is-null">IS
@@ -1248,7 +1250,7 @@
<primary>INTERVAL()</primary>
</indexterm>
- <literal>INTERVAL(<replaceable>N</replaceable>,<replaceable>N1</replaceable>,<replaceable>N2</replaceable>,<replaceable>N3</replaceable>,...)</literal>
+ <function role="sql">INTERVAL(<replaceable>N</replaceable>,<replaceable>N1</replaceable>,<replaceable>N2</replaceable>,<replaceable>N3</replaceable>,...)</function>
</para>
<remark role="help-syntax-end"/>
@@ -1453,7 +1455,8 @@
<primary>! (logical NOT)</primary>
</indexterm>
- <literal>NOT</literal>, <literal>!</literal>
+ <function role="sqlop">NOT</function>,
+ <function role="sqlop" condition="operator_not">!</function>
</para>
<remark role="help-syntax-end"/>
@@ -1510,7 +1513,8 @@
<primary>&& (logical AND)</primary>
</indexterm>
- <literal>AND</literal>, <literal>&&</literal>
+ <function role="sqlop">AND</function>,
+ <function role="sqlop" condition="operator_and">&&</function>
</para>
<remark role="help-syntax-end"/>
@@ -4276,8 +4280,8 @@
comparisons using <literal>NOT RLIKE</literal> or
<literal>NOT REGEXP</literal>. In such cases, you must
test explicitly for <literal>NOT NULL</literal> using
- <literal>OR</literal> (and not <literal>AND</literal>), as
- shown here:
+ <literal>OR</literal> (and not
+ <function role="sqlop">AND</function>), as shown here:
<programlisting>
SELECT COUNT(*) FROM foo WHERE bar NOT LIKE '%baz%' OR bar IS NULL;
Modified: trunk/refman-4.1/introduction.xml
===================================================================
--- trunk/refman-4.1/introduction.xml 2007-12-03 04:00:27 UTC (rev 9059)
+++ trunk/refman-4.1/introduction.xml 2007-12-03 04:00:46 UTC (rev 9060)
Changed blocks: 1, Lines Added: 22, Lines Deleted: 12; 2496 bytes
@@ -1714,18 +1714,28 @@
<listitem>
<para>
- MySQL Server understands the <literal>||</literal> and
- <literal>&&</literal> operators to mean logical
- OR and AND, as in the C programming language. In MySQL
- Server, <literal>||</literal> and <literal>OR</literal>
- are synonyms, as are <literal>&&</literal> and
- <literal>AND</literal>. Because of this nice syntax,
- MySQL Server doesn't support the standard SQL
- <literal>||</literal> operator for string concatenation;
- use <literal>CONCAT()</literal> instead. Because
- <literal>CONCAT()</literal> takes any number of
- arguments, it's easy to convert use of the
- <literal>||</literal> operator to MySQL Server.
+ MySQL Server understands the
+ <function role="sqlop" condition="operator_or">||</function>
+ and
+ <function role="sqlop" condition="operator_and">&&</function>
+ operators to mean logical OR and AND, as in the C
+ programming language. In MySQL Server,
+ <function role="sqlop" condition="operator_or">||</function>
+ and
+ <function role="sqlop" condition="operator_or">OR</function>
+ are synonyms, as are
+ <function role="sqlop" condition="operator_and">&&</function>
+ and
+ <function role="sqlop" condition="operator_and">AND</function>.
+ Because of this nice syntax, MySQL Server doesn't
+ support the standard SQL
+ <function role="sqlop" condition="operator_or">||</function>
+ operator for string concatenation; use
+ <function role="sql">CONCAT()</function> instead.
+ Because <function role="sql">CONCAT()</function> takes
+ any number of arguments, it's easy to convert use of the
+ <function role="sqlop" condition="operator_or">||</function>
+ operator to MySQL Server.
</para>
</listitem>
Modified: trunk/refman-4.1/news-3.20.xml
===================================================================
--- trunk/refman-4.1/news-3.20.xml 2007-12-03 04:00:27 UTC (rev 9059)
+++ trunk/refman-4.1/news-3.20.xml 2007-12-03 04:00:46 UTC (rev 9060)
Changed blocks: 3, Lines Added: 8, Lines Deleted: 7; 1386 bytes
@@ -516,8 +516,8 @@
<listitem>
<para>
- Fixed a bug in <literal>OR</literal> of multiple tables (gave
- empty set).
+ Fixed a bug in <function role="sqlop">OR</function> of
+ multiple tables (gave empty set).
</para>
</listitem>
@@ -548,7 +548,8 @@
<listitem>
<para>
Fixed bug in <literal>SELECT</literal> with
- <literal>AND</literal>-<literal>OR</literal> levels.
+ <function role="sqlop">AND</function>-<function role="sqlop">OR</function>
+ levels.
</para>
</listitem>
@@ -1200,10 +1201,10 @@
<listitem>
<para>
- Changed name of SQL function <literal>FIELDS()</literal> to
- <literal>ELT()</literal>. Changed SQL function
- <literal>INTERVALL()</literal> to
- <literal>INTERVAL()</literal>.
+ Changed name of SQL function <function>FIELDS()</function> to
+ <function role="sql">ELT()</function>. Changed SQL function
+ <function>INTERVALL()</function> to
+ <function role="sql">INTERVAL()</function>.
</para>
</listitem>
Modified: trunk/refman-4.1/news-3.21.xml
===================================================================
--- trunk/refman-4.1/news-3.21.xml 2007-12-03 04:00:27 UTC (rev 9059)
+++ trunk/refman-4.1/news-3.21.xml 2007-12-03 04:00:46 UTC (rev 9060)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 2; 634 bytes
@@ -733,8 +733,8 @@
<listitem>
<para>
Fixed unlikely(?) key optimizer bug when using
- <literal>OR</literal> operators of key parts inside
- <literal>AND</literal> expressions.
+ <function role="sqlop">OR</function> operators of key parts
+ inside <function role="sqlop">AND</function> expressions.
</para>
</listitem>
Modified: trunk/refman-4.1/news-3.23.xml
===================================================================
--- trunk/refman-4.1/news-3.23.xml 2007-12-03 04:00:27 UTC (rev 9059)
+++ trunk/refman-4.1/news-3.23.xml 2007-12-03 04:00:46 UTC (rev 9060)
Changed blocks: 3, Lines Added: 13, Lines Deleted: 10; 2225 bytes
@@ -91,10 +91,11 @@
<para>
Fixed incorrect destruction of expression which led to crash
of server on complex
- <literal>AND</literal>/<literal>OR</literal> expressions if
- query was ignored (either by a replication server because of
- <option>--replicate-*-table</option> rules, or by any MySQL
- server because of a syntax error). (Bug #3969, Bug #4494)
+ <function role="sqlop">AND</function>/<function role="sqlop">OR</function>
+ expressions if query was ignored (either by a replication
+ server because of <option>--replicate-*-table</option> rules,
+ or by any MySQL server because of a syntax error). (Bug #3969,
+ Bug #4494)
</para>
</listitem>
@@ -1054,10 +1055,12 @@
<listitem>
<para>
- Changed <literal>AND/OR</literal> to report that they can
- return NULL. This fixes a bug in <literal>GROUP BY</literal>
- on <literal>AND/OR</literal> expressions that return
- <literal>NULL</literal>.
+ Changed
+ <function role="sqlop">AND</function>/<function role="sqlop">OR</function>
+ to report that they can return NULL. This fixes a bug in
+ <literal>GROUP BY</literal> on
+ <function role="sqlop">AND</function>/<function role="sqlop">OR</function>
+ expressions that return <literal>NULL</literal>.
</para>
</listitem>
@@ -1380,9 +1383,9 @@
<listitem>
<para>
Fixed optimization bug with
- <literal>ISNULL(<replaceable>expression_which_cannot_be_null</replaceable>)</literal>
+ <function role="sql">ISNULL(<replaceable>expression_which_cannot_be_null</replaceable>)</function>
and
- <literal>ISNULL(<replaceable>constant_expression</replaceable>)</literal>.
+ <function role="sql">ISNULL(<replaceable>constant_expression</replaceable>)</function>.
</para>
</listitem>
Modified: trunk/refman-4.1/news-4.0.xml
===================================================================
--- trunk/refman-4.1/news-4.0.xml 2007-12-03 04:00:27 UTC (rev 9059)
+++ trunk/refman-4.1/news-4.0.xml 2007-12-03 04:00:46 UTC (rev 9060)
Changed blocks: 5, Lines Added: 17, Lines Deleted: 13; 2729 bytes
@@ -2083,10 +2083,11 @@
<para>
Fixed incorrect destruction of expression which led to crash
of server on complex
- <literal>AND</literal>/<literal>OR</literal> expressions if
- query was ignored (either by a replication server because of
- <option>--replicate-*-table</option> rules, or by any MySQL
- server because of a syntax error). (Bug #3969, Bug #4494)
+ <function role="sqlop">AND</function>/<function role="sqlop">OR</function>
+ expressions if query was ignored (either by a replication
+ server because of <option>--replicate-*-table</option> rules,
+ or by any MySQL server because of a syntax error). (Bug #3969,
+ Bug #4494)
</para>
</listitem>
@@ -3567,7 +3568,8 @@
<listitem>
<para>
Fixed bug in range optimizer that caused wrong results for
- some unlikely <literal>AND</literal>/<literal>OR</literal>
+ some unlikely
+ <function role="sqlop">AND</function>/<function role="sqlop">OR</function>
queries. (Bug #1828)
</para>
</listitem>
@@ -4803,8 +4805,9 @@
<listitem>
<para>
- A documentation change: Function <literal>INTERVAL(NULL,
- ...)</literal> returns <literal>-1</literal>.
+ A documentation change: Function
+ <function role="sql">INTERVAL(NULL, ...)</function> returns
+ <literal>-1</literal>.
</para>
</listitem>
@@ -7273,10 +7276,11 @@
<listitem>
<para>
- Change that <literal>AND</literal> works according to standard
- SQL when it comes to <literal>NULL</literal> handling. In
- practice, this affects only queries where you do something
- like <literal>WHERE ... NOT (NULL AND 0)</literal>.
+ Change that <function role="sqlop">AND</function> works
+ according to standard SQL when it comes to
+ <literal>NULL</literal> handling. In practice, this affects
+ only queries where you do something like <literal>WHERE ...
+ NOT (NULL AND 0)</literal>.
</para>
</listitem>
@@ -9470,8 +9474,8 @@
<listitem>
<para>
Speed up <function role="sqlop">IS NULL</function>,
- <literal>ISNULL()</literal> and some other internal
- primitives.
+ <function role="sql">ISNULL()</function> and some other
+ internal primitives.
</para>
</listitem>
Modified: trunk/refman-4.1/optimization.xml
===================================================================
--- trunk/refman-4.1/optimization.xml 2007-12-03 04:00:27 UTC (rev 9059)
+++ trunk/refman-4.1/optimization.xml 2007-12-03 04:00:46 UTC (rev 9060)
Changed blocks: 5, Lines Added: 20, Lines Deleted: 15; 3575 bytes
@@ -2316,8 +2316,9 @@
<listitem>
<para>
For all types of indexes, multiple range conditions
- combined with <literal>OR</literal> or
- <literal>AND</literal> form a range condition.
+ combined with <function role="sqlop">OR</function> or
+ <function role="sqlop">AND</function> form a range
+ condition.
</para>
</listitem>
@@ -2504,9 +2505,10 @@
<para>
The range condition extraction algorithm can handle nested
- <literal>AND</literal>/<literal>OR</literal> constructs of
- arbitrary depth, and its output does not depend on the order
- in which conditions appear in <literal>WHERE</literal> clause.
+ <function role="sqlop">AND</function>/<function role="sqlop">OR</function>
+ constructs of arbitrary depth, and its output does not depend
+ on the order in which conditions appear in
+ <literal>WHERE</literal> clause.
</para>
</section>
@@ -2614,8 +2616,8 @@
<para>
For a <literal>BTREE</literal> index, an interval might be
usable for conditions combined with
- <literal>AND</literal>, where each condition compares a
- key part with a constant value using
+ <function role="sqlop">AND</function>, where each
+ condition compares a key part with a constant value using
<function role="sqlop" condition="operator_equal">=</function>,
<function role="sqlop" condition="operator_equal-to"><=></function>,
<function role="sqlop">IS NULL</function>,
@@ -2663,11 +2665,12 @@
<listitem>
<para>
If conditions that cover sets of rows contained within
- intervals are combined with <literal>OR</literal>, they
- form a condition that covers a set of rows contained
- within the union of their intervals. If the conditions are
- combined with <literal>AND</literal>, they form a
+ intervals are combined with
+ <function role="sqlop">OR</function>, they form a
condition that covers a set of rows contained within the
+ union of their intervals. If the conditions are combined
+ with <function role="sqlop">AND</function>, they form a
+ condition that covers a set of rows contained within the
intersection of their intervals. For example, for this
condition on a two-part index:
</para>
@@ -6216,10 +6219,12 @@
</para>
<para>
- Any index that does not span all <literal>AND</literal> levels
- in the <literal>WHERE</literal> clause is not used to optimize
- the query. In other words, to be able to use an index, a prefix
- of the index must be used in every <literal>AND</literal> group.
+ Any index that does not span all
+ <function role="sqlop">AND</function> levels in the
+ <literal>WHERE</literal> clause is not used to optimize the
+ query. In other words, to be able to use an index, a prefix of
+ the index must be used in every
+ <function role="sqlop">AND</function> group.
</para>
<para>
Modified: trunk/refman-4.1/restrictions.xml
===================================================================
--- trunk/refman-4.1/restrictions.xml 2007-12-03 04:00:27 UTC (rev 9059)
+++ trunk/refman-4.1/restrictions.xml 2007-12-03 04:00:46 UTC (rev 9060)
Changed blocks: 1, Lines Added: 5, Lines Deleted: 3; 1003 bytes
@@ -185,9 +185,11 @@
The reason for supporting row comparisons for
<literal>IN</literal> but not for the others is that
<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
+ sequence of
+ <function role="sqlop" condition="operator_equal">=</function>
+ comparisons and <function role="sqlop">AND</function>
+ operations. This approach cannot be used for
+ <literal>ALL</literal>, <literal>ANY</literal>, or
<literal>SOME</literal>.
</para>
</listitem>
Modified: trunk/refman-4.1/tutorial.xml
===================================================================
--- trunk/refman-4.1/tutorial.xml 2007-12-03 04:00:27 UTC (rev 9059)
+++ trunk/refman-4.1/tutorial.xml 2007-12-03 04:00:46 UTC (rev 9060)
Changed blocks: 3, Lines Added: 13, Lines Deleted: 10; 2032 bytes
@@ -1400,8 +1400,9 @@
</programlisting>
<para>
- The preceding query uses the <literal>AND</literal> logical
- operator. There is also an <literal>OR</literal> operator:
+ The preceding query uses the
+ <function role="sqlop">AND</function> logical operator. There
+ is also an <function role="sqlop">OR</function> operator:
</para>
<programlisting>
@@ -1416,11 +1417,12 @@
</programlisting>
<para>
- <literal>AND</literal> and <literal>OR</literal> may be
- intermixed, although <literal>AND</literal> has higher
- precedence than <literal>OR</literal>. If you use both
- operators, it is a good idea to use parentheses to indicate
- explicitly how conditions should be grouped:
+ <function role="sqlop">AND</function> and
+ <function role="sqlop">OR</function> may be intermixed,
+ although <function role="sqlop">AND</function> has higher
+ precedence than <function role="sqlop">OR</function>. If you
+ use both operators, it is a good idea to use parentheses to
+ indicate explicitly how conditions should be grouped:
</para>
<programlisting>
@@ -3709,13 +3711,14 @@
</indexterm>
<para>
- An <literal>OR</literal> using a single key is well optimized,
- as is the handling of <literal>AND</literal>.
+ An <function role="sqlop">OR</function> using a single key is
+ well optimized, as is the handling of
+ <function role="sqlop">AND</function>.
</para>
<para>
The one tricky case is that of searching on two different keys
- combined with <literal>OR</literal>:
+ combined with <function role="sqlop">OR</function>:
</para>
<programlisting>
Modified: trunk/refman-5.0/dba-core.xml
===================================================================
--- trunk/refman-5.0/dba-core.xml 2007-12-03 04:00:27 UTC (rev 9059)
+++ trunk/refman-5.0/dba-core.xml 2007-12-03 04:00:46 UTC (rev 9060)
Changed blocks: 1, Lines Added: 5, Lines Deleted: 5; 1200 bytes
@@ -10288,11 +10288,11 @@
<para>
From MySQL 5.0.2 on, the precedence of the
- <literal>NOT</literal> operator is such that expressions
- such as <literal>NOT a BETWEEN b AND c</literal> are
- parsed as <literal>NOT (a BETWEEN b AND c)</literal>.
- Before MySQL 5.0.2, the expression is parsed as
- <literal>(NOT a) BETWEEN b AND c</literal>. The old
+ <function role="sqlop">NOT</function> operator is such
+ that expressions such as <literal>NOT a BETWEEN b AND
+ c</literal> are parsed as <literal>NOT (a BETWEEN b AND
+ c)</literal>. Before MySQL 5.0.2, the expression is parsed
+ as <literal>(NOT a) BETWEEN b AND c</literal>. The old
higher-precedence behavior can be obtained by enabling the
<literal>HIGH_NOT_PRECEDENCE</literal> SQL mode. (Added in
MySQL 5.0.2)
Modified: trunk/refman-5.0/functions-core.xml
===================================================================
--- trunk/refman-5.0/functions-core.xml 2007-12-03 04:00:27 UTC (rev 9059)
+++ trunk/refman-5.0/functions-core.xml 2007-12-03 04:00:46 UTC (rev 9060)
Changed blocks: 10, Lines Added: 24, Lines Deleted: 19; 4877 bytes
@@ -170,12 +170,13 @@
</para>
<para>
- The precedence shown for <literal>NOT</literal> is as of MySQL
- 5.0.2. For earlier versions, or from 5.0.2 on if the
- <literal>HIGH_NOT_PRECEDENCE</literal> SQL mode is enabled, the
- precedence of <literal>NOT</literal> is the same as that of the
- <literal>!</literal> operator. See
- <xref linkend="server-sql-mode"/>.
+ The precedence shown for <function role="sqlop">NOT</function>
+ is as of MySQL 5.0.2. For earlier versions, or from 5.0.2 on if
+ the <literal>HIGH_NOT_PRECEDENCE</literal> SQL mode is enabled,
+ the precedence of <function role="sqlop">NOT</function> is the
+ same as that of the
+ <function role="sqlop" condition="operator_not">!</function>
+ operator. See <xref linkend="server-sql-mode"/>.
</para>
<indexterm>
@@ -1315,7 +1316,7 @@
<primary>ISNULL()</primary>
</indexterm>
- <literal>ISNULL(<replaceable>expr</replaceable>)</literal>
+ <function role="sql">ISNULL(<replaceable>expr</replaceable>)</function>
</para>
<remark role="help-syntax-end"/>
@@ -1324,7 +1325,8 @@
<para>
If <replaceable>expr</replaceable> is
- <literal>NULL</literal>, <literal>ISNULL()</literal> returns
+ <literal>NULL</literal>,
+ <function role="sql">ISNULL()</function> returns
<literal>1</literal>, otherwise it returns
<literal>0</literal>.
</para>
@@ -1341,7 +1343,8 @@
</programlisting>
<para>
- <literal>ISNULL()</literal> can be used instead of
+ <function role="sql">ISNULL()</function> can be used instead
+ of
<function role="sqlop" condition="operator_equal">=</function>
to test whether a value is <literal>NULL</literal>.
(Comparing a value to <literal>NULL</literal> using
@@ -1350,8 +1353,8 @@
</para>
<para>
- The <literal>ISNULL()</literal> function shares some special
- behaviors with the
+ The <function role="sql">ISNULL()</function> function shares
+ some special behaviors with the
<function role="sqlop" condition="operator_is-null">IS
NULL</function> comparison operator. See the description of
<function role="sqlop" condition="operator_is-null">IS
@@ -1369,7 +1372,7 @@
<primary>INTERVAL()</primary>
</indexterm>
- <literal>INTERVAL(<replaceable>N</replaceable>,<replaceable>N1</replaceable>,<replaceable>N2</replaceable>,<replaceable>N3</replaceable>,...)</literal>
+ <function role="sql">INTERVAL(<replaceable>N</replaceable>,<replaceable>N1</replaceable>,<replaceable>N2</replaceable>,<replaceable>N3</replaceable>,...)</function>
</para>
<remark role="help-syntax-end"/>
@@ -1570,7 +1573,8 @@
<primary>! (logical NOT)</primary>
</indexterm>
- <literal>NOT</literal>, <literal>!</literal>
+ <function role="sqlop">NOT</function>,
+ <function role="sqlop" condition="operator_not">!</function>
</para>
<remark role="help-syntax-end"/>
@@ -1608,9 +1612,9 @@
</para>
<para>
- Note that the precedence of the <literal>NOT</literal>
- operator changed in MySQL 5.0.2. See
- <xref linkend="operator-precedence"/>.
+ Note that the precedence of the
+ <function role="sqlop">NOT</function> operator changed in
+ MySQL 5.0.2. See <xref linkend="operator-precedence"/>.
</para>
</listitem>
@@ -1633,7 +1637,8 @@
<primary>&& (logical AND)</primary>
</indexterm>
- <literal>AND</literal>, <literal>&&</literal>
+ <function role="sqlop">AND</function>,
+ <function role="sqlop" condition="operator_and">&&</function>
</para>
<remark role="help-syntax-end"/>
@@ -4460,8 +4465,8 @@
comparisons using <literal>NOT RLIKE</literal> or
<literal>NOT REGEXP</literal>. In such cases, you must
test explicitly for <literal>NOT NULL</literal> using
- <literal>OR</literal> (and not <literal>AND</literal>), as
- shown here:
+ <literal>OR</literal> (and not
+ <function role="sqlop">AND</function>), as shown here:
<programlisting>
SELECT COUNT(*) FROM foo WHERE bar NOT LIKE '%baz%' OR bar IS NULL;
Modified: trunk/refman-5.0/introduction.xml
===================================================================
--- trunk/refman-5.0/introduction.xml 2007-12-03 04:00:27 UTC (rev 9059)
+++ trunk/refman-5.0/introduction.xml 2007-12-03 04:00:46 UTC (rev 9060)
Changed blocks: 3, Lines Added: 32, Lines Deleted: 20; 4195 bytes
@@ -568,12 +568,13 @@
<listitem>
<para>
Use of the <firstterm>Index Merge</firstterm> method to
- obtain better optimization of <literal>AND</literal> and
- <literal>OR</literal> relations over different keys.
- (Previously, these were optimized only where both
- relations in the <literal>WHERE</literal> clause
- involved the same key.) This also applies to other
- one-to-one comparison operators
+ obtain better optimization of
+ <function role="sqlop">AND</function> and
+ <function role="sqlop">OR</function> relations over
+ different keys. (Previously, these were optimized only
+ where both relations in the <literal>WHERE</literal>
+ clause involved the same key.) This also applies to
+ other one-to-one comparison operators
(<literal>></literal>, <literal><</literal>, and
so on), including <literal>=</literal> and the
<literal>IN</literal> operator. This means that MySQL
@@ -607,8 +608,9 @@
<para>
These optimizations can be applied with any combination
- of <literal>AND</literal> and <literal>OR</literal>
- operators. See <xref linkend="nested-joins"/>, and
+ of <function role="sqlop">AND</function> and
+ <function role="sqlop">OR</function> operators. See
+ <xref linkend="nested-joins"/>, and
<xref linkend="outer-join-simplification"/>.
</para>
</listitem>
@@ -1388,18 +1390,28 @@
<listitem>
<para>
- MySQL Server understands the <literal>||</literal> and
- <literal>&&</literal> operators to mean logical
- OR and AND, as in the C programming language. In MySQL
- Server, <literal>||</literal> and <literal>OR</literal>
- are synonyms, as are <literal>&&</literal> and
- <literal>AND</literal>. Because of this nice syntax,
- MySQL Server doesn't support the standard SQL
- <literal>||</literal> operator for string concatenation;
- use <literal>CONCAT()</literal> instead. Because
- <literal>CONCAT()</literal> takes any number of
- arguments, it's easy to convert use of the
- <literal>||</literal> operator to MySQL Server.
+ MySQL Server understands the
+ <function role="sqlop" condition="operator_or">||</function>
+ and
+ <function role="sqlop" condition="operator_and">&&</function>
+ operators to mean logical OR and AND, as in the C
+ programming language. In MySQL Server,
+ <function role="sqlop" condition="operator_or">||</function>
+ and
+ <function role="sqlop" condition="operator_or">OR</function>
+ are synonyms, as are
+ <function role="sqlop" condition="operator_and">&&</function>
+ and
+ <function role="sqlop" condition="operator_and">AND</function>.
+ Because of this nice syntax, MySQL Server doesn't
+ support the standard SQL
+ <function role="sqlop" condition="operator_or">||</function>
+ operator for string concatenation; use
+ <function role="sql">CONCAT()</function> instead.
+ Because <function role="sql">CONCAT()</function> takes
+ any number of arguments, it's easy to convert use of the
+ <function role="sqlop" condition="operator_or">||</function>
+ operator to MySQL Server.
</para>
</listitem>
Modified: trunk/refman-5.0/optimization.xml
===================================================================
--- trunk/refman-5.0/optimization.xml 2007-12-03 04:00:27 UTC (rev 9059)
+++ trunk/refman-5.0/optimization.xml 2007-12-03 04:00:46 UTC (rev 9060)
Changed blocks: 9, Lines Added: 27, Lines Deleted: 22; 5260 bytes
@@ -2504,8 +2504,9 @@
<listitem>
<para>
For all types of indexes, multiple range conditions
- combined with <literal>OR</literal> or
- <literal>AND</literal> form a range condition.
+ combined with <function role="sqlop">OR</function> or
+ <function role="sqlop">AND</function> form a range
+ condition.
</para>
</listitem>
@@ -2692,9 +2693,10 @@
<para>
The range condition extraction algorithm can handle nested
- <literal>AND</literal>/<literal>OR</literal> constructs of
- arbitrary depth, and its output does not depend on the order
- in which conditions appear in <literal>WHERE</literal> clause.
+ <function role="sqlop">AND</function>/<function role="sqlop">OR</function>
+ constructs of arbitrary depth, and its output does not depend
+ on the order in which conditions appear in
+ <literal>WHERE</literal> clause.
</para>
<para>
@@ -2811,8 +2813,8 @@
<para>
For a <literal>BTREE</literal> index, an interval might be
usable for conditions combined with
- <literal>AND</literal>, where each condition compares a
- key part with a constant value using
+ <function role="sqlop">AND</function>, where each
+ condition compares a key part with a constant value using
<function role="sqlop" condition="operator_equal">=</function>,
<function role="sqlop" condition="operator_equal-to"><=></function>,
<function role="sqlop">IS NULL</function>,
@@ -2863,10 +2865,10 @@
intervals are combined with <literal>OR</literal>, they
form a condition that covers a set of rows contained
within the union of their intervals. If the conditions are
- combined with <literal>AND</literal>, they form a
- condition that covers a set of rows contained within the
- intersection of their intervals. For example, for this
- condition on a two-part index:
+ combined with <function role="sqlop">AND</function>, they
+ form a condition that covers a set of rows contained
+ within the intersection of their intervals. For example,
+ for this condition on a two-part index:
</para>
<programlisting>
@@ -3093,7 +3095,8 @@
<listitem>
<para>
If your query has a complex <literal>WHERE</literal> clause
- with deep <literal>AND</literal>/<literal>OR</literal>
+ with deep
+ <function role="sqlop">AND</function>/<function role="sqlop">OR</function>
nesting and MySQL doesn't choose the optimal plan, try
distributing terms using the following identity laws:
</para>
@@ -3127,8 +3130,8 @@
This access algorithm can be employed when a
<literal>WHERE</literal> clause was converted to several range
conditions on different keys combined with
- <literal>AND</literal>, and each condition is one of the
- following:
+ <function role="sqlop">AND</function>, and each condition is
+ one of the following:
</para>
<itemizedlist>
@@ -5257,8 +5260,8 @@
<para>
You do not need to distinguish <literal>NULL</literal> from
<literal>FALSE</literal> subquery results. (If the subquery
- is a part of an <literal>OR</literal> or
- <literal>AND</literal> expression in the
+ is a part of an <function role="sqlop">OR</function> or
+ <function role="sqlop">AND</function> expression in the
<literal>WHERE</literal> clause, MySQL assumes that you
don't care.)
</para>
@@ -5710,8 +5713,8 @@
<para>
Then <literal>NULL IN (SELECT ...)</literal> will never be
evaluated because MySQL stops evaluating
- <literal>AND</literal> parts as soon as the expression
- result is clear.
+ <function role="sqlop">AND</function> parts as soon as the
+ expression result is clear.
</para>
</listitem>
@@ -8406,10 +8409,12 @@
</para>
<para>
- Any index that does not span all <literal>AND</literal> levels
- in the <literal>WHERE</literal> clause is not used to optimize
- the query. In other words, to be able to use an index, a prefix
- of the index must be used in every <literal>AND</literal> group.
+ Any index that does not span all
+ <function role="sqlop">AND</function> levels in the
+ <literal>WHERE</literal> clause is not used to optimize the
+ query. In other words, to be able to use an index, a prefix of
+ the index must be used in every
+ <function role="sqlop">AND</function> group.
</para>
<para>
Modified: trunk/refman-5.0/restrictions.xml
===================================================================
--- trunk/refman-5.0/restrictions.xml 2007-12-03 04:00:27 UTC (rev 9059)
+++ trunk/refman-5.0/restrictions.xml 2007-12-03 04:00:46 UTC (rev 9060)
Changed blocks: 1, Lines Added: 5, Lines Deleted: 3; 1003 bytes
@@ -556,9 +556,11 @@
The reason for supporting row comparisons for
<literal>IN</literal> but not for the others is that
<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
+ sequence of
+ <function role="sqlop" condition="operator_equal">=</function>
+ comparisons and <function role="sqlop">AND</function>
+ operations. This approach cannot be used for
+ <literal>ALL</literal>, <literal>ANY</literal>, or
<literal>SOME</literal>.
</para>
</listitem>
Modified: trunk/refman-5.0/tutorial.xml
===================================================================
--- trunk/refman-5.0/tutorial.xml 2007-12-03 04:00:27 UTC (rev 9059)
+++ trunk/refman-5.0/tutorial.xml 2007-12-03 04:00:46 UTC (rev 9060)
Changed blocks: 3, Lines Added: 13, Lines Deleted: 10; 2032 bytes
@@ -1408,8 +1408,9 @@
</programlisting>
<para>
- The preceding query uses the <literal>AND</literal> logical
- operator. There is also an <literal>OR</literal> operator:
+ The preceding query uses the
+ <function role="sqlop">AND</function> logical operator. There
+ is also an <function role="sqlop">OR</function> operator:
</para>
<programlisting>
@@ -1424,11 +1425,12 @@
</programlisting>
<para>
- <literal>AND</literal> and <literal>OR</literal> may be
- intermixed, although <literal>AND</literal> has higher
- precedence than <literal>OR</literal>. If you use both
- operators, it is a good idea to use parentheses to indicate
- explicitly how conditions should be grouped:
+ <function role="sqlop">AND</function> and
+ <function role="sqlop">OR</function> may be intermixed,
+ although <function role="sqlop">AND</function> has higher
+ precedence than <function role="sqlop">OR</function>. If you
+ use both operators, it is a good idea to use parentheses to
+ indicate explicitly how conditions should be grouped:
</para>
<programlisting>
@@ -3584,13 +3586,14 @@
</indexterm>
<para>
- An <literal>OR</literal> using a single key is well optimized,
- as is the handling of <literal>AND</literal>.
+ An <function role="sqlop">OR</function> using a single key is
+ well optimized, as is the handling of
+ <function role="sqlop">AND</function>.
</para>
<para>
The one tricky case is that of searching on two different keys
- combined with <literal>OR</literal>:
+ combined with <function role="sqlop">OR</function>:
</para>
<programlisting>
Modified: trunk/refman-5.0/views.xml
===================================================================
--- trunk/refman-5.0/views.xml 2007-12-03 04:00:27 UTC (rev 9059)
+++ trunk/refman-5.0/views.xml 2007-12-03 04:00:46 UTC (rev 9060)
Changed blocks: 1, Lines Added: 4, Lines Deleted: 3; 916 bytes
@@ -700,9 +700,10 @@
that <literal>vc1 < 100</literal> becomes <literal>c1 <
100</literal> and the view <literal>WHERE</literal> clause is
added to the statement <literal>WHERE</literal> clause using an
- <literal>AND</literal> connective (and parentheses are added to
- make sure the parts of the clause are executed with correct
- precedence). The resulting statement to be executed becomes:
+ <function role="sqlop">AND</function> connective (and parentheses
+ are added to make sure the parts of the clause are executed with
+ correct precedence). The resulting statement to be executed
+ becomes:
</para>
<programlisting>
Modified: trunk/refman-5.1/ccsg-temp.xml
===================================================================
--- trunk/refman-5.1/ccsg-temp.xml 2007-12-03 04:00:27 UTC (rev 9059)
+++ trunk/refman-5.1/ccsg-temp.xml 2007-12-03 04:00:46 UTC (rev 9060)
Changed blocks: 3, Lines Added: 6, Lines Deleted: 6; 1859 bytes
@@ -22585,8 +22585,8 @@
together and applied as a whole. In other words, a
comparison for <emphasis>each</emphasis> column must be
present, and the comparisons must be combined using the
- <literal>AND</literal> logical operator. Consider the
- following query:
+ <function role="sqlop">AND</function> logical operator.
+ Consider the following query:
</para>
<programlisting>
@@ -22656,7 +22656,7 @@
<para>
These columns are combined in a manner that is
equivalent to a combination using only the
- <literal>AND</literal> operator
+ <function role="sqlop">AND</function> operator
</para>
</listitem>
@@ -22696,9 +22696,9 @@
query contains a condition that combines the
<literal>CountryCode</literal> and
<literal>District</literal> columns using the
- <literal>AND</literal> operator. These two columns
- constitute a prefix of the index that is used to implement
- the primary key constraint, because they appear
+ <function role="sqlop">AND</function> operator. These two
+ columns constitute a prefix of the index that is used to
+ implement the primary key constraint, because they appear
consecutively in the definition of the primary key and the
<literal>CountryCode</literal> column is indeed the first
column in the index definition.
Modified: trunk/refman-5.1/dba-core.xml
===================================================================
Changed blocks: 0, Lines Added: 0, Lines Deleted: 0; 106 bytes
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r9060 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-6.0 xsl.d | paul | 3 Dec |
