An error occurred fetching the project authors.
  1. 19 Jun, 2006 1 commit
  2. 15 Jun, 2006 1 commit
  3. 30 May, 2006 1 commit
    • tnurnberg@mysql.com's avatar
      Bug#17371: Unable to dump a schema with invalid views · c7ae355d
      tnurnberg@mysql.com authored
      'show create' works even on views that are short of a base-table (this
      throw a warning though, like you would expect). Unfortunately, this is
      not what mysqldump uses; it creates stand-in tables and hence requests
      'show fields' on the view which fails with missing base-tables.  The
      --force option prevents the dump from stopping at this point; furthermore
      this patch dumps a comment showing create for the offending view for
      better diagnostics. This solution was confirmed by submitter as solving
      their/clients' problem. Problem might become non-issue once mysqldump no
      longer creates stand-in tables.
      c7ae355d
  4. 29 May, 2006 2 commits
  5. 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
  6. 25 May, 2006 1 commit
  7. 19 May, 2006 1 commit
  8. 11 May, 2006 1 commit
  9. 04 May, 2006 1 commit
    • 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
  10. 10 Mar, 2006 1 commit
  11. 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
  12. 21 Feb, 2006 2 commits
  13. 17 Feb, 2006 1 commit
  14. 09 Feb, 2006 1 commit
  15. 12 Jan, 2006 1 commit
  16. 10 Jan, 2006 1 commit
  17. 01 Dec, 2005 1 commit
  18. 24 Nov, 2005 1 commit
  19. 21 Nov, 2005 1 commit
  20. 10 Nov, 2005 2 commits
  21. 04 Nov, 2005 1 commit
  22. 27 Oct, 2005 1 commit
  23. 25 Oct, 2005 2 commits
    • 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
    • pgalbraith@mysql.com's avatar
      This cset fixes BUG# 12838, 14061, 12129 · feca138e
      pgalbraith@mysql.com authored
      mysqldump.result:
        BUG# 12838
            New test results for mysqldump -x on a DB with views
      mysqldump.test:
        sqldump.test:
            BUG# 12838
            New test to run mysqldump -x on a DB with views
      mysqldump.c:
        BUG# 12838
            Removed/Changed code which created tables to be put into the dump
            (For loading views of views) by creating temp tables and then using
            the CREATE TABLE information in those temp tables. The problem with this
            is that when mysqldump -x is called, it locks all tables, so the
            temp tables could not be created, causing the mysqldump to exit with
            failure. The code was changed to use SHOW FIELDS to get the column
            names and type to build CREATE TABLE text used to create these tables
            that views need in the dump.
      feca138e
  24. 13 Oct, 2005 2 commits
    • patg@krsna.patg.net's avatar
      BUG# 13146 · d86f4065
      patg@krsna.patg.net authored
      Re-application of patch to clean 5.0 tree. Fixed issue with ANSI quotes 
      when dumping triggers
      d86f4065
    • patg@krsna.patg.net's avatar
      BUG# 13052 · a46dd412
      patg@krsna.patg.net authored
      Clean application of patch - 
      - Added --tz-utc to fix issue of dumping timestamp values between 
      servers with different global time zone settings, particularly 
      with regard to the day of DST changeover, which without this fix,
       would dump duplicate timestamp values.
      a46dd412
  25. 06 Oct, 2005 1 commit
    • monty@mysql.com's avatar
      Review of code pushed since last 5.0 pull: · 78e828d3
      monty@mysql.com authored
      Ensure that ccache is also used for C programs
      mysql: Ensure that 'delimiter' works the same way in batch mode as in normal mode
      mysqldump: Change to use ;; (instead of //) as a stored procedure/trigger delimiter
      Fixed test cases by adding missing DROP's and rename views to be of type 'v#'
      Removed MY_UNIX_PATH from fn_format()
      Removed current_db_used from TABLE_LIST
      Removed usage of 'current_thd' in Item_splocal
      Removed some compiler warnings
      A bit faster longlong2str code
      78e828d3
  26. 29 Sep, 2005 1 commit
  27. 27 Sep, 2005 1 commit
  28. 14 Sep, 2005 2 commits
  29. 13 Sep, 2005 2 commits
  30. 09 Sep, 2005 2 commits
  31. 08 Sep, 2005 2 commits