Author: jstephens
Date: 2006-12-14 06:20:37 +0100 (Thu, 14 Dec 2006)
New Revision: 4248
Log:
Reformat.
Modified:
trunk/refman-4.1/news-4.1.xml
trunk/refman-5.0/releasenotes-es-5.0.xml
trunk/refman-5.1/news-5.1.xml
Modified: trunk/refman-4.1/news-4.1.xml
===================================================================
--- trunk/refman-4.1/news-4.1.xml 2006-12-14 05:18:21 UTC (rev 4247)
+++ trunk/refman-4.1/news-4.1.xml 2006-12-14 05:20:37 UTC (rev 4248)
Changed blocks: 6, Lines Added: 18, Lines Deleted: 17; 3420 bytes
@@ -198,27 +198,27 @@
</para>
<itemizedlist>
-
+
<listitem>
<para>
<literal>ALTER ENABLE KEYS</literal> or <literal>ALTER TABLE
- DISABLE KEYS</literal> combined with another <literal>ALTER
- TABLE</literal> option other than <literal>RENAME
- TO</literal> did nothing. In addition, if ALTER TABLE
- was used on a table having disabled keys, the keys of the
- resulting table were enabled. (Bug #24395)
+ DISABLE KEYS</literal> combined with another <literal>ALTER
+ TABLE</literal> option other than <literal>RENAME TO</literal>
+ did nothing. In addition, if ALTER TABLE was used on a table
+ having disabled keys, the keys of the resulting table were
+ enabled. (Bug #24395)
</para>
</listitem>
-
+
<listitem>
<para>
Queries using a column alias in an expression as part of an
<literal>ORDER BY</literal> clause failed, an example of such
a query being <literal>SELECT mycol + 1 AS mynum FROM mytable
- ORDER BY 30 - mynum</literal>. (Bug #22457)
+ ORDER BY 30 - mynum</literal>. (Bug #22457)
</para>
</listitem>
-
+
<listitem>
<para>
Trailing spaces were not removed from Unicode
@@ -227,15 +227,15 @@
affect the results of some <literal>ORDER BY</literal> queries
that made use of such indexes.
</para>
-
+
<para>
<emphasis role="bold">Note</emphasis>: When upgrading, it is
necessary to re-create any existing indexes on Unicode
<literal>CHAR</literal> columns in order to take advantage of
the fix. This can be done by using a <literal>REPAIR
- TABLE</literal> statement on each affected table.
+ TABLE</literal> statement on each affected table.
</para>
-
+
<para>
(Bug #22052)
</para>
@@ -498,7 +498,7 @@
</para>
<itemizedlist>
-
+
<listitem>
<para>
If the user specified the server options
@@ -507,9 +507,10 @@
<option>--table-open-cache=<replaceable>M</replaceable></option>,
a warning would be given in some cases that some values were
recalculated, with the result that
- <option>--table-open-cache</option> could be assigned greater value.
+ <option>--table-open-cache</option> could be assigned greater
+ value.
</para>
-
+
<para>
It should be noted that, in such cases, both the warning and
the increase in the <option>--table-open-cache</option> value
@@ -518,7 +519,7 @@
the maximum number of open files, since this is determined by
the operating system.
</para>
-
+
<para>
The recalculation code has now been fixed to ensure that the
value of <option>--table-open-cache</option> is no longer
@@ -526,7 +527,7 @@
if some values had to be decreased due to operating system
limits.
</para>
-
+
<para>
(Bug #21915)
</para>
Modified: trunk/refman-5.0/releasenotes-es-5.0.xml
===================================================================
--- trunk/refman-5.0/releasenotes-es-5.0.xml 2006-12-14 05:18:21 UTC (rev 4247)
+++ trunk/refman-5.0/releasenotes-es-5.0.xml 2006-12-14 05:20:37 UTC (rev 4248)
Changed blocks: 9, Lines Added: 37, Lines Deleted: 34; 7025 bytes
@@ -56,30 +56,32 @@
</para>
<itemizedlist>
-
+
<listitem>
<para>
<literal>NDB Cluster</literal>: It is now possible to create a
unique hashed index on a column that is not defined as
<literal>NOT NULL</literal>. <emphasis>Note that this change
- applies only to tables using the <literal>NDB</literal>
- storage engine</emphasis>.
+ applies only to tables using the <literal>NDB</literal>
+ storage engine</emphasis>.
</para>
-
+
<para>
Unique indexes on columns in <literal>NDB</literal> tables do
not store null values because they are mapped to primary keys
in an internal index table (and primary keys cannot contain
nulls).
</para>
+
<para>
Normally, an additional ordered index is created when one
- creates unique indexes on <literal>NDB</literal> table columns;
- this can be used to search for <literal>NULL</literal> values.
- However, if <literal>USING HASH</literal> is specified when
- such an index is created, no ordered index is created.
+ creates unique indexes on <literal>NDB</literal> table
+ columns; this can be used to search for
+ <literal>NULL</literal> values. However, if <literal>USING
+ HASH</literal> is specified when such an index is created, no
+ ordered index is created.
</para>
-
+
<para>
The reason for permitting unique hash indexes with null values
is that, in some cases, the user wants to save space if a
@@ -89,16 +91,16 @@
MySQL does not support indexes that are not allowed to be
searched in some cases, the <literal>NDB</literal> storage
engine uses a full table scan with pushed conditions for the
- referenced index columns to return the correct result.
+ referenced index columns to return the correct result.
</para>
-
+
<para>
Note that a warning is returned if one creates a unique
nullable hash index, since the query optimizer should be
provided a hint not to use it with <literal>NULL</literal>
values if this can be avoided.
</para>
-
+
<para>
(Bug #21507)
</para>
@@ -142,17 +144,17 @@
</para>
<itemizedlist>
-
+
<listitem>
<para>
It was possible to use <literal>DATETIME</literal> values
whose year, month, and day parts were all zeroes but whose
hour, minute, and second parts contained nonzero values, an
example of such an illegal <literal>DATETIME</literal> being
- <literal>'0000-00-00 11:23:45'</literal>. (Bug #21789)
+ <literal>'0000-00-00 11:23:45'</literal>. (Bug #21789)
</para>
</listitem>
-
+
<listitem>
<para>
It was possible to set the backslash character
@@ -161,38 +163,38 @@
possible to use it as the delimiter. (Bug #21412)
</para>
</listitem>
-
+
<listitem>
<para>
The loose index scan optimization for <literal>GROUP
- BY</literal> with <literal>MIN</literal> or
+ BY</literal> with <literal>MIN</literal> or
<literal>MAX</literal> was not applied within other queries,
such as <literal>CREATE TABLE ... SELECT ...</literal>,
<literal>INSERT ... SELECT ...</literal>, or in the
<literal>FROM</literal> clauses of subqueries. (Bug #24156)
</para>
</listitem>
-
+
<listitem>
<para>
<literal>ALTER ENABLE KEYS</literal> or <literal>ALTER TABLE
- DISABLE KEYS</literal> combined with another <literal>ALTER
- TABLE</literal> option other than <literal>RENAME
- TO</literal> did nothing. In addition, if ALTER TABLE
- was used on a table having disabled keys, the keys of the
- resulting table were enabled. (Bug #24395)
+ DISABLE KEYS</literal> combined with another <literal>ALTER
+ TABLE</literal> option other than <literal>RENAME TO</literal>
+ did nothing. In addition, if ALTER TABLE was used on a table
+ having disabled keys, the keys of the resulting table were
+ enabled. (Bug #24395)
</para>
</listitem>
-
+
<listitem>
<para>
Queries using a column alias in an expression as part of an
<literal>ORDER BY</literal> clause failed, an example of such
a query being <literal>SELECT mycol + 1 AS mynum FROM mytable
- ORDER BY 30 - mynum</literal>. (Bug #22457)
+ ORDER BY 30 - mynum</literal>. (Bug #22457)
</para>
</listitem>
-
+
<listitem>
<para>
Trailing spaces were not removed from Unicode
@@ -201,15 +203,15 @@
affect the results of some <literal>ORDER BY</literal> queries
that made use of such indexes.
</para>
-
+
<para>
<emphasis role="bold">Note</emphasis>: When upgrading, it is
necessary to re-create any existing indexes on Unicode
<literal>CHAR</literal> columns in order to take advantage of
the fix. This can be done by using a <literal>REPAIR
- TABLE</literal> statement on each affected table.
+ TABLE</literal> statement on each affected table.
</para>
-
+
<para>
(Bug #22052)
</para>
@@ -688,7 +690,7 @@
</para>
<itemizedlist>
-
+
<listitem>
<para>
If the user specified the server options
@@ -697,9 +699,10 @@
<option>--table-open-cache=<replaceable>M</replaceable></option>,
a warning would be given in some cases that some values were
recalculated, with the result that
- <option>--table-open-cache</option> could be assigned greater value.
+ <option>--table-open-cache</option> could be assigned greater
+ value.
</para>
-
+
<para>
It should be noted that, in such cases, both the warning and
the increase in the <option>--table-open-cache</option> value
@@ -708,7 +711,7 @@
the maximum number of open files, since this is determined by
the operating system.
</para>
-
+
<para>
The recalculation code has now been fixed to ensure that the
value of <option>--table-open-cache</option> is no longer
@@ -716,7 +719,7 @@
if some values had to be decreased due to operating system
limits.
</para>
-
+
<para>
(Bug #21915)
</para>
Modified: trunk/refman-5.1/news-5.1.xml
===================================================================
--- trunk/refman-5.1/news-5.1.xml 2006-12-14 05:18:21 UTC (rev 4247)
+++ trunk/refman-5.1/news-5.1.xml 2006-12-14 05:20:37 UTC (rev 4248)
Changed blocks: 11, Lines Added: 48, Lines Deleted: 45; 9072 bytes
@@ -138,17 +138,17 @@
</para>
<itemizedlist>
-
+
<listitem>
<para>
It was possible to use <literal>DATETIME</literal> values
whose year, month, and day parts were all zeroes but whose
hour, minute, and second parts contained nonzero values, an
example of such an illegal <literal>DATETIME</literal> being
- <literal>'0000-00-00 11:23:45'</literal>. (Bug #21789)
+ <literal>'0000-00-00 11:23:45'</literal>. (Bug #21789)
</para>
</listitem>
-
+
<listitem>
<para>
It was possible to set the backslash character
@@ -157,18 +157,18 @@
possible to use it as the delimiter. (Bug #21412)
</para>
</listitem>
-
+
<listitem>
<para>
<literal>ALTER ENABLE KEYS</literal> or <literal>ALTER TABLE
- DISABLE KEYS</literal> combined with another <literal>ALTER
- TABLE</literal> option other than <literal>RENAME
- TO</literal> did nothing. In addition, if ALTER TABLE
- was used on a table having disabled keys, the keys of the
- resulting table were enabled. (Bug #24395)
+ DISABLE KEYS</literal> combined with another <literal>ALTER
+ TABLE</literal> option other than <literal>RENAME TO</literal>
+ did nothing. In addition, if ALTER TABLE was used on a table
+ having disabled keys, the keys of the resulting table were
+ enabled. (Bug #24395)
</para>
</listitem>
-
+
<listitem>
<para>
An <literal>ALTER TABLE</literal> statement that used a
@@ -188,24 +188,23 @@
against the renamed table would fail. (Bug #22369)
</para>
</listitem>
-
+
<listitem>
<para>
Queries of the form <literal>SELECT ... WHERE
- <replaceable>string</replaceable> =
- ANY(...)</literal> failed when the server used a single-byte
- character set and the client used a multi-byte character set.
- (Bug #20835)
+ <replaceable>string</replaceable> = ANY(...)</literal> failed
+ when the server used a single-byte character set and the
+ client used a multi-byte character set. (Bug #20835)
</para>
</listitem>
-
+
<listitem>
<para>
A partitioned table that used the <literal>DATA
- DIRECTORY</literal> option, where the data directory was the
+ DIRECTORY</literal> option, where the data directory was the
same as the directory in which the table definition file
resided, became corrupted following <literal>ALTER TABLE
- ENGINE=ARCHIVE</literal>. This was actually due to an issue
+ ENGINE=ARCHIVE</literal>. This was actually due to an issue
with the <literal>ARCHIVE</literal> storage engine, and not
with partitioned tables in general. (Bug #22634)
</para>
@@ -504,30 +503,32 @@
<xref linkend="mysql-cluster-replication-schema"/>.
</para>
</listitem>
-
+
<listitem>
<para>
<literal>NDB Cluster</literal>: It is now possible to create a
unique hashed index on a column that is not defined as
<literal>NOT NULL</literal>. <emphasis>Note that this change
- applies only to tables using the <literal>NDB</literal>
- storage engine</emphasis>.
+ applies only to tables using the <literal>NDB</literal>
+ storage engine</emphasis>.
</para>
-
+
<para>
Unique indexes on columns in <literal>NDB</literal> tables do
not store null values because they are mapped to primary keys
in an internal index table (and primary keys cannot contain
nulls).
</para>
+
<para>
Normally, an additional ordered index is created when one
- creates unique indexes on <literal>NDB</literal> table columns;
- this can be used to search for <literal>NULL</literal> values.
- However, if <literal>USING HASH</literal> is specified when
- such an index is created, no ordered index is created.
+ creates unique indexes on <literal>NDB</literal> table
+ columns; this can be used to search for
+ <literal>NULL</literal> values. However, if <literal>USING
+ HASH</literal> is specified when such an index is created, no
+ ordered index is created.
</para>
-
+
<para>
The reason for permitting unique hash indexes with null values
is that, in some cases, the user wants to save space if a
@@ -537,16 +538,16 @@
MySQL does not support indexes that are not allowed to be
searched in some cases, the <literal>NDB</literal> storage
engine uses a full table scan with pushed conditions for the
- referenced index columns to return the correct result.
+ referenced index columns to return the correct result.
</para>
-
+
<para>
Note that a warning is returned if one creates a unique
nullable hash index, since the query optimizer should be
provided a hint not to use it with <literal>NULL</literal>
values if this can be avoided.
</para>
-
+
<para>
(Bug #21507)
</para>
@@ -612,36 +613,36 @@
</para>
<itemizedlist>
-
+
<listitem>
<para>
<literal>CREATE FUNCTION X()</literal> and <literal>CREATE
- FUNCTION Y()</literal> failed with a syntax error instead of
+ FUNCTION Y()</literal> failed with a syntax error instead of
warning the user that these function names are already used
(for GIS functions). (Bug #21015)
</para>
</listitem>
-
+
<listitem>
<para>
The loose index scan optimization for <literal>GROUP
- BY</literal> with <literal>MIN</literal> or
+ BY</literal> with <literal>MIN</literal> or
<literal>MAX</literal> was not applied within other queries,
such as <literal>CREATE TABLE ... SELECT ...</literal>,
<literal>INSERT ... SELECT ...</literal>, or in the
<literal>FROM</literal> clauses of subqueries. (Bug #24156)
</para>
</listitem>
-
+
<listitem>
<para>
Queries using a column alias in an expression as part of an
<literal>ORDER BY</literal> clause failed, an example of such
a query being <literal>SELECT mycol + 1 AS mynum FROM mytable
- ORDER BY 30 - mynum</literal>. (Bug #22457)
+ ORDER BY 30 - mynum</literal>. (Bug #22457)
</para>
</listitem>
-
+
<listitem>
<para>
Trailing spaces were not removed from Unicode
@@ -650,19 +651,20 @@
affect the results of some <literal>ORDER BY</literal> queries
that made use of such indexes.
</para>
-
+
<para>
<emphasis role="bold">Note</emphasis>: When upgrading, it is
necessary to re-create any existing indexes on Unicode
<literal>CHAR</literal> columns in order to take advantage of
the fix. This can be done by using a <literal>REPAIR
- TABLE</literal> statement on each affected table.
+ TABLE</literal> statement on each affected table.
</para>
-
+
<para>
(Bug #22052)
</para>
</listitem>
+
<listitem>
<para>
<literal>NDB Cluster</literal> (Replication): If errors
@@ -1257,7 +1259,7 @@
</para>
<itemizedlist>
-
+
<listitem>
<para>
If the user specified the server options
@@ -1266,9 +1268,10 @@
<option>--table-open-cache=<replaceable>M</replaceable></option>,
a warning would be given in some cases that some values were
recalculated, with the result that
- <option>--table-open-cache</option> could be assigned greater value.
+ <option>--table-open-cache</option> could be assigned greater
+ value.
</para>
-
+
<para>
It should be noted that, in such cases, both the warning and
the increase in the <option>--table-open-cache</option> value
@@ -1277,7 +1280,7 @@
the maximum number of open files, since this is determined by
the operating system.
</para>
-
+
<para>
The recalculation code has now been fixed to ensure that the
value of <option>--table-open-cache</option> is no longer
@@ -1285,7 +1288,7 @@
if some values had to be decreased due to operating system
limits.
</para>
-
+
<para>
(Bug #21915)
</para>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r4248 - in trunk: refman-4.1 refman-5.0 refman-5.1 | jon | 14 Dec |
