triggers".
Applying ALTER/OPTIMIZE/REPAIR TABLE statements to transactional table or to
table of any type on Windows caused disappearance of its triggers.
Bug was introduced in 5.0.19 by my fix for bug #13525 "Rename table does not
keep info of triggers" (see comment for sql_table.cc for more info).
.
mysql-test/r/trigger.result:
Added test-case covering handling of triggers when one does ALTER TABLE which
should move table to different database.
mysql-test/t/trigger.test:
Added test-case covering handling of triggers when one does ALTER TABLE which
should move table to different database.
sql/sql_table.cc:
mysql_alter_table():
Removal of strdup() which is no longer necessary allows us to preserve
nice assumption that "(new_db != db || new_table != table_name) indicates
that table will be renamed. So now we really can use this condition to
avoid updating trigger definitions when table is not renamed.
Note that we can't use (alter_info->flags & ALTER_RENAME) condition instead
since it can be also true when we do "ALTER TABLE t1 RENAME TO t1".
sql/sql_trigger.cc:
Table_triggers_list::change_table_name():
Mentioned assumption that subject table is not renamed to itself in method
description. Added DBUG_ASSERT() to catch wrong usage of this method.
mysql-test/r/trigger-trans.result:
New BitKeeper file ``mysql-test/r/trigger-trans.result''
mysql-test/t/trigger-trans.test:
New BitKeeper file ``mysql-test/t/trigger-trans.test''
