1. 04 Feb, 2004 12 commits
  2. 03 Feb, 2004 11 commits
  3. 02 Feb, 2004 5 commits
  4. 01 Feb, 2004 6 commits
    • heikki@hundin.mysql.fi's avatar
      rpl_insert_id.test, rpl_insert_id.result: · be760bec
      heikki@hundin.mysql.fi authored
        Change tests so that tables are dropped in an order respecting the FOREIGN KEY constraints
      be760bec
    • heikki@hundin.mysql.fi's avatar
      innodb.result, innodb.test: · 77d60aa6
      heikki@hundin.mysql.fi authored
        Change tests so that tables are dropped in an order respecting the FOREIGN KEY constraints
      77d60aa6
    • heikki@hundin.mysql.fi's avatar
      dict0dict.c: · 7e19a8ee
      heikki@hundin.mysql.fi authored
        Change print format of FOREIGN KEY constraints spanning multiple databases to <backquote>databasename<backquote>.<backquote>tablename<backquote>; but when parsing them we must also accept <backquote>databasename.tablename<backquote>, because that was the output format in < 4.0.18
      7e19a8ee
    • heikki@hundin.mysql.fi's avatar
      dict0dict.c: · b382ee2c
      heikki@hundin.mysql.fi authored
        Change print format of FOREIGN KEY constraints spanning multiple databases to: .; but we when parsing them we must also accept , because that was the output format in < 4.0.18
      b382ee2c
    • heikki@hundin.mysql.fi's avatar
      dict0dict.c: · 7533b0cf
      heikki@hundin.mysql.fi authored
        Remove redundant code; parse both the database name and the table name in a FOREIGN KEY constraint with quotes in mind
      row0mysql.c, ha_innodb.cc, sql_table.cc:
        Return error message Cannot delete or update a parent row... if we try to drop a table which is referenced by a FOREIGN KEY constraint, and the user has not set foreign_key_checks=0
      7533b0cf
    • heikki@hundin.mysql.fi's avatar
      dict0dict.c: · 0216948c
      heikki@hundin.mysql.fi authored
        Cleanup
      0216948c
  5. 30 Jan, 2004 5 commits
  6. 29 Jan, 2004 1 commit
    • guilhem@mysql.com's avatar
      Fix for BUG#2477 "Slave stop with error after master reboot if use HEAP tables": · e71325ca
      guilhem@mysql.com authored
      when we open the HEAP table for the first time since server restart,
      in hp_open(), we set a flag to propagate this info to the handler level
      which then writes a DELETE FROM this_heap_table to the binlog.
      It is not a perfect solution for the bug, because between the server start and 
      the first open of the table, the slave still had old data in his table so
      a SELECT on the slave may show wrong content. But if there is a --init-file
      to populate the HEAP table on master as startup, then this is a safe fix
      (I'll put a note about init-file in the HEAP section of the manual).
      e71325ca