bk commit - mysqldoc@docsrva tree (Mike.Hillyer:1.3414)

[mhillyer]

Below is the list of changes that have just been committed into a local
mysqldoc repository of root. When root 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/Installing_source_tree.html

ChangeSet
  1.3414 05/08/29 16:08:05 Mike.Hillyer@stripped +2 -0
  Document Bugfixes: 11718,11398,10646

  refman-common/news-5.0.xml
    1.96 05/08/29 16:08:05 Mike.Hillyer@stripped +22 -4
    Document Bugfixes

  refman-common/news-4.1.xml
    1.57 05/08/29 16:08:05 Mike.Hillyer@stripped +13 -7
    Document Bugfixes

# 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:	Mike.Hillyer
# Host:	www.openwin.org
# Root:	/home/mysqldoc/mysqldoc

--- 1.56/refman-common/news-4.1.xml	2005-08-26 14:27:48 -06:00
+++ 1.57/refman-common/news-4.1.xml	2005-08-29 16:08:05 -06:00
@@ -180,6 +180,13 @@
 
       <listitem>
         <para>
+          Queries that created implicit temporary tables could return
+          incorrect column types for some columns. (Bug #11718)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
           An optimizer estimate of zero rows for a non-empty
           <literal>InnoDB</literal> table used in a left or right join
           could cause incomplete rollback for the table. (Bug #12779)
@@ -1854,11 +1861,10 @@
           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>
 
@@ -3648,8 +3654,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.95/refman-common/news-5.0.xml	2005-08-27 13:40:43 -06:00
+++ 1.96/refman-common/news-5.0.xml	2005-08-29 16:08:05 -06:00
@@ -355,6 +355,24 @@
 
       <listitem>
         <para>
+          Joins on <literal>VARCHAR</literal> columns of different
+          lengths could produce incorrect results. (Bug #11398)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          <literal>SELECT <replaceable>PK</replaceable> FROM
+          <replaceable>TableA</replaceable> INNER JOIN
+          <replaceable>TableB</replaceable>
+          USING(<replaceable>PK</replaceable>)</literal> resulted in a
+          inappropriate <literal>Column ... is ambiguous</literal>
+          error. (Bug #10646)
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
           A <quote>Duplicate column name</quote> error no longer occurs
           when selecting from a view defined as <literal>SELECT
           *</literal> from a join that uses a <literal>USING</literal>
@@ -4760,8 +4778,8 @@
           InnoDB: True <literal>VARCHAR</literal>: InnoDB stored the
           'position' of a row wrong in a column prefix primary key
           index; this could cause MySQL to complain <literal>ERROR 1032:
-          Can't find record …</literal> in an update of the primary
-          key, and also some <literal>ORDER BY</literal> or
+          Can't find record …</literal> in an update of the primary key,
+          and also some <literal>ORDER BY</literal> or
           <literal>DISTINCT</literal> queries. (Bug #9314)
         </para>
       </listitem>
@@ -5647,8 +5665,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