1. 04 May, 2006 26 commits
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0 · 3c191100
      unknown authored
      into  mysql.com:/home/my/mysql-5.0
      
      3c191100
    • unknown's avatar
      .del-changelog-5.0.xml~f4c50926ccdd7434: · f1f4af21
      unknown authored
        Delete: Docs/changelog-5.0.xml
      
      
      BitKeeper/deleted/.del-changelog-5.0.xml~f4c50926ccdd7434:
        Delete: Docs/changelog-5.0.xml
      f1f4af21
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0 · c7e37f0a
      unknown authored
      into  mysql.com:/home/my/mysql-5.0
      
      c7e37f0a
    • unknown's avatar
      Fixed wrong free in sql_view.cc · 44fd366d
      unknown authored
      mysql-test-run now fails in case of warnings
      
      
      mysql-test/lib/mtr_report.pl:
        Fail if find warnings
      mysql-test/mysql-test-run.sh:
        Fail if find warnings
      sql/sql_lex.cc:
        Initalize st_lex properly
      sql/sql_view.cc:
        Fixed problem with unaligned memory (wrong free)
      44fd366d
    • unknown's avatar
      Merge jamppa@bk-internal.mysql.com:/home/bk/mysql-5.0 · d5103de4
      unknown authored
      into  hundin.mysql.fi:/home/jani/mysql-5.0merge_4_1
      
      d5103de4
    • unknown's avatar
      Fixed a test case that got broken during merge. · 99f7bc65
      unknown authored
      99f7bc65
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0 · b863cea3
      unknown authored
      into  mysql.com:/home/my/mysql-5.0
      
      b863cea3
    • unknown's avatar
      Merge ua141d10.elisa.omakaista.fi:/home/my/bk/mysql-4.1 · b6b05068
      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
      b6b05068
    • unknown's avatar
      Merge monty@192.168.0.9:/my/mysql-5.0 · 90126089
      unknown authored
      into  mysql.com:/home/my/mysql-5.0
      
      90126089
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0 · be1b9e85
      unknown authored
      into  mysql.com:/home/my/mysql-5.0
      
      be1b9e85
    • unknown's avatar
      Fixed an (unlikely) memory leak · b344b11b
      unknown authored
      b344b11b
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0 · 49eb84c0
      unknown authored
      into  mysql.com:/home/my/mysql-5.0
      
      49eb84c0
    • unknown's avatar
      Merge jamppa@bk-internal.mysql.com:/home/bk/mysql-5.0 · 7aed267e
      unknown authored
      into  ua141d10.elisa.omakaista.fi:/home/my/bk/mysql-5.0
      
      7aed267e
    • unknown's avatar
      Added test case for Bug#18712: Truncation problem. The test · 96b1fa1a
      unknown authored
      is only to make sure that this will not be fixed, as it is
      intended behaviour. Documentation will be improved accordingly.
      
      96b1fa1a
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0 · 4290b225
      unknown authored
      into  mysql.com:/home/my/mysql-5.0
      
      4290b225
    • unknown's avatar
      Fixed memory leak in sql_parse.cc (lex_end() was not called) · 26476672
      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
      26476672
    • unknown's avatar
      Merge rurik.mysql.com:/home/igor/mysql-5.0 · 36bfdc21
      unknown authored
      into  rurik.mysql.com:/home/igor/dev/mysql-5.0-0
      
      36bfdc21
    • unknown's avatar
      Fixed heap_btree test failure on 64-bit boxes. · 24860544
      unknown authored
      24860544
    • unknown's avatar
      Merge jamppa@bk-internal.mysql.com:/home/bk/mysql-4.1 · 029e4410
      unknown authored
      into  hundin.mysql.fi:/home/jani/mysql-4.1
      
      
      sql/sql_show.cc:
        Auto merged
      029e4410
    • unknown's avatar
      Merge tnurnberg@bk-internal.mysql.com:/home/bk/mysql-4.1 · 7c68a3ee
      unknown authored
      into  mysql.com:/home/mysql-4.1-19025e
      
      7c68a3ee
    • unknown's avatar
      Merge abotchkov@bk-internal.mysql.com:/home/bk/mysql-5.0 · 163f0bf1
      unknown authored
      into mysql.com:/home/hf/work/mysql-5.0.mrg
      
      163f0bf1
    • unknown's avatar
      Merge mysql.com:/home/hf/work/mysql-4.1.mrg · 8c243188
      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
      8c243188
    • unknown's avatar
      test result fixed · 6104ece0
      unknown authored
      
      mysql-test/r/mysqltest.result:
        result fixed
      6104ece0
    • unknown's avatar
      Post-review changes. · 102f40a7
      unknown authored
      102f40a7
    • unknown's avatar
      Merge rurik.mysql.com:/home/igor/mysql-5.0 · 3ef8178e
      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
      3ef8178e
    • unknown's avatar
      Bug#19025 4.1 mysqldump doesn't correctly dump "auto_increment = [int]" · 64828eeb
      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.
      64828eeb
  2. 03 May, 2006 14 commits