Author: paul
Date: 2006-09-12 03:46:47 +0200 (Tue, 12 Sep 2006)
New Revision: 3329
Log:
Document bugfixes:
Bug#14897
Bug#17591
Bug#17939
Bug#19741
Bug#19844
Bug#20393
Bug#20402
Bug#21432
Modified:
trunk/refman-4.1/news-4.1.xml
trunk/refman-5.0/news-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-09-12 00:06:56 UTC (rev 3328)
+++ trunk/refman-4.1/news-4.1.xml 2006-09-12 01:46:47 UTC (rev 3329)
Changed blocks: 1, Lines Added: 60, Lines Deleted: 0; 2500 bytes
@@ -200,6 +200,66 @@
<listitem>
<para>
+ For <literal>TIME_FORMAT()</literal>, the
+ <literal>%H</literal> and <literal>%k</literal> format
+ specifiers can return values larger than two digits (if the
+ hour is greater than 99), but for some query results that
+ contained three-character hours, column values were truncated.
+ (Bug #19844)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ For table-format output, mysql did not always calculate
+ columns widths correctly for columns containing multi-byte
+ characters in the column name or contents. (Bug #17939)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Views could not be updated within a stored function or
+ trigger. (Bug #17591)
+ </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>
+ 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>
+ When using tables created under MySQL 4.1 with a 5.0 server,
+ if the tables contained <literal>VARCHAR</literal> columns,
+ for some queries the metadata sent to the client could have an
+ empty column name. (Bug #14897)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ On 64-bit systems, use of the <literal>cp1250</literal>
+ character set with a primary key column in a
+ <literal>LIKE</literal> clause caused a server crash for
+ patterns having letters in the range 128..255. (Bug #19741)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
A subquery in the <literal>WHERE</literal> clause of the outer
query and using <literal>IN</literal> and <literal>GROUP
BY</literal> returned an incorrect result. (Bug #16255)
Modified: trunk/refman-5.0/news-5.0.xml
===================================================================
--- trunk/refman-5.0/news-5.0.xml 2006-09-12 00:06:56 UTC (rev 3328)
+++ trunk/refman-5.0/news-5.0.xml 2006-09-12 01:46:47 UTC (rev 3329)
Changed blocks: 1, Lines Added: 51, Lines Deleted: 0; 2182 bytes
@@ -369,6 +369,57 @@
<listitem>
<para>
+ For <literal>TIME_FORMAT()</literal>, the
+ <literal>%H</literal> and <literal>%k</literal> format
+ specifiers can return values larger than two digits (if the
+ hour is greater than 99), but for some query results that
+ contained three-character hours, column values were truncated.
+ (Bug #19844)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ For table-format output, mysql did not always calculate
+ columns widths correctly for columns containing multi-byte
+ characters in the column name or contents. (Bug #17939)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Views could not be updated within a stored function or
+ trigger. (Bug #17591)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Some user-level level errors were being written to the
+ server's error log, which is for server errors. (Bug #20402)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ When using tables created under MySQL 4.1 with a 5.0 server,
+ if the tables contained <literal>VARCHAR</literal> columns,
+ for some queries the metadata sent to the client could have an
+ empty column name. (Bug #14897)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ On 64-bit systems, use of the <literal>cp1250</literal>
+ character set with a primary key column in a
+ <literal>LIKE</literal> clause caused a server crash for
+ patterns having letters in the range 128..255. (Bug #19741)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
<literal>N'xxx'</literal> and <literal>_utf8'xxx'</literal>
were not treated as equivalent because
<literal>N'xxx'</literal> failed to unescape backslashes
Modified: trunk/refman-5.1/news-5.1.xml
===================================================================
--- trunk/refman-5.1/news-5.1.xml 2006-09-12 00:06:56 UTC (rev 3328)
+++ trunk/refman-5.1/news-5.1.xml 2006-09-12 01:46:47 UTC (rev 3329)
Changed blocks: 1, Lines Added: 19, Lines Deleted: 0; 1156 bytes
@@ -648,6 +648,25 @@
<listitem>
<para>
+ to the client could have an empty column name. When using
+ tables created under MySQL 4.1 with a 5.0 server, if the
+ tables contained <literal>VARCHAR</literal> columns, for some
+ queries the metadata sent to the client could have an empty
+ column name. (Bug #14897)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ On 64-bit systems, use of the <literal>cp1250</literal>
+ character set with a primary key column in a
+ <literal>LIKE</literal> clause caused a server crash for
+ patterns having letters in the range 128..255. (Bug #19741)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
<literal>ORDER BY RAND() LIMIT 1</literal> always set a user
variable to the last possible value from the table. (Bug
#16861)
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r3329 - in trunk: refman-4.1 refman-5.0 refman-5.1 | paul | 12 Sep |
