svn commit - mysqldoc@docsrva: r3395 - in trunk: . refman-5.0 refman-5.1

[paul]

Author: paul
Date: 2006-09-19 18:53:13 +0200 (Tue, 19 Sep 2006)
New Revision: 3395

Log:
 r13817@polar:  paul | 2006-09-19 11:53:10 -0500
 Document bugfixes:
 Bug#16249
 Bug#20393
 Bug#21011
 Bug#21432
 Bug#21456
 Bug#21477
 Bug#21787


Modified:
   trunk/refman-5.0/news-5.0.xml
   trunk/refman-5.1/news-5.1.xml

Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:13744
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:10300
   + 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:13817
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:10300


Modified: trunk/refman-5.0/news-5.0.xml
===================================================================
--- trunk/refman-5.0/news-5.0.xml	2006-09-19 14:54:40 UTC (rev 3394)
+++ trunk/refman-5.0/news-5.0.xml	2006-09-19 16:53:13 UTC (rev 3395)
Changed blocks: 2, Lines Added: 27, Lines Deleted: 0; 1621 bytes

@@ -211,6 +211,25 @@
 
       <listitem>
         <para>
+          <command>mysql_upgrade</command> produced a malformed
+          <filename>upgrade_defaults</filename> file by overwriting the
+          <literal>[client]</literal> group header with a
+          <literal>password</literal> option. This prevented
+          <command>mysqlcheck</command> from running successfully when
+          invoked by <command>mysql_upgrade</command>. (Bug #21011)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          Usernames have a maximum length of 16 characters (even if they
+          contain multi-byte characters), but were being truncated to 16
+          bytes. (Bug #20393)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
           <command>mysql</command> displayed an empty string for
           <literal>NULL</literal> values. (Bug #21618)
         </para>

@@ -433,6 +452,14 @@
 
       <listitem>
         <para>
+          Database and table names have a maximum length of 64
+          characters (even if they contain multi-byte characters), but
+          were being truncated to 64 bytes. (Bug #21432)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
           <literal>character_set_results</literal> can be
           <literal>NULL</literal> to signify <quote>no
           conversion,</quote> but some code did not check for


Modified: trunk/refman-5.1/news-5.1.xml
===================================================================
--- trunk/refman-5.1/news-5.1.xml	2006-09-19 14:54:40 UTC (rev 3394)
+++ trunk/refman-5.1/news-5.1.xml	2006-09-19 16:53:13 UTC (rev 3395)
Changed blocks: 1, Lines Added: 73, Lines Deleted: 15; 4492 bytes

@@ -683,41 +683,99 @@
 REPAIR TABLE <replaceable>tbl_name</replaceable> QUICK;
 </programlisting>
       </listitem>
-      
+
       <listitem>
         <para>
+          Database and table names have a maximum length of 64
+          characters (even if they contain multi-byte characters), but
+          were being truncated to 64 bytes. (Bug #21432)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          Usernames have a maximum length of 16 characters (even if they
+          contain multi-byte characters), but were being truncated to 16
+          bytes. (Bug #20393)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          A query could produce different results with and without and
+          index, if the <literal>WHERE</literal> clause contained a
+          range condition that used an invalid
+          <literal>DATETIME</literal> constant. (Bug #16249)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          <literal>COUNT(*)</literal> queries with <literal>ORDER
+          BY</literal> and <literal>LIMIT</literal> could return the
+          wrong result. (Bug #21787)
+        </para>
+
+        <para>
+          <emphasis role="bold">Note</emphasis>: This problem was
+          introduced by the fix for Bug #9676, which limited the rows
+          stored in a temporary table to the <literal>LIMIT</literal>
+          clause. This optimization is not applicable to non-group
+          queries with aggregate functions. The current fix disables the
+          optimization in such cases.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          Memory overruns could occur for certain kinds of subqueries.
+          (Bug #21477)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          Adding <literal>ORDER BY</literal> to a <literal>SELECT
+          DISTINCT(<replaceable>expr</replaceable>)</literal> query
+          could produce incorrect results. (Bug #21456)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
           Memory used by scheduled events was not freed when the events
           were dropped. (Bug #18683)
         </para>
       </listitem>
-      
+
       <listitem>
         <para>
           A scheduled event that took longer to execute than the length
           of time scheduled between successive executions could
-          <quote>skip</quote> executions. For example, an event
-          defined with <literal>EVERY 1 SECOND</literal> &mdash; but
-          which required longer than 1 second to complete &mdash; might
-          be excuted only once every 2 seconds. (Bug #16417)
+          <quote>skip</quote> executions. For example, an event defined
+          with <literal>EVERY 1 SECOND</literal> &mdash; but which
+          required longer than 1 second to complete &mdash; might be
+          excuted only once every 2 seconds. (Bug #16417)
         </para>
       </listitem>
-      
+
       <listitem>
         <para>
-          When used in the <literal>DO</literal> clause of a
<literal>CREATE
-            EVENT</literal> statement, the statements <literal>CREATE
-              EVENT</literal>, <literal>CREATE FUNCTION</literal>, and
-          <literal>CREATE PROCEDURE</literal> caused the server to
-          crash. (These statements are not permitted inside <literal>CREATE
-            EVENT</literal>.) (Bug #16409, Bug #18896) 
+          When used in the <literal>DO</literal> clause of a
+          <literal>CREATE EVENT</literal> statement, the statements
+          <literal>CREATE EVENT</literal>, <literal>CREATE
+          FUNCTION</literal>, and <literal>CREATE PROCEDURE</literal>
+          caused the server to crash. (These statements are not
+          permitted inside <literal>CREATE EVENT</literal>.) (Bug
+          #16409, Bug #18896)
         </para>
       </listitem>
-      
+
       <listitem>
         <para>
           A subselect used in the <literal>ON SCHEDULE</literal> clause
           of a <literal>CREATE EVENT</literal> or <literal>ALTER
-            EVENT</literal> statement caused the server to crash, rather
+          EVENT</literal> statement caused the server to crash, rather
           than producing an error as expected. (Bug #16394)
         </para>
       </listitem>