bk commit - mysqldoc@docsrva tree (marko:1.3581)

[Marko Mäkelä]

Below is the list of changes that have just been committed into a local
mysqldoc repository of marko. When marko 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.3581 05/09/16 16:27:42 marko@stripped +3 -0
  innodb-foreign-key-constraints: try to clarify the impact of
  not having deferred constraint checking (Bug #12449)

  refman/innodb.xml
    1.41 05/09/16 16:27:40 marko@stripped +6 -2
    innodb-foreign-key-constraints: try to clarify the impact of
    not having deferred constraint checking

  refman-5.0/innodb.xml
    1.27 05/09/16 16:27:40 marko@stripped +6 -2
    innodb-foreign-key-constraints: try to clarify the impact of
    not having deferred constraint checking

  refman-4.1/innodb.xml
    1.33 05/09/16 16:27:40 marko@stripped +6 -2
    innodb-foreign-key-constraints: try to clarify the impact of
    not having deferred constraint checking

# 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:	marko
# Host:	hundin.mysql.fi
# Root:	/home/marko/mysqldoc

--- 1.32/refman-4.1/innodb.xml	2005-09-15 21:24:18 +03:00
+++ 1.33/refman-4.1/innodb.xml	2005-09-16 16:27:40 +03:00
@@ -2152,8 +2152,12 @@
         deletes, or updates many rows, InnoDB checks
         <literal>UNIQUE</literal> and <literal>FOREIGN KEY</literal>
         constraints row-by-row. According to the SQL standard, the
-        default behavior should be that constraints are only checked
-        after the WHOLE SQL statement has been processed.
+        default behavior should be deferred checking, that is,
+        constraints are only checked after the <emphasis
+        role="bold">whole SQL statement</emphasis> has been processed.
+        Until InnoDB implements deferred constraint checking, some
+        things will be impossible, such as deleting a record that
+        refers to itself via a foreign key.
       </para>
 
       <para>

--- 1.40/refman/innodb.xml	2005-09-15 21:24:19 +03:00
+++ 1.41/refman/innodb.xml	2005-09-16 16:27:40 +03:00
@@ -2289,8 +2289,12 @@
         deletes, or updates many rows, InnoDB checks
         <literal>UNIQUE</literal> and <literal>FOREIGN KEY</literal>
         constraints row-by-row. According to the SQL standard, the
-        default behavior should be that constraints are only checked
-        after the WHOLE SQL statement has been processed.
+        default behavior should be deferred checking, that is,
+        constraints are only checked after the <emphasis
+        role="bold">whole SQL statement</emphasis> has been processed.
+        Until InnoDB implements deferred constraint checking, some
+        things will be impossible, such as deleting a record that
+        refers to itself via a foreign key.
       </para>
 
       <para>

--- 1.26/refman-5.0/innodb.xml	2005-09-15 21:24:19 +03:00
+++ 1.27/refman-5.0/innodb.xml	2005-09-16 16:27:40 +03:00
@@ -2160,8 +2160,12 @@
         deletes, or updates many rows, InnoDB checks
         <literal>UNIQUE</literal> and <literal>FOREIGN KEY</literal>
         constraints row-by-row. According to the SQL standard, the
-        default behavior should be that constraints are only checked
-        after the WHOLE SQL statement has been processed.
+        default behavior should be deferred checking, that is,
+        constraints are only checked after the <emphasis
+        role="bold">whole SQL statement</emphasis> has been processed.
+        Until InnoDB implements deferred constraint checking, some
+        things will be impossible, such as deleting a record that
+        refers to itself via a foreign key.
       </para>
 
       <para>