bk commit - mysqldoc@docsrva tree (paul:1.3367)

[paul]

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/Installing_source_tree.html

ChangeSet
  1.3367 05/08/23 11:59:04 paul@stripped +1 -0
  news-5.0.xml:
    5.0.3 change note.

  refman-common/news-5.0.xml
    1.79 05/08/23 11:58:44 paul@stripped +24 -16
    5.0.3 change note.

# 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:	frost.snake.net
# Root:	/Volumes/frost2/MySQL/bk/mysqldoc

--- 1.78/refman-common/news-5.0.xml	2005-08-23 10:36:51 -05:00
+++ 1.79/refman-common/news-5.0.xml	2005-08-23 11:58:44 -05:00
@@ -1553,14 +1553,15 @@
           and collation, causing server crashes for stored procedure
           operations if the server was using a multi-byte character set.
           To take advantage of the bug fix,
-          <command>mysql_fix_privilege_tables</command> should be run
-          to correct the structure of the <literal>mysql.proc</literal>
+          <command>mysql_fix_privilege_tables</command> should be run to
+          correct the structure of the <literal>mysql.proc</literal>
           table. (Bug #11365)
         </para>
+
         <para>
           Note that it is <emphasis>necessary</emphasis> to run
-          <command>mysql_fix_privileges_tables</command>
-          when upgrading from a previous installation that contains the
+          <command>mysql_fix_privileges_tables</command> when upgrading
+          from a previous installation that contains the
           <literal>mysql.proc</literal> table (that is, from a previous
           5.0 installation). Otherwise, creating stored procedures might
           not work.
@@ -4510,8 +4511,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>
@@ -4810,14 +4811,8 @@
 
     <remark role="note">
       References to bug numbers should be written after the sentence
-    </remark>
-
-    <remark role="note">
-      describing the bugfix, like this:
-    </remark>
-
-    <remark role="note">
-      This sentence describes the fix. (Bug #nnnn)
+      describing the bugfix, like this: This sentence describes the fix.
+      (Bug #nnnn)
     </remark>
 
     <para>
@@ -4828,6 +4823,19 @@
 
       <listitem>
         <para>
+          Additional control over transaction completion was
+          implemented. The <literal>COMMIT</literal> and
+          <literal>ROLLBACK</literal> statements support <literal>AND
+          [NO] CHAIN</literal> and <literal>RELEASE</literal> clauses.
+          There is a new <literal>RELEASE SAVEPOINT</literal> statement.
+          The <literal>completion_type</literal> system variable was
+          added for setting the global and session default completion
+          type.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
           New privilege <literal>CREATE USER</literal> was added.
         </para>
       </listitem>
@@ -5390,8 +5398,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