1. 09 Jun, 2007 1 commit
  2. 08 Jun, 2007 1 commit
  3. 07 Jun, 2007 1 commit
  4. 06 Jun, 2007 3 commits
  5. 05 Jun, 2007 2 commits
  6. 04 Jun, 2007 7 commits
  7. 03 Jun, 2007 12 commits
  8. 02 Jun, 2007 10 commits
  9. 01 Jun, 2007 3 commits
    • ibabaev@bk-internal.mysql.com's avatar
      Merge bk-internal.mysql.com:/data0/bk/mysql-5.0 · 4bc1738b
      ibabaev@bk-internal.mysql.com authored
      into  bk-internal.mysql.com:/data0/bk/mysql-5.0-opt
      4bc1738b
    • igor@olga.mysql.com's avatar
      Merge olga.mysql.com:/home/igor/mysql-5.0-opt · cf36fd11
      igor@olga.mysql.com authored
      into  olga.mysql.com:/home/igor/mysql-5.1-opt
      cf36fd11
    • evgen@moonbone.local's avatar
      Bug#28427: Columns were renamed instead of moving by ALTER TABLE. · fc01b099
      evgen@moonbone.local authored
      To avoid unnecessary work the mysql_alter_table function takes the
      list of table fields and applies all changes to it (drops/moves/renames/etc).
      Then this function compares the new list and the old one. If the changes
      require only .frm to be modified then the actual data isn't copied. To detect
      changes all columns attributes but names are compared. When a column has been
      moved and has replaced another column with the same attributes except name
      the mysql_alter_table function wrongly decides that two fields has been just
      renamed. As a result the data from the moved column and from all columns
      after it is not copied.
      
      Now the mysql_alter_table function forces table data copying by setting
      the need_copy_table flag when it finds a moved column. The flag is set at
      the stage when the modified fields are created.
      fc01b099