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''