Author: paul
Date: 2006-06-23 07:17:43 +0200 (Fri, 23 Jun 2006)
New Revision: 2481
Log:
r11619@frost: paul | 2006-06-23 00:17:13 -0500
Document bugfixes:
Bug#14708
Bug#15351
Bug#15355
Bug#15962
Bug#17589
Bug#19667
Modified:
trunk/
trunk/refman-common/news-4.1.xml
trunk/refman-common/news-5.0.xml
trunk/refman-common/news-5.1.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:10808
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:11604
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:7663
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:10808
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:11619
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:7663
Modified: trunk/refman-common/news-4.1.xml
===================================================================
--- trunk/refman-common/news-4.1.xml 2006-06-23 03:55:48 UTC (rev 2480)
+++ trunk/refman-common/news-4.1.xml 2006-06-23 05:17:43 UTC (rev 2481)
@@ -338,6 +338,18 @@
<listitem>
<para>
+ The MD5() and SHA() functions treat their arguments as
+ case-sensitive strings. But when they are compared, their
+ arguments were compared as case-insensitive strings, which
+ leads to two function calls with different arguments (and thus
+ different results) compared as being identical. This can lead
+ to a wrong decision made in the range optimizer and thus to an
+ incorrect result set. (Bug #15351)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
<literal>InnoDB</literal> unlocked its data directory before
committing a transaction, potentially resulting in
non-recoverable tables if a server crash occurred before the
Modified: trunk/refman-common/news-5.0.xml
===================================================================
--- trunk/refman-common/news-5.0.xml 2006-06-23 03:55:48 UTC (rev 2480)
+++ trunk/refman-common/news-5.0.xml 2006-06-23 05:17:43 UTC (rev 2481)
@@ -564,6 +564,56 @@
<listitem>
<para>
+ Nested natural joins worked executed correctly when executed
+ as a non-prepared statement could fail with an
+ <literal>Unknown column '<replaceable>col_name</replaceable>'
+ in 'field list'</literal> error when executed as a prepared
+ statement, due to a name resolution problem. (Bug #15355)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>GROUP BY</literal> on an expression that contained a
+ cast to <literal>DECIMAL</literal> produced an incorrect
+ result. (Bug #19667)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>max_length</literal> metadata value for columns
+ created from <literal>CONCAT()</literal> could be incorrect
+ when the collation of an argument differed from the collation
+ of the <literal>CONCAT()</literal> itself. In some contexts
+ such as <literal>UNION</literal>, this could lead to
+ truncation of the column contents. (Bug #15962)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The MD5() and SHA() functions treat their arguments as
+ case-sensitive strings. But when they are compared, their
+ arguments were compared as case-insensitive strings, which
+ leads to two function calls with different arguments (and thus
+ different results) compared as being identical. This can lead
+ to a wrong decision made in the range optimizer and thus to an
+ incorrect result set. (Bug #15351)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ For <literal>BOOLEAN</literal> mode full-text searches on
+ non-indexed columns, <literal>NULL</literal> rows generated by
+ a <literal>LEFT JOIN</literal> caused incorrect query results.
+ (Bug #14708)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
<literal>BIT</literal> columns in a table could cause joins
that use the table to fail. (Bug #18895)
</para>
Modified: trunk/refman-common/news-5.1.xml
===================================================================
--- trunk/refman-common/news-5.1.xml 2006-06-23 03:55:48 UTC (rev 2480)
+++ trunk/refman-common/news-5.1.xml 2006-06-23 05:17:43 UTC (rev 2481)
@@ -463,6 +463,56 @@
<listitem>
<para>
+ Nested natural joins worked executed correctly when executed
+ as a non-prepared statement could fail with an
+ <literal>Unknown column '<replaceable>col_name</replaceable>'
+ in 'field list'</literal> error when executed as a prepared
+ statement, due to a name resolution problem. (Bug #15355)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>max_length</literal> metadata value for columns
+ created from <literal>CONCAT()</literal> could be incorrect
+ when the collation of an argument differed from the collation
+ of the <literal>CONCAT()</literal> itself. In some contexts
+ such as <literal>UNION</literal>, this could lead to
+ truncation of the column contents. (Bug #15962)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The MD5() and SHA() functions treat their arguments as
+ case-sensitive strings. But when they are compared, their
+ arguments were compared as case-insensitive strings, which
+ leads to two function calls with different arguments (and thus
+ different results) compared as being identical. This can lead
+ to a wrong decision made in the range optimizer and thus to an
+ incorrect result set. (Bug #15351)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ For <literal>BOOLEAN</literal> mode full-text searches on
+ non-indexed columns, <literal>NULL</literal> rows generated by
+ a <literal>LEFT JOIN</literal> caused incorrect query results.
+ (Bug #14708)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If the general log table reached a large enough file size
+ (27GB), <literal>SELECT COUNT(*)</literal> on the table caused
+ a server crash. (Bug #17589)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
Identifiers could not contain bytes with a value of 255,
though that should be allowed as of the identifier-encoding
changes made in MySQL 5.1.6. (Bug #12982)
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r2481 - in trunk: . refman-common | paul | 23 Jun |
