svn commit - mysqldoc@docsrva: r4246 - in trunk: refman-4.1 refman-5.0 refman-5.1

[jon]

Author: jstephens
Date: 2006-12-14 06:02:30 +0100 (Thu, 14 Dec 2006)
New Revision: 4246

Log:

Documenting Server bugfixes:

  Bug #20835, Bug #21915, Bug #22052, Bug #22369, Bug #22457
  Bug #24395, Bug #24156, Bug #21025, Bug #21412, Bug #21789



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 01:58:12 UTC (rev 4245)
+++ trunk/refman-4.1/news-4.1.xml	2006-12-14 05:02:30 UTC (rev 4246)
Changed blocks: 2, Lines Added: 75, Lines Deleted: 0; 3357 bytes

@@ -198,6 +198,48 @@
     </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)
+        </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)
+        </para>
+      </listitem>
+      
+      <listitem>
+        <para>
+          Trailing spaces were not removed from Unicode
+          <literal>CHAR</literal> column values when used in indexes.
+          This resulted in excessive usage of storage space, and could
+          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.
+        </para>
+        
+        <para>
+          (Bug #22052)
+        </para>
+      </listitem>
 
       <listitem>
         <para>

@@ -456,6 +498,39 @@
     </para>
 
     <itemizedlist>
+      
+      <listitem>
+        <para>
+          If the user specified the server options
+         
<option>--max-connections=<replaceable>N</replaceable></option>
+          or
+         
<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.
+        </para>
+        
+        <para>
+          It should be noted that, in such cases, both the warning and
+          the increase in the <option>--table-open-cache</option> value
+          were completely harmless. Note also that it is not possible
+          for the MySQL Server to predict or to control limitations on
+          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
+          increased automatically, and that a warning is now given only
+          if some values had to be decreased due to operating system
+          limits.
+        </para>
+        
+        <para>
+          (Bug #21915)
+        </para>
+      </listitem>
 
       <listitem>
         <para>


Modified: trunk/refman-5.0/releasenotes-es-5.0.xml
===================================================================
--- trunk/refman-5.0/releasenotes-es-5.0.xml	2006-12-14 01:58:12 UTC (rev 4245)
+++ trunk/refman-5.0/releasenotes-es-5.0.xml	2006-12-14 05:02:30 UTC (rev 4246)
Changed blocks: 2, Lines Added: 105, Lines Deleted: 0; 4594 bytes

@@ -95,6 +95,78 @@
     </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) 
+        </para>
+      </listitem>
+      
+      <listitem>
+        <para>
+          It was possible to set the backslash character
+          (<quote><literal>\</literal></quote>) as the delimiter
+          character using <literal>DELIMITER</literal>, but not actually
+          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
+          <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)
+        </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)
+        </para>
+      </listitem>
+      
+      <listitem>
+        <para>
+          Trailing spaces were not removed from Unicode
+          <literal>CHAR</literal> column values when used in indexes.
+          This resulted in excessive usage of storage space, and could
+          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.
+        </para>
+        
+        <para>
+          (Bug #22052)
+        </para>
+      </listitem>
 
       <listitem>
         <para>

@@ -569,6 +641,39 @@
     </para>
 
     <itemizedlist>
+      
+      <listitem>
+        <para>
+          If the user specified the server options
+         
<option>--max-connections=<replaceable>N</replaceable></option>
+          or
+         
<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.
+        </para>
+        
+        <para>
+          It should be noted that, in such cases, both the warning and
+          the increase in the <option>--table-open-cache</option> value
+          were completely harmless. Note also that it is not possible
+          for the MySQL Server to predict or to control limitations on
+          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
+          increased automatically, and that a warning is now given only
+          if some values had to be decreased due to operating system
+          limits.
+        </para>
+        
+        <para>
+          (Bug #21915)
+        </para>
+      </listitem>
 
       <listitem>
         <para>


Modified: trunk/refman-5.1/news-5.1.xml
===================================================================
--- trunk/refman-5.1/news-5.1.xml	2006-12-14 01:58:12 UTC (rev 4245)
+++ trunk/refman-5.1/news-5.1.xml	2006-12-14 05:02:30 UTC (rev 4246)
Changed blocks: 3, Lines Added: 144, Lines Deleted: 1; 6773 bytes

@@ -141,6 +141,66 @@
       
       <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) 
+        </para>
+      </listitem>
+      
+      <listitem>
+        <para>
+          It was possible to set the backslash character
+          (<quote><literal>\</literal></quote>) as the delimiter
+          character using <literal>DELIMITER</literal>, but not actually
+          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)
+        </para>
+      </listitem>
+      
+      <listitem>
+        <para>
+          An <literal>ALTER TABLE</literal> statement that used a
+          <literal>RENAME</literal> clause in combination with a
+          <literal>MODIFY</literal> or <literal>CHANGE</literal>
that
+          did not actually change the table (for example, when it
+          changed a column's type from <literal>INT</literal> to
+          <literal>INT</literal>). The behavior caused by this bug
+          differed according to whether or not the storage engine used
+          by the table was transactional or non-transactional. For
+          transactional tables (such as those using the
+          <literal>InnoDB</literal> storage engine), the statement
+          simply failed; for non-transactional tables (such as those
+          using the <literal>MyISAM</literal> storage engine), the
+          <literal>ALTER TABLE</literal> statement succeeding renaming
+          the table, but subsequent <literal>SELECT</literal> statements
+          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)
+        </para>
+      </listitem>
+      
+      <listitem>
+        <para>
           A partitioned table that used the <literal>DATA
             DIRECTORY</literal> option, where the data directory was the
           same as the directory in which the table definition file

@@ -505,9 +565,59 @@
     </para>
 
     <itemizedlist>
-
+      
       <listitem>
         <para>
+          <literal>CREATE FUNCTION X()</literal> and <literal>CREATE
+            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
+          <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)
+        </para>
+      </listitem>
+      
+      <listitem>
+        <para>
+          Trailing spaces were not removed from Unicode
+          <literal>CHAR</literal> column values when used in indexes.
+          This resulted in excessive usage of storage space, and could
+          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.
+        </para>
+        
+        <para>
+          (Bug #22052)
+        </para>
+      </listitem>
+      <listitem>
+        <para>
           <literal>NDB Cluster</literal> (Replication): If errors
           occurred during purging of the binary logs, extraneous rows
           could remain left in the <literal>binlog_index</literal>

@@ -1100,6 +1210,39 @@
     </para>
 
     <itemizedlist>
+      
+      <listitem>
+        <para>
+          If the user specified the server options
+         
<option>--max-connections=<replaceable>N</replaceable></option>
+          or
+         
<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.
+        </para>
+        
+        <para>
+          It should be noted that, in such cases, both the warning and
+          the increase in the <option>--table-open-cache</option> value
+          were completely harmless. Note also that it is not possible
+          for the MySQL Server to predict or to control limitations on
+          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
+          increased automatically, and that a warning is now given only
+          if some values had to be decreased due to operating system
+          limits.
+        </para>
+        
+        <para>
+          (Bug #21915)
+        </para>
+      </listitem>
 
       <listitem>
         <para>