An error occurred fetching the project authors.
  1. 21 Jun, 2006 1 commit
  2. 19 Jun, 2006 1 commit
  3. 15 Jun, 2006 1 commit
  4. 31 May, 2006 1 commit
  5. 29 May, 2006 2 commits
  6. 26 May, 2006 1 commit
    • grog@mysql.com's avatar
      mysqldump.result: · 01c1eaa2
      grog@mysql.com authored
        Get output from modified test (dropping t1).
      mysqldump.test:
        Drop t1 at end so that the next test doesn't trip over it.
      01c1eaa2
  7. 25 May, 2006 1 commit
  8. 19 May, 2006 1 commit
  9. 11 May, 2006 1 commit
  10. 10 May, 2006 1 commit
  11. 04 May, 2006 2 commits
    • monty@mysql.com's avatar
      After merge fixes · 86b2be8d
      monty@mysql.com authored
      Remove compiler warnings
      Fix some broken tests
      Workaround for syncronization bug in NDB (Bug #16445)
      86b2be8d
    • tnurnberg@mysql.com's avatar
      Bug#19025 4.1 mysqldump doesn't correctly dump "auto_increment = [int]" · 5becb110
      tnurnberg@mysql.com 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.
      5becb110
  12. 10 Mar, 2006 1 commit
  13. 09 Mar, 2006 1 commit
  14. 02 Mar, 2006 1 commit
    • anozdrin@mysql.com's avatar
      Implementation of WL#2897: Complete definer support in the stored routines. · fbb59203
      anozdrin@mysql.com authored
      The idea is to add DEFINER-clause in CREATE PROCEDURE and CREATE FUNCTION
      statements. Almost all support of definer in stored routines had been already
      done before this patch.
      
      NOTE: this patch changes behaviour of dumping stored routines in mysqldump.
      Before this patch, mysqldump did not dump DEFINER-clause for stored routines
      and this was documented behaviour. In order to get full information about stored
      routines, one should have dumped mysql.proc table. This patch changes this
      behaviour, so that DEFINER-clause is dumped.
      
      Since DEFINER-clause is not supported in CREATE PROCEDURE | FUNCTION statements
      before this patch, the clause is covered by additional version-specific comments.
      fbb59203
  15. 24 Feb, 2006 1 commit
  16. 22 Feb, 2006 1 commit
  17. 21 Feb, 2006 2 commits
  18. 20 Feb, 2006 1 commit
  19. 17 Feb, 2006 2 commits
  20. 14 Feb, 2006 1 commit
  21. 13 Feb, 2006 1 commit
  22. 09 Feb, 2006 1 commit
  23. 12 Jan, 2006 1 commit
  24. 10 Jan, 2006 1 commit
  25. 31 Dec, 2005 1 commit
    • bar@mysql.com's avatar
      WL#1324 table name to file name encoding · 6ff21132
      bar@mysql.com authored
      - Encoding itself, implemented as a charset
        "filename". Originally planned to use '.'
        as an escape character, but now changed to '@'
        for two reasons: "ls" does not return
        file names starting with '.' considering them
        as a kind of hidden files; some platforms
        do not allow several dots in a file name.
      - replacing many calls of my_snprintf() and
        strnxmov() to the new build_table_filename().
      - Adding MY_APPEND_EXT mysys flag, to append
        an extention rather that replace it.
      - Replacing all numeric constants in fn_format
        flag arguments to their mysys definitions, e.g.
        MY_UNPACK_FILENAME,
      - Predictability in several function/methods:
        when a table name can appear with or withot .frm
        extension. Some functions/methods were changed
        so accept names strictly with .frm, other - strictly
        without .frm extensions. Several DBUG_ASSERTs were
        added to check whether an extension is passed.
      Many files:
        table name to file name encoding
      mysql_priv.h:
        Prototypes for new table name encoding tools.
      ctype-utf8.c:
        Implementing "filename" charset for
        table name to file name encoding.
      row0mysql.c:
        Fixing table name prefix.
      mf_format.c:
        Adding MY_APPEND_EXT processing.
      Many files:
        Fixing tests.
      my_sys.h:
        Adding new flag to append rather than replace an extension.
      m_ctype.h:
        Adding "filename" charset definition.
      6ff21132
  26. 02 Dec, 2005 1 commit
  27. 01 Dec, 2005 1 commit
  28. 24 Nov, 2005 3 commits
  29. 21 Nov, 2005 1 commit
  30. 10 Nov, 2005 2 commits
  31. 04 Nov, 2005 1 commit
  32. 27 Oct, 2005 1 commit
  33. 25 Oct, 2005 1 commit
    • patg@krsna.patg.net's avatar
      BUG# 12123 · 7243b7bb
      patg@krsna.patg.net authored
      Made change to mysqlimport to set character_set_database to binary to 
      make importing various charsets/columns work correctly.
      7243b7bb