Author: paul
Date: 2006-02-19 00:31:31 +0100 (Sun, 19 Feb 2006)
New Revision: 1388
Log:
r7826@frost: paul | 2006-02-18 16:21:22 -0600
Cleanup edits.
Modified:
trunk/
trunk/refman-4.1/client-utility-programs.xml
trunk/refman-4.1/innodb.xml
trunk/refman-4.1/optimization.xml
trunk/refman-5.0/client-utility-programs.xml
trunk/refman-5.0/innodb.xml
trunk/refman-5.0/optimization.xml
trunk/refman-5.1/client-utility-programs.xml
trunk/refman-5.1/innodb.xml
trunk/refman-5.1/optimization.xml
trunk/refman-common/manual-conventions.en.xml
trunk/refman-common/news-4.1.xml
trunk/refman-common/news-5.0.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:7825
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:3223
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:7826
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:3223
Modified: trunk/refman-4.1/client-utility-programs.xml
===================================================================
--- trunk/refman-4.1/client-utility-programs.xml 2006-02-18 23:31:13 UTC (rev 1387)
+++ trunk/refman-4.1/client-utility-programs.xml 2006-02-18 23:31:31 UTC (rev 1388)
@@ -462,7 +462,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>myisamchk [<replaceable>options</replaceable>] <replaceable>tbl_name</replaceable> …</command>
+ <command>myisamchk [<replaceable>options</replaceable>] <replaceable>tbl_name</replaceable> ...</command>
</cmdsynopsis>
<cmdsynopsis>
@@ -2336,7 +2336,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>myisampack [<replaceable>options</replaceable>] <replaceable>file_name</replaceable> …</command>
+ <command>myisampack [<replaceable>options</replaceable>] <replaceable>file_name</replaceable> ...</command>
</cmdsynopsis>
<cmdsynopsis>
@@ -5953,7 +5953,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>mysqladmin [<replaceable>options</replaceable>] <replaceable>command</replaceable> [<replaceable>command-options</replaceable>] [<replaceable>command</replaceable> [<replaceable>command-options</replaceable>]] …</command>
+ <command>mysqladmin [<replaceable>options</replaceable>] <replaceable>command</replaceable> [<replaceable>command-options</replaceable>] [<replaceable>command</replaceable> [<replaceable>command-options</replaceable>]] ...</command>
</cmdsynopsis>
</refsynopsisdiv>
@@ -6092,7 +6092,7 @@
<listitem>
<para>
<literal>kill
- <replaceable>id</replaceable>,<replaceable>id</replaceable>,…</literal>
+ <replaceable>id</replaceable>,<replaceable>id</replaceable>,...</literal>
</para>
<para>
@@ -7009,7 +7009,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>mysqlbinlog [<literal>options</literal>] <replaceable>log_file</replaceable> …</command>
+ <command>mysqlbinlog [<literal>options</literal>] <replaceable>log_file</replaceable> ...</command>
</cmdsynopsis>
</refsynopsisdiv>
@@ -7911,7 +7911,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>mysqlcheck [<replaceable>options</replaceable>] [<replaceable>db_name</replaceable> [<replaceable>tbl_name</replaceable> …]]</command>
+ <command>mysqlcheck [<replaceable>options</replaceable>] [<replaceable>db_name</replaceable> [<replaceable>tbl_name</replaceable> ...]]</command>
</cmdsynopsis>
</refsynopsisdiv>
@@ -8755,7 +8755,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>mysqldump [<replaceable>options</replaceable>] [<replaceable>db_name</replaceable> [<replaceable>tbl_name</replaceable> …]]</command>
+ <command>mysqldump [<replaceable>options</replaceable>] [<replaceable>db_name</replaceable> [<replaceable>tbl_name</replaceable> ...]]</command>
</cmdsynopsis>
</refsynopsisdiv>
@@ -9361,11 +9361,11 @@
<listitem>
<para>
- <option>--fields-terminated-by=…</option>,
- <option>--fields-enclosed-by=…</option>,
- <option>--fields-optionally-enclosed-by=…</option>,
- <option>--fields-escaped-by=…</option>,
- <option>--lines-terminated-by=…</option>
+ <option>--fields-terminated-by=...</option>,
+ <option>--fields-enclosed-by=...</option>,
+ <option>--fields-optionally-enclosed-by=...</option>,
+ <option>--fields-escaped-by=...</option>,
+ <option>--lines-terminated-by=...</option>
</para>
<para>
@@ -11109,7 +11109,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>mysqlimport [<replaceable>options</replaceable>] <replaceable>db_name</replaceable> <replaceable>textfile1</replaceable> …</command>
+ <command>mysqlimport [<replaceable>options</replaceable>] <replaceable>db_name</replaceable> <replaceable>textfile1</replaceable> ...</command>
</cmdsynopsis>
</refsynopsisdiv>
@@ -11303,11 +11303,11 @@
<listitem>
<para>
- <option>--fields-terminated-by=…</option>,
- <option>--fields-enclosed-by=…</option>,
- <option>--fields-optionally-enclosed-by=…</option>,
- <option>--fields-escaped-by=…</option>,
- <option>--lines-terminated-by=…</option>
+ <option>--fields-terminated-by=...</option>,
+ <option>--fields-enclosed-by=...</option>,
+ <option>--fields-optionally-enclosed-by=...</option>,
+ <option>--fields-escaped-by=...</option>,
+ <option>--lines-terminated-by=...</option>
</para>
<para>
@@ -12368,7 +12368,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>perror [<replaceable>options</replaceable>] <replaceable>errorcode</replaceable> …</command>
+ <command>perror [<replaceable>options</replaceable>] <replaceable>errorcode</replaceable> ...</command>
</cmdsynopsis>
</refsynopsisdiv>
Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml 2006-02-18 23:31:13 UTC (rev 1387)
+++ trunk/refman-4.1/innodb.xml 2006-02-18 23:31:31 UTC (rev 1388)
@@ -2033,10 +2033,10 @@
afterward. The fastest way to alter a table to
<literal>InnoDB</literal> is to do the inserts directly to an
<literal>InnoDB</literal> table. That is, use <literal>ALTER
- TABLE … TYPE=INNODB</literal>, or create an empty
+ TABLE ... TYPE=INNODB</literal>, or create an empty
<literal>InnoDB</literal> table with identical definitions and
- insert the rows with <literal>INSERT INTO … SELECT * FROM
- …</literal>.
+ insert the rows with <literal>INSERT INTO ... SELECT * FROM
+ ...</literal>.
</para>
<para>
@@ -2636,9 +2636,9 @@
<para>
Starting from MySQL 3.23.50, the <literal>InnoDB</literal>
parser allows table and column identifiers in a <literal>FOREIGN
- KEY … REFERENCES …</literal> clause to be quoted
- within backticks. (Alternatively, double quotes can be used if
- the <literal>ANSI_QUOTES</literal> SQL mode is enabled.) The
+ KEY ... REFERENCES ...</literal> clause to be quoted within
+ backticks. (Alternatively, double quotes can be used if the
+ <literal>ANSI_QUOTES</literal> SQL mode is enabled.) The
<literal>InnoDB</literal> parser also takes into account the
setting of the <literal>lower_case_table_names</literal> system
variable.
@@ -3624,7 +3624,7 @@
<para>
Thus, intention locks do not block anything except full table
- requests (for example, <literal>LOCK TABLES …
+ requests (for example, <literal>LOCK TABLES ...
WRITE</literal>). The main purpose of
<replaceable>IX</replaceable> and <replaceable>IS</replaceable>
locks is to show that someone is locking a row, or going to lock
@@ -3868,10 +3868,10 @@
<para>
A somewhat Oracle-like isolation level. All <literal>SELECT
- … FOR UPDATE</literal> and <literal>SELECT …
- LOCK IN SHARE MODE</literal> statements lock only the index
- records, not the gaps before them, and thus allow the free
- insertion of new records next to locked records.
+ ... FOR UPDATE</literal> and <literal>SELECT ... LOCK IN
+ SHARE MODE</literal> statements lock only the index records,
+ not the gaps before them, and thus allow the free insertion
+ of new records next to locked records.
<literal>UPDATE</literal> and <literal>DELETE</literal>
statements using a unique index with a unique search
condition lock only the index record found, not the gap
@@ -3898,8 +3898,8 @@
<para>
This is the default isolation level of
- <literal>InnoDB</literal>. <literal>SELECT … FOR
- UPDATE</literal>, <literal>SELECT … LOCK IN SHARE
+ <literal>InnoDB</literal>. <literal>SELECT ... FOR
+ UPDATE</literal>, <literal>SELECT ... LOCK IN SHARE
MODE</literal>, <literal>UPDATE</literal>, and
<literal>DELETE</literal> statements that use a unique index
with a unique search condition lock only the index record
@@ -3930,8 +3930,8 @@
<para>
This level is like <literal>REPEATABLE READ</literal>, but
<literal>InnoDB</literal> implicitly commits all plain
- <literal>SELECT</literal> statements to <literal>SELECT
- … LOCK IN SHARE MODE</literal>.
+ <literal>SELECT</literal> statements to <literal>SELECT ...
+ LOCK IN SHARE MODE</literal>.
</para>
</listitem>
@@ -4066,7 +4066,7 @@
</programlisting>
<para>
- A <literal>SELECT … FOR UPDATE</literal> reads the latest
+ A <literal>SELECT ... FOR UPDATE</literal> reads the latest
available data, setting exclusive locks on each row it reads.
Thus, it sets the same locks a searched SQL
<literal>UPDATE</literal> would set on the rows.
@@ -4074,9 +4074,9 @@
<para>
The preceding description is merely an example of how
- <literal>SELECT … FOR UPDATE</literal> works. In MySQL,
- the specific task of generating a unique identifier actually can
- be accomplished using only a single access to the table:
+ <literal>SELECT ... FOR UPDATE</literal> works. In MySQL, the
+ specific task of generating a unique identifier actually can be
+ accomplished using only a single access to the table:
</para>
<programlisting>
@@ -4279,9 +4279,9 @@
<listitem>
<para>
- <literal>SELECT … FROM</literal> is a consistent
- read, reading a snapshot of the database and setting no
- locks unless the transaction isolation level is set to
+ <literal>SELECT ... FROM</literal> is a consistent read,
+ reading a snapshot of the database and setting no locks
+ unless the transaction isolation level is set to
<literal>SERIALIZABLE</literal>. For
<literal>SERIALIZABLE</literal> level, this sets shared
next-key locks on the index records it encounters.
@@ -4290,26 +4290,26 @@
<listitem>
<para>
- <literal>SELECT … FROM … LOCK IN SHARE
- MODE</literal> sets shared next-key locks on all index
- records the read encounters.
+ <literal>SELECT ... FROM ... LOCK IN SHARE MODE</literal>
+ sets shared next-key locks on all index records the read
+ encounters.
</para>
</listitem>
<listitem>
<para>
- <literal>SELECT … FROM … FOR UPDATE</literal>
- sets exclusive next-key locks on all index records the read
+ <literal>SELECT ... FROM ... FOR UPDATE</literal> sets
+ exclusive next-key locks on all index records the read
encounters.
</para>
</listitem>
<listitem>
<para>
- <literal>INSERT INTO … VALUES (…)</literal>
- sets an exclusive lock on the inserted row. Note that this
- lock is not a next-key lock and does not prevent other users
- from inserting to the gap before the inserted row. If a
+ <literal>INSERT INTO ... VALUES (...)</literal> sets an
+ exclusive lock on the inserted row. Note that this lock is
+ not a next-key lock and does not prevent other users from
+ inserting to the gap before the inserted row. If a
duplicate-key error occurs, a shared lock on the duplicate
index record is set.
</para>
@@ -4352,23 +4352,23 @@
</remark>
<para>
- <literal>INSERT INTO T SELECT … FROM S WHERE
- …</literal> sets an exclusive (non-next-key) lock on
- each row inserted into <literal>T</literal>. It does the
- search on <literal>S</literal> as a consistent read, but
- sets shared next-key locks on <literal>S</literal> if MySQL
- binary logging is turned on. <literal>InnoDB</literal> has
- to set locks in the latter case: In roll-forward recovery
- from a backup, every SQL statement has to be executed in
- exactly the same way it was done originally.
+ <literal>INSERT INTO T SELECT ... FROM S WHERE ...</literal>
+ sets an exclusive (non-next-key) lock on each row inserted
+ into <literal>T</literal>. It does the search on
+ <literal>S</literal> as a consistent read, but sets shared
+ next-key locks on <literal>S</literal> if MySQL binary
+ logging is turned on. <literal>InnoDB</literal> has to set
+ locks in the latter case: In roll-forward recovery from a
+ backup, every SQL statement has to be executed in exactly
+ the same way it was done originally.
</para>
</listitem>
<listitem>
<para>
- <literal>CREATE TABLE … SELECT …</literal>
- performs the <literal>SELECT</literal> as a consistent read
- or with shared locks, as in the previous item.
+ <literal>CREATE TABLE ... SELECT ...</literal> performs the
+ <literal>SELECT</literal> as a consistent read or with
+ shared locks, as in the previous item.
</para>
</listitem>
@@ -4382,16 +4382,15 @@
<listitem>
<para>
- <literal>UPDATE … WHERE …</literal> sets an
- exclusive next-key lock on every record the search
- encounters.
+ <literal>UPDATE ... WHERE ...</literal> sets an exclusive
+ next-key lock on every record the search encounters.
</para>
</listitem>
<listitem>
<para>
- <literal>DELETE FROM … WHERE …</literal> sets
- an exclusive next-key lock on every record the search
+ <literal>DELETE FROM ... WHERE ...</literal> sets an
+ exclusive next-key lock on every record the search
encounters.
</para>
</listitem>
@@ -4620,8 +4619,8 @@
<listitem>
<para>
- If you are using locking reads (<literal>SELECT … FOR
- UPDATE</literal> or <literal>… LOCK IN SHARE
+ If you are using locking reads (<literal>SELECT ... FOR
+ UPDATE</literal> or <literal>... LOCK IN SHARE
MODE</literal>), try using a lower isolation level such as
<literal>READ COMMITTED</literal>.
</para>
Modified: trunk/refman-4.1/optimization.xml
===================================================================
--- trunk/refman-4.1/optimization.xml 2006-02-18 23:31:13 UTC (rev 1387)
+++ trunk/refman-4.1/optimization.xml 2006-02-18 23:31:31 UTC (rev 1388)
@@ -1807,12 +1807,12 @@
</indexterm>
<para>
- In general, when you want to make a slow <literal>SELECT
- … WHERE</literal> query faster, the first thing to check
- is whether you can add an index. All references between
- different tables should usually be done with indexes. You can
- use the <literal>EXPLAIN</literal> statement to determine which
- indexes are used for a <literal>SELECT</literal>. See
+ In general, when you want to make a slow <literal>SELECT ...
+ WHERE</literal> query faster, the first thing to check is
+ whether you can add an index. All references between different
+ tables should usually be done with indexes. You can use the
+ <literal>EXPLAIN</literal> statement to determine which indexes
+ are used for a <literal>SELECT</literal>. See
<xref linkend="explain"/>, and <xref linkend="mysql-indexes"/>.
</para>
@@ -3049,8 +3049,8 @@
</itemizedlist>
<para>
- With <literal>EXPLAIN SELECT … ORDER BY</literal>, you
- can check whether MySQL can use indexes to resolve the query. It
+ With <literal>EXPLAIN SELECT ... ORDER BY</literal>, you can
+ check whether MySQL can use indexes to resolve the query. It
cannot if you see <literal>Using filesort</literal> in the
<literal>Extra</literal> column. See <xref linkend="explain"/>.
</para>
@@ -3263,11 +3263,10 @@
By default, MySQL sorts all <literal>GROUP BY
<replaceable>col1</replaceable>,
- <replaceable>col2</replaceable>, …</literal> queries as
- if you specified <literal>ORDER BY
- <replaceable>col1</replaceable>,
- <replaceable>col2</replaceable>, …</literal> in the query
- as well. If you include an <literal>ORDER BY</literal> clause
+ <replaceable>col2</replaceable>, ...</literal> queries as if you
+ specified <literal>ORDER BY <replaceable>col1</replaceable>,
+ <replaceable>col2</replaceable>, ...</literal> in the query as
+ well. If you include an <literal>ORDER BY</literal> clause
explicitly that contains the same column list, MySQL optimizes
it away without any speed penalty, although the sorting still
occurs. If a query includes <literal>GROUP BY</literal> but you
@@ -4061,14 +4060,14 @@
<listitem>
<para>
- Use <literal>ALTER TABLE … ORDER BY
+ Use <literal>ALTER TABLE ... ORDER BY
<replaceable>expr1</replaceable>,
- <replaceable>expr2</replaceable>, …</literal> if you
+ <replaceable>expr2</replaceable>, ...</literal> if you
usually retrieve rows in
<literal><replaceable>expr1</replaceable>,
- <replaceable>expr2</replaceable>, …</literal> order.
- By using this option after extensive changes to the table,
- you may be able to get higher performance.
+ <replaceable>expr2</replaceable>, ...</literal> order. By
+ using this option after extensive changes to the table, you
+ may be able to get higher performance.
</para>
</listitem>
@@ -5700,9 +5699,8 @@
<para>
MySQL 4.0 and later versions perform an additional
- <literal>LIKE</literal> optimization. If you use
- <literal>… LIKE
- '%<replaceable>string</replaceable>%'</literal> and
+ <literal>LIKE</literal> optimization. If you use <literal>...
+ LIKE '%<replaceable>string</replaceable>%'</literal> and
<replaceable>string</replaceable> is longer than three
characters, MySQL uses the <firstterm>Turbo Boyer-Moore
algorithm</firstterm> to initialize the pattern for the string
@@ -8246,7 +8244,7 @@
</remark>
<para>
- If you rename a table with <literal>ALTER TABLE …
+ If you rename a table with <literal>ALTER TABLE ...
RENAME</literal> and you do not move the table to another
database, the symlinks in the database directory are
renamed to the new names and the data file and index file
@@ -8260,8 +8258,8 @@
</remark>
<para>
- If you use <literal>ALTER TABLE … RENAME</literal>
- to move a table to another database, the table is moved to
+ If you use <literal>ALTER TABLE ... RENAME</literal> to
+ move a table to another database, the table is moved to
the other database directory. The old symlinks and the
files to which they pointed are deleted. In other words,
the new table is not symlinked.
Modified: trunk/refman-5.0/client-utility-programs.xml
===================================================================
--- trunk/refman-5.0/client-utility-programs.xml 2006-02-18 23:31:13 UTC (rev 1387)
+++ trunk/refman-5.0/client-utility-programs.xml 2006-02-18 23:31:31 UTC (rev 1388)
@@ -438,7 +438,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>myisamchk [<replaceable>options</replaceable>] <replaceable>tbl_name</replaceable> …</command>
+ <command>myisamchk [<replaceable>options</replaceable>] <replaceable>tbl_name</replaceable> ...</command>
</cmdsynopsis>
</refsynopsisdiv>
@@ -2211,7 +2211,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>myisampack [<replaceable>options</replaceable>] <replaceable>file_name</replaceable> …</command>
+ <command>myisampack [<replaceable>options</replaceable>] <replaceable>file_name</replaceable> ...</command>
</cmdsynopsis>
</refsynopsisdiv>
@@ -5821,7 +5821,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>mysqladmin [<replaceable>options</replaceable>] <replaceable>command</replaceable> [<replaceable>command-options</replaceable>] [<replaceable>command</replaceable> [<replaceable>command-options</replaceable>]] …</command>
+ <command>mysqladmin [<replaceable>options</replaceable>] <replaceable>command</replaceable> [<replaceable>command-options</replaceable>] [<replaceable>command</replaceable> [<replaceable>command-options</replaceable>]] ...</command>
</cmdsynopsis>
</refsynopsisdiv>
@@ -5960,7 +5960,7 @@
<listitem>
<para>
<literal>kill
- <replaceable>id</replaceable>,<replaceable>id</replaceable>,…</literal>
+ <replaceable>id</replaceable>,<replaceable>id</replaceable>,...</literal>
</para>
<para>
@@ -6875,7 +6875,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>mysqlbinlog [<literal>options</literal>] <replaceable>log_file</replaceable> …</command>
+ <command>mysqlbinlog [<literal>options</literal>] <replaceable>log_file</replaceable> ...</command>
</cmdsynopsis>
</refsynopsisdiv>
@@ -8066,7 +8066,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>mysqlcheck [<replaceable>options</replaceable>] [<replaceable>db_name</replaceable> [<replaceable>tbl_name</replaceable> …]]</command>
+ <command>mysqlcheck [<replaceable>options</replaceable>] [<replaceable>db_name</replaceable> [<replaceable>tbl_name</replaceable> ...]]</command>
</cmdsynopsis>
</refsynopsisdiv>
@@ -8930,7 +8930,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>mysqldump [<replaceable>options</replaceable>] [<replaceable>db_name</replaceable> [<replaceable>tbl_name</replaceable> …]]</command>
+ <command>mysqldump [<replaceable>options</replaceable>] [<replaceable>db_name</replaceable> [<replaceable>tbl_name</replaceable> ...]]</command>
</cmdsynopsis>
</refsynopsisdiv>
@@ -9477,11 +9477,11 @@
<listitem>
<para>
- <option>--fields-terminated-by=…</option>,
- <option>--fields-enclosed-by=…</option>,
- <option>--fields-optionally-enclosed-by=…</option>,
- <option>--fields-escaped-by=…</option>,
- <option>--lines-terminated-by=…</option>
+ <option>--fields-terminated-by=...</option>,
+ <option>--fields-enclosed-by=...</option>,
+ <option>--fields-optionally-enclosed-by=...</option>,
+ <option>--fields-escaped-by=...</option>,
+ <option>--lines-terminated-by=...</option>
</para>
<para>
@@ -11314,7 +11314,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>mysqlimport [<replaceable>options</replaceable>] <replaceable>db_name</replaceable> <replaceable>textfile1</replaceable> …</command>
+ <command>mysqlimport [<replaceable>options</replaceable>] <replaceable>db_name</replaceable> <replaceable>textfile1</replaceable> ...</command>
</cmdsynopsis>
</refsynopsisdiv>
@@ -11508,11 +11508,11 @@
<listitem>
<para>
- <option>--fields-terminated-by=…</option>,
- <option>--fields-enclosed-by=…</option>,
- <option>--fields-optionally-enclosed-by=…</option>,
- <option>--fields-escaped-by=…</option>,
- <option>--lines-terminated-by=…</option>
+ <option>--fields-terminated-by=...</option>,
+ <option>--fields-enclosed-by=...</option>,
+ <option>--fields-optionally-enclosed-by=...</option>,
+ <option>--fields-escaped-by=...</option>,
+ <option>--lines-terminated-by=...</option>
</para>
<para>
@@ -12612,7 +12612,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>perror [<replaceable>options</replaceable>] <replaceable>errorcode</replaceable> …</command>
+ <command>perror [<replaceable>options</replaceable>] <replaceable>errorcode</replaceable> ...</command>
</cmdsynopsis>
</refsynopsisdiv>
Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml 2006-02-18 23:31:13 UTC (rev 1387)
+++ trunk/refman-5.0/innodb.xml 2006-02-18 23:31:31 UTC (rev 1388)
@@ -2080,10 +2080,10 @@
afterward. The fastest way to alter a table to
<literal>InnoDB</literal> is to do the inserts directly to an
<literal>InnoDB</literal> table. That is, use <literal>ALTER
- TABLE … ENGINE=INNODB</literal>, or create an empty
+ TABLE ... ENGINE=INNODB</literal>, or create an empty
<literal>InnoDB</literal> table with identical definitions and
- insert the rows with <literal>INSERT INTO … SELECT * FROM
- …</literal>.
+ insert the rows with <literal>INSERT INTO ... SELECT * FROM
+ ...</literal>.
</para>
<para>
@@ -2673,8 +2673,8 @@
<para>
The <literal>InnoDB</literal> parser allows table and column
- identifiers in a <literal>FOREIGN KEY … REFERENCES
- …</literal> clause to be quoted within backticks.
+ identifiers in a <literal>FOREIGN KEY ... REFERENCES
+ ...</literal> clause to be quoted within backticks.
(Alternatively, double quotes can be used if the
<literal>ANSI_QUOTES</literal> SQL mode is enabled.) The
<literal>InnoDB</literal> parser also takes into account the
@@ -3590,7 +3590,7 @@
<para>
Thus, intention locks do not block anything except full table
- requests (for example, <literal>LOCK TABLES …
+ requests (for example, <literal>LOCK TABLES ...
WRITE</literal>). The main purpose of
<replaceable>IX</replaceable> and <replaceable>IS</replaceable>
locks is to show that someone is locking a row, or going to lock
@@ -3826,10 +3826,10 @@
<para>
A somewhat Oracle-like isolation level. All <literal>SELECT
- … FOR UPDATE</literal> and <literal>SELECT …
- LOCK IN SHARE MODE</literal> statements lock only the index
- records, not the gaps before them, and thus allow the free
- insertion of new records next to locked records.
+ ... FOR UPDATE</literal> and <literal>SELECT ... LOCK IN
+ SHARE MODE</literal> statements lock only the index records,
+ not the gaps before them, and thus allow the free insertion
+ of new records next to locked records.
<literal>UPDATE</literal> and <literal>DELETE</literal>
statements using a unique index with a unique search
condition lock only the index record found, not the gap
@@ -3856,8 +3856,8 @@
<para>
This is the default isolation level of
- <literal>InnoDB</literal>. <literal>SELECT … FOR
- UPDATE</literal>, <literal>SELECT … LOCK IN SHARE
+ <literal>InnoDB</literal>. <literal>SELECT ... FOR
+ UPDATE</literal>, <literal>SELECT ... LOCK IN SHARE
MODE</literal>, <literal>UPDATE</literal>, and
<literal>DELETE</literal> statements that use a unique index
with a unique search condition lock only the index record
@@ -3888,8 +3888,8 @@
<para>
This level is like <literal>REPEATABLE READ</literal>, but
<literal>InnoDB</literal> implicitly commits all plain
- <literal>SELECT</literal> statements to <literal>SELECT
- … LOCK IN SHARE MODE</literal>.
+ <literal>SELECT</literal> statements to <literal>SELECT ...
+ LOCK IN SHARE MODE</literal>.
</para>
</listitem>
@@ -4024,7 +4024,7 @@
</programlisting>
<para>
- A <literal>SELECT … FOR UPDATE</literal> reads the latest
+ A <literal>SELECT ... FOR UPDATE</literal> reads the latest
available data, setting exclusive locks on each row it reads.
Thus, it sets the same locks a searched SQL
<literal>UPDATE</literal> would set on the rows.
@@ -4032,9 +4032,9 @@
<para>
The preceding description is merely an example of how
- <literal>SELECT … FOR UPDATE</literal> works. In MySQL,
- the specific task of generating a unique identifier actually can
- be accomplished using only a single access to the table:
+ <literal>SELECT ... FOR UPDATE</literal> works. In MySQL, the
+ specific task of generating a unique identifier actually can be
+ accomplished using only a single access to the table:
</para>
<programlisting>
@@ -4237,9 +4237,9 @@
<listitem>
<para>
- <literal>SELECT … FROM</literal> is a consistent
- read, reading a snapshot of the database and setting no
- locks unless the transaction isolation level is set to
+ <literal>SELECT ... FROM</literal> is a consistent read,
+ reading a snapshot of the database and setting no locks
+ unless the transaction isolation level is set to
<literal>SERIALIZABLE</literal>. For
<literal>SERIALIZABLE</literal> level, this sets shared
next-key locks on the index records it encounters.
@@ -4248,26 +4248,26 @@
<listitem>
<para>
- <literal>SELECT … FROM … LOCK IN SHARE
- MODE</literal> sets shared next-key locks on all index
- records the read encounters.
+ <literal>SELECT ... FROM ... LOCK IN SHARE MODE</literal>
+ sets shared next-key locks on all index records the read
+ encounters.
</para>
</listitem>
<listitem>
<para>
- <literal>SELECT … FROM … FOR UPDATE</literal>
- sets exclusive next-key locks on all index records the read
+ <literal>SELECT ... FROM ... FOR UPDATE</literal> sets
+ exclusive next-key locks on all index records the read
encounters.
</para>
</listitem>
<listitem>
<para>
- <literal>INSERT INTO … VALUES (…)</literal>
- sets an exclusive lock on the inserted row. Note that this
- lock is not a next-key lock and does not prevent other users
- from inserting to the gap before the inserted row. If a
+ <literal>INSERT INTO ... VALUES (...)</literal> sets an
+ exclusive lock on the inserted row. Note that this lock is
+ not a next-key lock and does not prevent other users from
+ inserting to the gap before the inserted row. If a
duplicate-key error occurs, a shared lock on the duplicate
index record is set.
</para>
@@ -4298,11 +4298,10 @@
<listitem>
<para>
- <literal>INSERT INTO T SELECT … FROM S WHERE
- …</literal> sets an exclusive (non-next-key) lock on
- each row inserted into <literal>T</literal>.
- <literal>InnoDB</literal> sets shared next-key locks locks
- on <literal>S</literal>, unless
+ <literal>INSERT INTO T SELECT ... FROM S WHERE ...</literal>
+ sets an exclusive (non-next-key) lock on each row inserted
+ into <literal>T</literal>. <literal>InnoDB</literal> sets
+ shared next-key locks locks on <literal>S</literal>, unless
<literal>innodb_locks_unsafe_for_binlog</literal> is
enabled, in which case it does the search on
<literal>S</literal> as a consistent read.
@@ -4315,9 +4314,9 @@
<listitem>
<para>
- <literal>CREATE TABLE … SELECT …</literal>
- performs the <literal>SELECT</literal> as a consistent read
- or with shared locks, as in the previous item.
+ <literal>CREATE TABLE ... SELECT ...</literal> performs the
+ <literal>SELECT</literal> as a consistent read or with
+ shared locks, as in the previous item.
</para>
</listitem>
@@ -4331,16 +4330,15 @@
<listitem>
<para>
- <literal>UPDATE … WHERE …</literal> sets an
- exclusive next-key lock on every record the search
- encounters.
+ <literal>UPDATE ... WHERE ...</literal> sets an exclusive
+ next-key lock on every record the search encounters.
</para>
</listitem>
<listitem>
<para>
- <literal>DELETE FROM … WHERE …</literal> sets
- an exclusive next-key lock on every record the search
+ <literal>DELETE FROM ... WHERE ...</literal> sets an
+ exclusive next-key lock on every record the search
encounters.
</para>
</listitem>
@@ -4570,8 +4568,8 @@
<listitem>
<para>
- If you are using locking reads (<literal>SELECT … FOR
- UPDATE</literal> or <literal>… LOCK IN SHARE
+ If you are using locking reads (<literal>SELECT ... FOR
+ UPDATE</literal> or <literal>... LOCK IN SHARE
MODE</literal>), try using a lower isolation level such as
<literal>READ COMMITTED</literal>.
</para>
Modified: trunk/refman-5.0/optimization.xml
===================================================================
--- trunk/refman-5.0/optimization.xml 2006-02-18 23:31:13 UTC (rev 1387)
+++ trunk/refman-5.0/optimization.xml 2006-02-18 23:31:31 UTC (rev 1388)
@@ -1426,9 +1426,9 @@
<listitem>
<para>
- <literal>Using sort_union(…)</literal>,
- <literal>Using union(…)</literal>, <literal>Using
- intersect(…)</literal>
+ <literal>Using sort_union(...)</literal>, <literal>Using
+ union(...)</literal>, <literal>Using
+ intersect(...)</literal>
</para>
<para>
@@ -1975,12 +1975,12 @@
</indexterm>
<para>
- In general, when you want to make a slow <literal>SELECT
- … WHERE</literal> query faster, the first thing to check
- is whether you can add an index. All references between
- different tables should usually be done with indexes. You can
- use the <literal>EXPLAIN</literal> statement to determine which
- indexes are used for a <literal>SELECT</literal>. See
+ In general, when you want to make a slow <literal>SELECT ...
+ WHERE</literal> query faster, the first thing to check is
+ whether you can add an index. All references between different
+ tables should usually be done with indexes. You can use the
+ <literal>EXPLAIN</literal> statement to determine which indexes
+ are used for a <literal>SELECT</literal>. See
<xref linkend="explain"/>, and <xref linkend="mysql-indexes"/>.
</para>
@@ -2848,19 +2848,19 @@
<listitem>
<para>
- <literal>Using intersect(…)</literal>
+ <literal>Using intersect(...)</literal>
</para>
</listitem>
<listitem>
<para>
- <literal>Using union(…)</literal>
+ <literal>Using union(...)</literal>
</para>
</listitem>
<listitem>
<para>
- <literal>Using sort_union(…)</literal>
+ <literal>Using sort_union(...)</literal>
</para>
</listitem>
@@ -4461,8 +4461,8 @@
</itemizedlist>
<para>
- With <literal>EXPLAIN SELECT … ORDER BY</literal>, you
- can check whether MySQL can use indexes to resolve the query. It
+ With <literal>EXPLAIN SELECT ... ORDER BY</literal>, you can
+ check whether MySQL can use indexes to resolve the query. It
cannot if you see <literal>Using filesort</literal> in the
<literal>Extra</literal> column. See <xref linkend="explain"/>.
</para>
@@ -4589,11 +4589,10 @@
By default, MySQL sorts all <literal>GROUP BY
<replaceable>col1</replaceable>,
- <replaceable>col2</replaceable>, …</literal> queries as
- if you specified <literal>ORDER BY
- <replaceable>col1</replaceable>,
- <replaceable>col2</replaceable>, …</literal> in the query
- as well. If you include an <literal>ORDER BY</literal> clause
+ <replaceable>col2</replaceable>, ...</literal> queries as if you
+ specified <literal>ORDER BY <replaceable>col1</replaceable>,
+ <replaceable>col2</replaceable>, ...</literal> in the query as
+ well. If you include an <literal>ORDER BY</literal> clause
explicitly that contains the same column list, MySQL optimizes
it away without any speed penalty, although the sorting still
occurs. If a query includes <literal>GROUP BY</literal> but you
@@ -5519,14 +5518,14 @@
<listitem>
<para>
- Use <literal>ALTER TABLE … ORDER BY
+ Use <literal>ALTER TABLE ... ORDER BY
<replaceable>expr1</replaceable>,
- <replaceable>expr2</replaceable>, …</literal> if you
+ <replaceable>expr2</replaceable>, ...</literal> if you
usually retrieve rows in
<literal><replaceable>expr1</replaceable>,
- <replaceable>expr2</replaceable>, …</literal> order.
- By using this option after extensive changes to the table,
- you may be able to get higher performance.
+ <replaceable>expr2</replaceable>, ...</literal> order. By
+ using this option after extensive changes to the table, you
+ may be able to get higher performance.
</para>
</listitem>
@@ -7191,7 +7190,7 @@
</para>
<para>
- If you use <literal>… LIKE
+ If you use <literal>... LIKE
'%<replaceable>string</replaceable>%'</literal> and
<replaceable>string</replaceable> is longer than three
characters, MySQL uses the <firstterm>Turbo Boyer-Moore
@@ -9793,7 +9792,7 @@
</remark>
<para>
- If you rename a table with <literal>ALTER TABLE …
+ If you rename a table with <literal>ALTER TABLE ...
RENAME</literal> and you do not move the table to another
database, the symlinks in the database directory are
renamed to the new names and the data file and index file
@@ -9807,8 +9806,8 @@
</remark>
<para>
- If you use <literal>ALTER TABLE … RENAME</literal>
- to move a table to another database, the table is moved to
+ If you use <literal>ALTER TABLE ... RENAME</literal> to
+ move a table to another database, the table is moved to
the other database directory. The old symlinks and the
files to which they pointed are deleted. In other words,
the new table is not symlinked.
Modified: trunk/refman-5.1/client-utility-programs.xml
===================================================================
--- trunk/refman-5.1/client-utility-programs.xml 2006-02-18 23:31:13 UTC (rev 1387)
+++ trunk/refman-5.1/client-utility-programs.xml 2006-02-18 23:31:31 UTC (rev 1388)
@@ -454,7 +454,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>myisamchk [<replaceable>options</replaceable>] <replaceable>tbl_name</replaceable> …</command>
+ <command>myisamchk [<replaceable>options</replaceable>] <replaceable>tbl_name</replaceable> ...</command>
</cmdsynopsis>
</refsynopsisdiv>
@@ -2212,7 +2212,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>myisampack [<replaceable>options</replaceable>] <replaceable>file_name</replaceable> …</command>
+ <command>myisampack [<replaceable>options</replaceable>] <replaceable>file_name</replaceable> ...</command>
</cmdsynopsis>
</refsynopsisdiv>
@@ -5822,7 +5822,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>mysqladmin [<replaceable>options</replaceable>] <replaceable>command</replaceable> [<replaceable>command-options</replaceable>] [<replaceable>command</replaceable> [<replaceable>command-options</replaceable>]] …</command>
+ <command>mysqladmin [<replaceable>options</replaceable>] <replaceable>command</replaceable> [<replaceable>command-options</replaceable>] [<replaceable>command</replaceable> [<replaceable>command-options</replaceable>]] ...</command>
</cmdsynopsis>
</refsynopsisdiv>
@@ -5961,7 +5961,7 @@
<listitem>
<para>
<literal>kill
- <replaceable>id</replaceable>,<replaceable>id</replaceable>,…</literal>
+ <replaceable>id</replaceable>,<replaceable>id</replaceable>,...</literal>
</para>
<para>
@@ -6876,7 +6876,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>mysqlbinlog [<literal>options</literal>] <replaceable>log_file</replaceable> …</command>
+ <command>mysqlbinlog [<literal>options</literal>] <replaceable>log_file</replaceable> ...</command>
</cmdsynopsis>
</refsynopsisdiv>
@@ -8112,7 +8112,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>mysqlcheck [<replaceable>options</replaceable>] [<replaceable>db_name</replaceable> [<replaceable>tbl_name</replaceable> …]]</command>
+ <command>mysqlcheck [<replaceable>options</replaceable>] [<replaceable>db_name</replaceable> [<replaceable>tbl_name</replaceable> ...]]</command>
</cmdsynopsis>
</refsynopsisdiv>
@@ -9023,7 +9023,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>mysqldump [<replaceable>options</replaceable>] [<replaceable>db_name</replaceable> [<replaceable>tbl_name</replaceable> …]]</command>
+ <command>mysqldump [<replaceable>options</replaceable>] [<replaceable>db_name</replaceable> [<replaceable>tbl_name</replaceable> ...]]</command>
</cmdsynopsis>
</refsynopsisdiv>
@@ -9598,11 +9598,11 @@
<listitem>
<para>
- <option>--fields-terminated-by=…</option>,
- <option>--fields-enclosed-by=…</option>,
- <option>--fields-optionally-enclosed-by=…</option>,
- <option>--fields-escaped-by=…</option>,
- <option>--lines-terminated-by=…</option>
+ <option>--fields-terminated-by=...</option>,
+ <option>--fields-enclosed-by=...</option>,
+ <option>--fields-optionally-enclosed-by=...</option>,
+ <option>--fields-escaped-by=...</option>,
+ <option>--lines-terminated-by=...</option>
</para>
<para>
@@ -11455,7 +11455,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>mysqlimport [<replaceable>options</replaceable>] <replaceable>db_name</replaceable> <replaceable>textfile1</replaceable> …</command>
+ <command>mysqlimport [<replaceable>options</replaceable>] <replaceable>db_name</replaceable> <replaceable>textfile1</replaceable> ...</command>
</cmdsynopsis>
</refsynopsisdiv>
@@ -11649,11 +11649,11 @@
<listitem>
<para>
- <option>--fields-terminated-by=…</option>,
- <option>--fields-enclosed-by=…</option>,
- <option>--fields-optionally-enclosed-by=…</option>,
- <option>--fields-escaped-by=…</option>,
- <option>--lines-terminated-by=…</option>
+ <option>--fields-terminated-by=...</option>,
+ <option>--fields-enclosed-by=...</option>,
+ <option>--fields-optionally-enclosed-by=...</option>,
+ <option>--fields-escaped-by=...</option>,
+ <option>--lines-terminated-by=...</option>
</para>
<para>
@@ -13523,7 +13523,7 @@
<refsynopsisdiv>
<cmdsynopsis>
- <command>perror [<replaceable>options</replaceable>] <replaceable>errorcode</replaceable> …</command>
+ <command>perror [<replaceable>options</replaceable>] <replaceable>errorcode</replaceable> ...</command>
</cmdsynopsis>
</refsynopsisdiv>
Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml 2006-02-18 23:31:13 UTC (rev 1387)
+++ trunk/refman-5.1/innodb.xml 2006-02-18 23:31:31 UTC (rev 1388)
@@ -2056,10 +2056,10 @@
afterward. The fastest way to alter a table to
<literal>InnoDB</literal> is to do the inserts directly to an
<literal>InnoDB</literal> table. That is, use <literal>ALTER
- TABLE … ENGINE=INNODB</literal>, or create an empty
+ TABLE ... ENGINE=INNODB</literal>, or create an empty
<literal>InnoDB</literal> table with identical definitions and
- insert the rows with <literal>INSERT INTO … SELECT * FROM
- …</literal>.
+ insert the rows with <literal>INSERT INTO ... SELECT * FROM
+ ...</literal>.
</para>
<para>
@@ -2648,8 +2648,8 @@
<para>
The <literal>InnoDB</literal> parser allows table and column
- identifiers in a <literal>FOREIGN KEY … REFERENCES
- …</literal> clause to be quoted within backticks.
+ identifiers in a <literal>FOREIGN KEY ... REFERENCES
+ ...</literal> clause to be quoted within backticks.
(Alternatively, double quotes can be used if the
<literal>ANSI_QUOTES</literal> SQL mode is enabled.) The
<literal>InnoDB</literal> parser also takes into account the
@@ -3565,7 +3565,7 @@
<para>
Thus, intention locks do not block anything except full table
- requests (for example, <literal>LOCK TABLES …
+ requests (for example, <literal>LOCK TABLES ...
WRITE</literal>). The main purpose of
<replaceable>IX</replaceable> and <replaceable>IS</replaceable>
locks is to show that someone is locking a row, or going to lock
@@ -3801,10 +3801,10 @@
<para>
A somewhat Oracle-like isolation level. All <literal>SELECT
- … FOR UPDATE</literal> and <literal>SELECT …
- LOCK IN SHARE MODE</literal> statements lock only the index
- records, not the gaps before them, and thus allow the free
- insertion of new records next to locked records.
+ ... FOR UPDATE</literal> and <literal>SELECT ... LOCK IN
+ SHARE MODE</literal> statements lock only the index records,
+ not the gaps before them, and thus allow the free insertion
+ of new records next to locked records.
<literal>UPDATE</literal> and <literal>DELETE</literal>
statements using a unique index with a unique search
condition lock only the index record found, not the gap
@@ -3831,8 +3831,8 @@
<para>
This is the default isolation level of
- <literal>InnoDB</literal>. <literal>SELECT … FOR
- UPDATE</literal>, <literal>SELECT … LOCK IN SHARE
+ <literal>InnoDB</literal>. <literal>SELECT ... FOR
+ UPDATE</literal>, <literal>SELECT ... LOCK IN SHARE
MODE</literal>, <literal>UPDATE</literal>, and
<literal>DELETE</literal> statements that use a unique index
with a unique search condition lock only the index record
@@ -3863,8 +3863,8 @@
<para>
This level is like <literal>REPEATABLE READ</literal>, but
<literal>InnoDB</literal> implicitly commits all plain
- <literal>SELECT</literal> statements to <literal>SELECT
- … LOCK IN SHARE MODE</literal>.
+ <literal>SELECT</literal> statements to <literal>SELECT ...
+ LOCK IN SHARE MODE</literal>.
</para>
</listitem>
@@ -3999,7 +3999,7 @@
</programlisting>
<para>
- A <literal>SELECT … FOR UPDATE</literal> reads the latest
+ A <literal>SELECT ... FOR UPDATE</literal> reads the latest
available data, setting exclusive locks on each row it reads.
Thus, it sets the same locks a searched SQL
<literal>UPDATE</literal> would set on the rows.
@@ -4007,9 +4007,9 @@
<para>
The preceding description is merely an example of how
- <literal>SELECT … FOR UPDATE</literal> works. In MySQL,
- the specific task of generating a unique identifier actually can
- be accomplished using only a single access to the table:
+ <literal>SELECT ... FOR UPDATE</literal> works. In MySQL, the
+ specific task of generating a unique identifier actually can be
+ accomplished using only a single access to the table:
</para>
<programlisting>
@@ -4212,9 +4212,9 @@
<listitem>
<para>
- <literal>SELECT … FROM</literal> is a consistent
- read, reading a snapshot of the database and setting no
- locks unless the transaction isolation level is set to
+ <literal>SELECT ... FROM</literal> is a consistent read,
+ reading a snapshot of the database and setting no locks
+ unless the transaction isolation level is set to
<literal>SERIALIZABLE</literal>. For
<literal>SERIALIZABLE</literal> level, this sets shared
next-key locks on the index records it encounters.
@@ -4223,26 +4223,26 @@
<listitem>
<para>
- <literal>SELECT … FROM … LOCK IN SHARE
- MODE</literal> sets shared next-key locks on all index
- records the read encounters.
+ <literal>SELECT ... FROM ... LOCK IN SHARE MODE</literal>
+ sets shared next-key locks on all index records the read
+ encounters.
</para>
</listitem>
<listitem>
<para>
- <literal>SELECT … FROM … FOR UPDATE</literal>
- sets exclusive next-key locks on all index records the read
+ <literal>SELECT ... FROM ... FOR UPDATE</literal> sets
+ exclusive next-key locks on all index records the read
encounters.
</para>
</listitem>
<listitem>
<para>
- <literal>INSERT INTO … VALUES (…)</literal>
- sets an exclusive lock on the inserted row. Note that this
- lock is not a next-key lock and does not prevent other users
- from inserting to the gap before the inserted row. If a
+ <literal>INSERT INTO ... VALUES (...)</literal> sets an
+ exclusive lock on the inserted row. Note that this lock is
+ not a next-key lock and does not prevent other users from
+ inserting to the gap before the inserted row. If a
duplicate-key error occurs, a shared lock on the duplicate
index record is set.
</para>
@@ -4273,11 +4273,10 @@
<listitem>
<para>
- <literal>INSERT INTO T SELECT … FROM S WHERE
- …</literal> sets an exclusive (non-next-key) lock on
- each row inserted into <literal>T</literal>.
- <literal>InnoDB</literal> sets shared next-key locks locks
- on <literal>S</literal>, unless
+ <literal>INSERT INTO T SELECT ... FROM S WHERE ...</literal>
+ sets an exclusive (non-next-key) lock on each row inserted
+ into <literal>T</literal>. <literal>InnoDB</literal> sets
+ shared next-key locks locks on <literal>S</literal>, unless
<literal>innodb_locks_unsafe_for_binlog</literal> is
enabled, in which case it does the search on
<literal>S</literal> as a consistent read.
@@ -4290,9 +4289,9 @@
<listitem>
<para>
- <literal>CREATE TABLE … SELECT …</literal>
- performs the <literal>SELECT</literal> as a consistent read
- or with shared locks, as in the previous item.
+ <literal>CREATE TABLE ... SELECT ...</literal> performs the
+ <literal>SELECT</literal> as a consistent read or with
+ shared locks, as in the previous item.
</para>
</listitem>
@@ -4306,16 +4305,15 @@
<listitem>
<para>
- <literal>UPDATE … WHERE …</literal> sets an
- exclusive next-key lock on every record the search
- encounters.
+ <literal>UPDATE ... WHERE ...</literal> sets an exclusive
+ next-key lock on every record the search encounters.
</para>
</listitem>
<listitem>
<para>
- <literal>DELETE FROM … WHERE …</literal> sets
- an exclusive next-key lock on every record the search
+ <literal>DELETE FROM ... WHERE ...</literal> sets an
+ exclusive next-key lock on every record the search
encounters.
</para>
</listitem>
@@ -4530,8 +4528,8 @@
<listitem>
<para>
- If you are using locking reads (<literal>SELECT … FOR
- UPDATE</literal> or <literal>… LOCK IN SHARE
+ If you are using locking reads (<literal>SELECT ... FOR
+ UPDATE</literal> or <literal>... LOCK IN SHARE
MODE</literal>), try using a lower isolation level such as
<literal>READ COMMITTED</literal>.
</para>
Modified: trunk/refman-5.1/optimization.xml
===================================================================
--- trunk/refman-5.1/optimization.xml 2006-02-18 23:31:13 UTC (rev 1387)
+++ trunk/refman-5.1/optimization.xml 2006-02-18 23:31:31 UTC (rev 1388)
@@ -1464,9 +1464,9 @@
<listitem>
<para>
- <literal>Using sort_union(…)</literal>,
- <literal>Using union(…)</literal>, <literal>Using
- intersect(…)</literal>
+ <literal>Using sort_union(...)</literal>, <literal>Using
+ union(...)</literal>, <literal>Using
+ intersect(...)</literal>
</para>
<para>
@@ -2006,12 +2006,12 @@
</indexterm>
<para>
- In general, when you want to make a slow <literal>SELECT
- … WHERE</literal> query faster, the first thing to check
- is whether you can add an index. All references between
- different tables should usually be done with indexes. You can
- use the <literal>EXPLAIN</literal> statement to determine which
- indexes are used for a <literal>SELECT</literal>. See
+ In general, when you want to make a slow <literal>SELECT ...
+ WHERE</literal> query faster, the first thing to check is
+ whether you can add an index. All references between different
+ tables should usually be done with indexes. You can use the
+ <literal>EXPLAIN</literal> statement to determine which indexes
+ are used for a <literal>SELECT</literal>. See
<xref linkend="explain"/>, and <xref linkend="mysql-indexes"/>.
</para>
@@ -2870,19 +2870,19 @@
<listitem>
<para>
- <literal>Using intersect(…)</literal>
+ <literal>Using intersect(...)</literal>
</para>
</listitem>
<listitem>
<para>
- <literal>Using union(…)</literal>
+ <literal>Using union(...)</literal>
</para>
</listitem>
<listitem>
<para>
- <literal>Using sort_union(…)</literal>
+ <literal>Using sort_union(...)</literal>
</para>
</listitem>
@@ -4470,8 +4470,8 @@
</itemizedlist>
<para>
- With <literal>EXPLAIN SELECT … ORDER BY</literal>, you
- can check whether MySQL can use indexes to resolve the query. It
+ With <literal>EXPLAIN SELECT ... ORDER BY</literal>, you can
+ check whether MySQL can use indexes to resolve the query. It
cannot if you see <literal>Using filesort</literal> in the
<literal>Extra</literal> column. See <xref linkend="explain"/>.
</para>
@@ -4598,11 +4598,10 @@
By default, MySQL sorts all <literal>GROUP BY
<replaceable>col1</replaceable>,
- <replaceable>col2</replaceable>, …</literal> queries as
- if you specified <literal>ORDER BY
- <replaceable>col1</replaceable>,
- <replaceable>col2</replaceable>, …</literal> in the query
- as well. If you include an <literal>ORDER BY</literal> clause
+ <replaceable>col2</replaceable>, ...</literal> queries as if you
+ specified <literal>ORDER BY <replaceable>col1</replaceable>,
+ <replaceable>col2</replaceable>, ...</literal> in the query as
+ well. If you include an <literal>ORDER BY</literal> clause
explicitly that contains the same column list, MySQL optimizes
it away without any speed penalty, although the sorting still
occurs. If a query includes <literal>GROUP BY</literal> but you
@@ -5528,14 +5527,14 @@
<listitem>
<para>
- Use <literal>ALTER TABLE … ORDER BY
+ Use <literal>ALTER TABLE ... ORDER BY
<replaceable>expr1</replaceable>,
- <replaceable>expr2</replaceable>, …</literal> if you
+ <replaceable>expr2</replaceable>, ...</literal> if you
usually retrieve rows in
<literal><replaceable>expr1</replaceable>,
- <replaceable>expr2</replaceable>, …</literal> order.
- By using this option after extensive changes to the table,
- you may be able to get higher performance.
+ <replaceable>expr2</replaceable>, ...</literal> order. By
+ using this option after extensive changes to the table, you
+ may be able to get higher performance.
</para>
</listitem>
@@ -7199,7 +7198,7 @@
</para>
<para>
- If you use <literal>… LIKE
+ If you use <literal>... LIKE
'%<replaceable>string</replaceable>%'</literal> and
<replaceable>string</replaceable> is longer than three
characters, MySQL uses the <firstterm>Turbo Boyer-Moore
@@ -9936,7 +9935,7 @@
</remark>
<para>
- If you rename a table with <literal>ALTER TABLE …
+ If you rename a table with <literal>ALTER TABLE ...
RENAME</literal> and you do not move the table to another
database, the symlinks in the database directory are
renamed to the new names and the data file and index file
@@ -9950,8 +9949,8 @@
</remark>
<para>
- If you use <literal>ALTER TABLE … RENAME</literal>
- to move a table to another database, the table is moved to
+ If you use <literal>ALTER TABLE ... RENAME</literal> to
+ move a table to another database, the table is moved to
the other database directory. The old symlinks and the
files to which they pointed are deleted. In other words,
the new table is not symlinked.
Modified: trunk/refman-common/manual-conventions.en.xml
===================================================================
--- trunk/refman-common/manual-conventions.en.xml 2006-02-18 23:31:13 UTC (rev 1387)
+++ trunk/refman-common/manual-conventions.en.xml 2006-02-18 23:31:31 UTC (rev 1388)
@@ -188,9 +188,9 @@
</programlisting>
<para>
- An ellipsis (<literal>…</literal>) indicates the omission of
+ An ellipsis (<literal>...</literal>) indicates the omission of
a section of a statement, typically to provide a shorter version of
- more complex syntax. For example, <literal>INSERT …
+ more complex syntax. For example, <literal>INSERT ...
SELECT</literal> is shorthand for the form of
<literal>INSERT</literal> statement that is followed by a
<literal>SELECT</literal> statement.
Modified: trunk/refman-common/news-4.1.xml
===================================================================
--- trunk/refman-common/news-4.1.xml 2006-02-18 23:31:13 UTC (rev 1387)
+++ trunk/refman-common/news-4.1.xml 2006-02-18 23:31:31 UTC (rev 1388)
@@ -628,7 +628,7 @@
<listitem>
<para>
<literal>DELETE</literal> could report full-text index
- corruption (<literal>Invalid key for table …</literal>)
+ corruption (<literal>Invalid key for table ...</literal>)
if the index was built with repair-by-sort, the data in the
full-text index used UCA collation, and some word appeared in
the data terminated by a 0xC2A0 character as well as by other
@@ -980,7 +980,7 @@
<listitem>
<para>
<literal>CREATE TABLE <replaceable>tbl_name</replaceable>
- (…) SELECT …</literal> could crash the server
+ (...) SELECT ...</literal> could crash the server
and write invalid data into the <filename>.frm</filename> file
if the <literal>CREATE TABLE</literal> and
<literal>SELECT</literal> both contained a column with the
@@ -1045,8 +1045,8 @@
<listitem>
<para>
- Statements of the form <literal>CREATE TABLE … SELECT
- …</literal> that created a column with a multi-byte
+ Statements of the form <literal>CREATE TABLE ... SELECT
+ ...</literal> that created a column with a multi-byte
character set could incorrectly calculate the maximum length
of the column, resulting in a <literal>Specified key was too
long</literal> error. (Bug #14139)
Modified: trunk/refman-common/news-5.0.xml
===================================================================
--- trunk/refman-common/news-5.0.xml 2006-02-18 23:31:13 UTC (rev 1387)
+++ trunk/refman-common/news-5.0.xml 2006-02-18 23:31:31 UTC (rev 1388)
@@ -1523,7 +1523,7 @@
<para>
Implicit versus explicit conversion of float to integer (such
as inserting a float value into an integer column versus using
- <literal>CAST(… AS UNSIGNED</literal> before inserting
+ <literal>CAST(... AS UNSIGNED</literal> before inserting
the value) could produce different results. Implicit and
explicit typecasts now are done the same way, with a value
equal to the nearest integer according to the prevailing
@@ -1603,7 +1603,7 @@
<listitem>
<para>
Within a stored procedure, inserting with <literal>INSERT
- … SELECT</literal> into a table with an
+ ... SELECT</literal> into a table with an
<literal>AUTO_INCREMENT</literal> column did not generate the
correct sequence number. (Bug #14304)
</para>
@@ -1660,7 +1660,7 @@
<listitem>
<para>
- <literal>ALTER TABLE … SET DEFAULT</literal> had no
+ <literal>ALTER TABLE ... SET DEFAULT</literal> had no
effect. (Bug #14693)
</para>
</listitem>
@@ -1688,8 +1688,8 @@
<listitem>
<para>
- <literal>CHAR(… USING …)</literal> and
- <literal>CONVERT(CHAR(…) USING …)</literal>,
+ <literal>CHAR(... USING ...)</literal> and
+ <literal>CONVERT(CHAR(...) USING ...)</literal>,
though logically equivalent, could produce different results.
(Bug #14146)
</para>
@@ -1950,7 +1950,7 @@
<listitem>
<para>
<literal>CREATE TABLE <replaceable>tbl_name</replaceable>
- (…) SELECT …</literal> could crash the server
+ (...) SELECT ...</literal> could crash the server
and write invalid data into the <filename>.frm</filename> file
if the <literal>CREATE TABLE</literal> and
<literal>SELECT</literal> both contained a column with the
@@ -2025,7 +2025,7 @@
procedure with the procedure name explicitly qualified with a
database name (<literal>CREATE PROCEDURE
<replaceable>db_name</replaceable>.<replaceable>proc_name</replaceable>
- …</literal>). 2) Create another stored procedure with
+ ...</literal>). 2) Create another stored procedure with
no database name qualifier. 3) Execute <literal>SHOW PROCEDURE
STATUS</literal>. (Bug #14569)
</para>
@@ -2433,8 +2433,8 @@
<listitem>
<para>
- Statements of the form <literal>CREATE TABLE … SELECT
- …</literal> that created a column with a multi-byte
+ Statements of the form <literal>CREATE TABLE ... SELECT
+ ...</literal> that created a column with a multi-byte
character set could incorrectly calculate the maximum length
of the column, resulting in a <literal>Specified key was too
long</literal> error. (Bug #14139)
@@ -2652,14 +2652,14 @@
<listitem>
<para>
Corrected a parser precedence problem that resulted in an
- <literal>Unknown column … in 'on clause'</literal>
+ <literal>Unknown column ... in 'on clause'</literal>
error for some joins. (Bug #13832)
</para>
</listitem>
<listitem>
<para>
- For <literal>LIKE … ESCAPE</literal>, an escape
+ For <literal>LIKE ... ESCAPE</literal>, an escape
sequence longer than one character was accepted as valid. Now
the sequence must be empty or one character long. If the
<literal>NO_BACKSLASH_ESCAPES</literal> SQL mode is enabled,
@@ -6210,9 +6210,9 @@
<listitem>
<para>
- A recent optimizer change caused <literal>DELETE …
- WHERE … NOT LIKE</literal> and <literal>DELETE …
- WHERE … NOT BETWEEN</literal> to not properly identify
+ A recent optimizer change caused <literal>DELETE ...
+ WHERE ... NOT LIKE</literal> and <literal>DELETE ...
+ WHERE ... NOT BETWEEN</literal> to not properly identify
the rows to be deleted. (Bug #11853)
</para>
</listitem>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r1388 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-common | paul | 19 Feb |
