bk commit - mysqldoc@docsrva tree (paul:1.3132) -
07-26-2005
, 03:31 PM
Below is the list of changes that have just been committed into a local
mysqldoc repository of paul. When paul does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Install...urce_tree.html
ChangeSet
1.3132 05/07/26 15:31:29 paul (AT) kite-hub (DOT) kitebird.com +2 -0
news-5.0.xml:
Document bugfix. (Bug #11685)
Document bugfix. (Bug #6120)
news-5.0.xml, news-4.1.xml:
Document bugfix. (Bug #11299)
Document bugfix. (Bug #10201)
refman-common/news-5.0.xml
1.12 05/07/26 15:29:03 paul (AT) kite-hub (DOT) kitebird.com +8 -0
Document bugfix. (Bug #11685)
refman-common/news-5.0.xml
1.11 05/07/26 15:22:32 paul (AT) kite-hub (DOT) kitebird.com +8 -0
Document bugfix. (Bug #6120)
refman-common/news-5.0.xml
1.10 05/07/26 15:16:01 paul (AT) kite-hub (DOT) kitebird.com +11 -0
Document bugfix. (Bug #11299)
refman-common/news-4.1.xml
1.6 05/07/26 15:15:48 paul (AT) kite-hub (DOT) kitebird.com +20 -7
Document bugfix. (Bug #11299)
refman-common/news-5.0.xml
1.9 05/07/26 14:56:12 paul (AT) kite-hub (DOT) kitebird.com +8 -0
Document bugfix. (Bug #10201)
refman-common/news-4.1.xml
1.5 05/07/26 14:56:01 paul (AT) kite-hub (DOT) kitebird.com +8 -0
Document bugfix. (Bug #10201)
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: paul
# Host: kite-hub.kitebird.com
# Root: /src/extern/MySQL/bk/mysqldoc
--- 1.4/refman-common/news-4.1.xml 2005-07-26 00:32:32 -05:00
+++ 1.6/refman-common/news-4.1.xml 2005-07-26 15:15:48 -05:00
@@ -190,6 +190,25 @@
<listitem>
<para>
+ For prepared statements, the SQL parser did not disallow
+ ‘<literal>?</literal>’ parameter markers
+ immediately adjacent to other tokens, which could result in
+ malformed statements in the binary log. (For example,
+ <literal>SELECT * FROM t WHERE? = 1</literal> could become
+ <literal>SELECT * FROM t WHERE0 = 1</literal>.) (Bug #11299)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>GROUP_CONCAT()</literal> sometimes returned a result
+ with a different collation that that of its arguments. (Bug
+ #10201)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
When two threads compete for the same table, a deadlock could
occur if one thread has also a lock on another table through
<literal>LOCK TABLES</literal> and the thread is attempting to
@@ -202,7 +221,8 @@
<para>
Incorrect error message displayed if user attempted to create
a table in a non-existing database using <literal>CREATE
- <replaceable>database_name</replaceable>.<replaceable>table_name</replaceable></literal> syntax. (Bug #10407)
+ <replaceable>database_name</replaceable>.<replaceable>table_name</replaceable></literal>
+ syntax. (Bug #10407)
</para>
</listitem>
@@ -1345,10 +1365,11 @@
and isolation level of the transaction is not set to
serializable then <literal>InnoDB</literal> uses a consistent
read for select in clauses like <literal>INSERT
- INTO…SELECT</literal> and <literal>UPDATE…(SELECT)</literal>
- that do not specify <literal>FOR UPDATE</literal> or
- <literal>IN SHARE MODE</literal>. Thus no locks are set to
- rows read from selected table.
+ INTO…SELECT</literal> and
+ <literal>UPDATE…(SELECT)</literal> that do not specify
+ <literal>FOR UPDATE</literal> or <literal>IN SHARE
+ MODE</literal>. Thus no locks are set to rows read from
+ selected table.
</para>
</listitem>
@@ -3119,8 +3140,8 @@
<listitem>
<para>
InnoDB: Relaxed locking in <literal>INSERT…SELECT</literal>,
- single table <literal>UPDATE…SELECT</literal> and single table
- <literal>DELETE…SELECT</literal> clauses when
+ single table <literal>UPDATE…SELECT</literal> and single
+ table <literal>DELETE…SELECT</literal> clauses when
<literal>innodb_locks_unsafe_for_binlog</literal> is used and
isolation level of the transaction is not serializable.
<literal>InnoDB</literal> uses consistent read in these cases
--- 1.8/refman-common/news-5.0.xml 2005-07-26 14:41:42 -05:00
+++ 1.12/refman-common/news-5.0.xml 2005-07-26 15:29:03 -05:00
@@ -199,6 +199,14 @@
<listitem>
<para>
+ <literal>GROUP_CONCAT()</literal> sometimes returned a result
+ with a different collation that that of its arguments. (Bug
+ #10201)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
The <literal>LPAD()</literal> and <literal>RPAD()</literal>
functions returned the wrong length to
<literal>mysql_fetch_fields()</literal>. (Bug #11311)
@@ -348,6 +356,33 @@
</para>
<itemizedlist>
+
+ <listitem>
+ <para>
+ Execution of <literal>SHOW TABLES</literal> failed to
+ increment the <literal>Com_show_tables</literal> status
+ variable. (Bug #11685)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ For execution of a stored procedure that refers to a view,
+ changes to the view definition were not seen. The procedure
+ continued to see the old contents of the view. (Bug #6120)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ For prepared statements, the SQL parser did not disallow
+ ‘<literal>?</literal>’ parameter markers
+ immediately adjacent to other tokens, which could result in
+ malformed statements in the binary log. (For example,
+ <literal>SELECT * FROM t WHERE? = 1</literal> could become
+ <literal>SELECT * FROM t WHERE0 = 1</literal>.) (Bug #11299)
+ </para>
+ </listitem>
<listitem>
<para>
--
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe: http://lists.mysql.com/internals?uns...ie.nctu.edu.tw |