Bug#23556: TRUNCATE TABLE still maps to DELETE

 This is the 5.0 part of the fix.
 Currently TRUNCATE command will not call
 delete_all_rows() in the handler (that implements
 the "fast" TRUNCATE for InnoDB) when there are
 triggers on the table.
 As decided by the architecture team TRUNCATE must
 use "fast" TRUNCATE even when there are triggers.
 Thus it must ignore the triggers. 
 Made TRUNCATE to ignore the triggers and call
 delete_all_rows() for all storage engines
 to maintain engine consistency.


mysql-test/r/trigger.result:
  Bug#23556: TRUNCATE TABLE still maps to DELETE
   - test case
mysql-test/t/trigger.test:
  Bug#23556: TRUNCATE TABLE still maps to DELETE
   - test case
sql/sql_delete.cc:
  Bug#23556: TRUNCATE TABLE still maps to DELETE
   - We implemenent fast TRUNCATE for InnoDB even
     if triggers are present.  
   - TRUNCATE ignores triggers.

1 files changed, 5 insertions, 1 deletions

diff --git a/sql/sql_delete.cc b/sql/sql_delete.cc
index e13e7728708..0d47c2a2623 100644
--- a/sql/sql_delete.cc
+++ b/sql/sql_delete.cc
@@ -76,10 +76,14 @@ bool mysql_delete(THD *thd, TABLE_LIST *table_list, COND *conds,
     Test if the user wants to delete all rows and deletion doesn't have
     any side-effects (because of triggers), so we can use optimized
     handler::delete_all_rows() method.
+    We implement fast TRUNCATE for InnoDB even if triggers are present. 
+    TRUNCATE ignores triggers.
   */
   if (!using_limit && const_cond && (!conds || conds->val_int()) &&
       !(specialflag & (SPECIAL_NO_NEW_FUNC | SPECIAL_SAFE_MODE)) &&
-      !(table->triggers && table->triggers->has_delete_triggers()))
+      (thd->lex->sql_command == SQLCOM_TRUNCATE ||
+       !(table->triggers && table->triggers->has_delete_triggers()))
+     )
   {
     deleted= table->file->records;
     if (!(error=table->file->delete_all_rows()))