row0mysql.c:

  Allow always DROPping of a table which is only referenced by FOREIGN KEY constraints from the same table
Many files:
  Do not let REPLACE to perform internally an UPDATE if the table is referenced by a FOREIGN KEY: the manual says that REPLACE must resolve a duplicate key error semantically with DELETE(s) + INSERT, and not by an UPDATE; the internal update caused foreign key checks and cascaded operations to behave in a semantically wrong way


sql/ha_innodb.cc:
  Do not let REPLACE to perform internally an UPDATE if the table is referenced by a FOREIGN KEY: the manual says that REPLACE must resolve a duplicate key error semantically with DELETE(s) + INSERT, and not by an UPDATE; the internal update caused foreign key checks and cascaded operations to behave in a semantically wrong way
sql/sql_insert.cc:
  Do not let REPLACE to perform internally an UPDATE if the table is referenced by a FOREIGN KEY: the manual says that REPLACE must resolve a duplicate key error semantically with DELETE(s) + INSERT, and not by an UPDATE; the internal update caused foreign key checks and cascaded operations to behave in a semantically wrong way
sql/ha_innodb.h:
  Do not let REPLACE to perform internally an UPDATE if the table is referenced by a FOREIGN KEY: the manual says that REPLACE must resolve a duplicate key error semantically with DELETE(s) + INSERT, and not by an UPDATE; the internal update caused foreign key checks and cascaded operations to behave in a semantically wrong way
sql/handler.h:
  Do not let REPLACE to perform internally an UPDATE if the table is referenced by a FOREIGN KEY: the manual says that REPLACE must resolve a duplicate key error semantically with DELETE(s) + INSERT, and not by an UPDATE; the internal update caused foreign key checks and cascaded operations to behave in a semantically wrong way
innobase/dict/dict0dict.c:
  Do not let REPLACE to perform internally an UPDATE if the table is referenced by a FOREIGN KEY: the manual says that REPLACE must resolve a duplicate key error semantically with DELETE(s) + INSERT, and not by an UPDATE; the internal update caused foreign key checks and cascaded operations to behave in a semantically wrong way
innobase/include/dict0dict.h:
  Do not let REPLACE to perform internally an UPDATE if the table is referenced by a FOREIGN KEY: the manual says that REPLACE must resolve a duplicate key error semantically with DELETE(s) + INSERT, and not by an UPDATE; the internal update caused foreign key checks and cascaded operations to behave in a semantically wrong way
innobase/row/row0mysql.c:
  Allow always DROPping of a table which is only referenced by FOREIGN KEY constraints from the same table

1 files changed, 9 insertions, 1 deletions

diff --git a/sql/sql_insert.cc b/sql/sql_insert.cc
index 97b7c1db03d..4d7a9f7e508 100644
--- a/sql/sql_insert.cc
+++ b/sql/sql_insert.cc
@@ -442,7 +442,15 @@ int write_record(TABLE *table,COPY_INFO *info)
 						HA_READ_KEY_EXACT))))
 	  goto err;
       }
-      if (last_uniq_key(table,key_nr))
+      /*
+	The manual defines the REPLACE semantics that it is either an INSERT or
+	DELETE(s) + INSERT; FOREIGN KEY checks do not function in the defined
+	way if we allow MySQL to convert the latter operation internally to an
+	UPDATE.
+      */
+
+      if (last_uniq_key(table,key_nr)
+	  && !table->file->referenced_by_foreign_key())
       {
 	if ((error=table->file->update_row(table->record[1],table->record[0])))
 	  goto err;