1. 04 May, 2006 22 commits
    • unknown's avatar
      Merge jamppa@bk-internal.mysql.com:/home/bk/mysql-5.0 · 43876431
      unknown authored
      into  hundin.mysql.fi:/home/jani/mysql-5.0merge_4_1
      
      
      43876431
    • unknown's avatar
      Fixed a test case that got broken during merge. · 7c9f5a8d
      unknown authored
      7c9f5a8d
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0 · 94964da3
      unknown authored
      into  mysql.com:/home/my/mysql-5.0
      
      
      94964da3
    • unknown's avatar
      Merge ua141d10.elisa.omakaista.fi:/home/my/bk/mysql-4.1 · f31cb5dd
      unknown authored
      into  ua141d10.elisa.omakaista.fi:/home/my/bk/mysql-5.0
      
      
      mysql-test/r/gis-rtree.result:
        Auto merged
      mysql-test/r/ansi.result:
        Merged from 4.1
      mysql-test/r/auto_increment.result:
        Merged from 4.1
      mysql-test/r/mysqldump.result:
        Merged from 4.1
      mysql-test/r/symlink.result:
        Merged from 4.1
      mysql-test/t/auto_increment.test:
        Merged from 4.1
      mysql-test/t/mysqldump.test:
        Merged from 4.1
      sql/set_var.cc:
        Merged from 4.1
      sql/sql_show.cc:
        Merged from 4.1
      f31cb5dd
    • unknown's avatar
      Merge monty@192.168.0.9:/my/mysql-5.0 · 8f1ed0aa
      unknown authored
      into  mysql.com:/home/my/mysql-5.0
      
      
      8f1ed0aa
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0 · 897f6158
      unknown authored
      into  mysql.com:/home/my/mysql-5.0
      
      
      897f6158
    • unknown's avatar
      Fixed an (unlikely) memory leak · d43731e2
      unknown authored
      d43731e2
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0 · fb83bfc7
      unknown authored
      into  mysql.com:/home/my/mysql-5.0
      
      
      fb83bfc7
    • unknown's avatar
      Merge jamppa@bk-internal.mysql.com:/home/bk/mysql-5.0 · 8570020c
      unknown authored
      into  ua141d10.elisa.omakaista.fi:/home/my/bk/mysql-5.0
      
      
      8570020c
    • unknown's avatar
      Added test case for Bug#18712: Truncation problem. The test · 231f4964
      unknown authored
      is only to make sure that this will not be fixed, as it is
      intended behaviour. Documentation will be improved accordingly.
      
      
      231f4964
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0 · 63791773
      unknown authored
      into  mysql.com:/home/my/mysql-5.0
      
      
      63791773
    • unknown's avatar
      Fixed memory leak in sql_parse.cc (lex_end() was not called) · 93db6d4a
      unknown authored
      This caused sp-vars.test to fail
      
      
      sql/item_func.h:
        Removed compiler warning
      sql/sp.cc:
        Fixed memory leak in sql_parse.cc
      sql/sp_head.cc:
        Fixed memory leak in sql_parse.cc
      sql/sp_head.h:
        Fixed memory leak in sql_parse.cc
      93db6d4a
    • unknown's avatar
      Merge rurik.mysql.com:/home/igor/mysql-5.0 · 1798edaf
      unknown authored
      into  rurik.mysql.com:/home/igor/dev/mysql-5.0-0
      
      
      1798edaf
    • unknown's avatar
      Fixed heap_btree test failure on 64-bit boxes. · 473ad8c9
      unknown authored
      473ad8c9
    • unknown's avatar
      Merge jamppa@bk-internal.mysql.com:/home/bk/mysql-4.1 · ac941700
      unknown authored
      into  hundin.mysql.fi:/home/jani/mysql-4.1
      
      
      sql/sql_show.cc:
        Auto merged
      ac941700
    • unknown's avatar
      Merge tnurnberg@bk-internal.mysql.com:/home/bk/mysql-4.1 · 66d4b40c
      unknown authored
      into  mysql.com:/home/mysql-4.1-19025e
      
      
      66d4b40c
    • unknown's avatar
      Merge abotchkov@bk-internal.mysql.com:/home/bk/mysql-5.0 · a766cf91
      unknown authored
      into mysql.com:/home/hf/work/mysql-5.0.mrg
      
      
      a766cf91
    • unknown's avatar
      Merge mysql.com:/home/hf/work/mysql-4.1.mrg · 1d8a1711
      unknown authored
      into mysql.com:/home/hf/work/mysql-5.0.mrg
      
      
      mysql-test/mysql-test-run.pl:
        Auto merged
      mysql-test/r/mysqltest.result:
        Auto merged
      sql/sql_table.cc:
        Auto merged
      1d8a1711
    • unknown's avatar
      test result fixed · 812a82ed
      unknown authored
      
      mysql-test/r/mysqltest.result:
        result fixed
      812a82ed
    • unknown's avatar
      Post-review changes. · 0a78d0aa
      unknown authored
      0a78d0aa
    • unknown's avatar
      Merge rurik.mysql.com:/home/igor/mysql-5.0 · ad370e3d
      unknown authored
      into  rurik.mysql.com:/home/igor/dev/mysql-5.0-0
      
      
      mysql-test/r/subselect.result:
        Auto merged
      sql/mysql_priv.h:
        Auto merged
      sql/sql_select.cc:
        Auto merged
      ad370e3d
    • unknown's avatar
      Bug#19025 4.1 mysqldump doesn't correctly dump "auto_increment = [int]" · d300ceea
      unknown authored
      mysqldump / SHOW CREATE TABLE will show the NEXT available value for
      the PK, rather than the *first* one that was available (that named in
      the original CREATE TABLE ... AUTO_INCREMENT = ... statement).
      
      This should produce correct and robust behaviour for the obvious use
      cases -- when no data were inserted, then we'll produce a statement
      featuring the same value the original CREATE TABLE had; if we dump
      with values, INSERTing the values on the target machine should set the
      correct next_ID anyway (and if not, we'll still have our AUTO_INCREMENT =
      ... to do that). Lastly, just the CREATE statement (with no data) for
      a table that saw inserts would still result in a table that new values
      could safely be inserted to).
      
      There seems to be no robust way however to see whether the next_ID
      field is > 1 because it was set to something else with CREATE TABLE
      ... AUTO_INCREMENT = ..., or because there is an AUTO_INCREMENT column
      in  the table (but no initial value was set with AUTO_INCREMENT = ...)
      and then one or more rows were INSERTed, counting up next_ID. This
      means that in both cases, we'll generate an AUTO_INCREMENT =
      ... clause in SHOW CREATE TABLE / mysqldump.  As we also show info on,
      say, charsets even if the user did not explicitly give that info in
      their own CREATE TABLE, this shouldn't be an issue.
      
      As per above, the next_ID will be affected by any INSERTs that have
      taken place, though.  This /should/ result in correct and robust
      behaviour, but it may look non-intuitive to some users if they CREATE
      TABLE ... AUTO_INCREMENT = 1000 and later (after some INSERTs) have
      SHOW CREATE TABLE give them a different value (say, CREATE TABLE
      ... AUTO_INCREMENT = 1006), so the docs should possibly feature a
      caveat to that effect.
      
      It's not very intuitive the way it works now (with the fix), but it's
      *correct*.  We're not storing the original value anyway, if we wanted
      that, we'd have to change on-disk representation?
      
      If we do dump/load cycles with empty DBs, nothing will change.  This
      changeset includes an additional test case that proves that tables
      with rows will create the same next_ID for AUTO_INCREMENT = ... across
      dump/restore cycles.
      
      Confirmed by support as likely solution for client's problem.
      
      
      mysql-test/r/auto_increment.result:
        test for creation of AUTO_INCREMENT=... clause
      mysql-test/r/gis-rtree.result:
        Add AUTO_INCREMENT=... clauses where appropriate
      mysql-test/r/mysqldump.result:
        show that AUTO_INCREMENT=... will survive dump/restore cycles
      mysql-test/r/symlink.result:
        Add AUTO_INCREMENT=... clauses where appropriate
      mysql-test/t/auto_increment.test:
        test for creation of AUTO_INCREMENT=... clause
      mysql-test/t/mysqldump.test:
        show that AUTO_INCREMENT=... will survive dump/restore cycles
      sql/sql_show.cc:
        Add AUTO_INCREMENT=... to output of SHOW CREATE TABLE if there is an
        AUTO_INCREMENT column, and NEXT_ID > 1 (the default).  We must not print
        the clause for engines that do not support this as it would break the
        import of dumps, but as of this writing, the test for whether
        AUTO_INCREMENT columns are allowed and wether AUTO_INCREMENT=...
        is supported is identical, !(file->table_flags() & HA_NO_AUTO_INCREMENT))
        Because of that, we do not explicitly test for the feature,
        but may extrapolate its existence from that of an AUTO_INCREMENT column.
      d300ceea
  2. 03 May, 2006 18 commits