An error occurred fetching the project authors.
  1. 13 Nov, 2006 1 commit
  2. 12 Sep, 2006 1 commit
    • timour/timka@lamia.home's avatar
      Fix for BUG#21774: Column count doesn't match value count at row x · 38a450b4
      timour/timka@lamia.home authored
      The cause of the bug was an incomplete fix for bug 18080.
      The problem was that setup_tables() unconditionally reset the
      name resolution context to its 'tables' argument, which pointed
      to the first table of an SQL statement.
      
      The bug fix limits resetting of the name resolution context in
      setup_tables() only in the cases when the context was not set
      by earlier parser/optimizer phases.
      38a450b4
  3. 02 Aug, 2006 1 commit
    • svoj@may.pils.ru's avatar
      BUG#14770 - LOAD DATA INFILE doesn't respect default values for · 6c6f435b
      svoj@may.pils.ru authored
                  columns
      Fixed confusing warning.
      
      Quoting INSERT section of the manual:
      ----
      Inserting NULL into a column that has been declared NOT NULL. For
      multiple-row INSERT statements or INSERT INTO ... SELECT statements, the
      column is set to the implicit default value for the column data type. This
      is 0 for numeric types, the empty string ('') for string types, and the
      "zero" value for date and time types. INSERT INTO ... SELECT statements are
      handled the same way as multiple-row inserts because the server does not
      examine the result set from the SELECT to see whether it returns a single
      row. (For a single-row INSERT, no warning occurs when NULL is inserted into
      a NOT NULL column. Instead, the statement fails with an error.)
      ----
      This is also true for LOAD DATA INFILE. For INSERT user can specify
      DEFAULT keyword as a value to set column default. There is no similiar
      feature available for LOAD DATA INFILE.
      6c6f435b
  4. 19 Jul, 2006 1 commit
  5. 19 Jun, 2006 2 commits
    • gkodinov@mysql.com's avatar
      Bug #18080: INSERT ... SELECT ... JOIN results in ambiguous field list error · 5508df25
      gkodinov@mysql.com authored
      There was an incomplete reset of the name resolution context, that caused 
      INSERT ... SELECT ... JOIN statements to resolve not by joint row type calculated
      for the join.
      Removed the redundant re-initialization of the context, because 
      mysql_insert_select_prepare() now correctly saves/restores the context.
      5508df25
    • gkodinov@mysql.com's avatar
      * Bug #9676: INSERT INTO x SELECT .. FROM x LIMIT 1; slows down with big · c5ed7a87
      gkodinov@mysql.com authored
                    tables
      Currently in INSERT ... SELECT ... LIMIT ... the compiler uses a 
      temporary table to store the results of SELECT ... LIMIT .. and then
      uses that table as a source for INSERT. The problem is that in some cases
      it actually skips the LIMIT clause in doing that and materializes the 
      whole SELECT result set regardless of the LIMIT.
      This fix is limiting the process of filling up the temp table with only 
      that much rows that will be actually used by propagating the LIMIT value.
      c5ed7a87
  6. 23 Jan, 2006 1 commit
  7. 01 Dec, 2005 1 commit
  8. 27 Oct, 2005 1 commit
  9. 25 Oct, 2005 1 commit
  10. 15 Sep, 2005 1 commit
  11. 09 Sep, 2005 1 commit
  12. 12 Aug, 2005 1 commit
    • timour@mysql.com's avatar
      Implementation of WL#2486 - · a247282a
      timour@mysql.com authored
      "Process NATURAL and USING joins according to SQL:2003".
      
      * Some of the main problems fixed by the patch:
        - in "select *" queries the * expanded correctly according to
          ANSI for arbitrary natural/using joins
        - natural/using joins are correctly transformed into JOIN ... ON
          for any number/nesting of the joins.
        - column references are correctly resolved against natural joins
          of any nesting and combined with arbitrary other joins.
      
      * This patch also contains a fix for name resolution of items
        inside the ON condition of JOIN ... ON - in this case items must
        be resolved only against the JOIN operands. To support such
        'local' name resolution, the patch introduces a stack of
        name resolution contexts used at parse time.
      
      NOTICE:
      - This patch is not complete in the sense that
        - there are 2 test cases that still do not pass -
          one in join.test, one in select.test. Both are marked
          with a comment "TODO: WL#2486".
        - it does not include a new test specific for the task
      a247282a
  13. 27 Jun, 2005 1 commit
    • monty@mishka.local's avatar
      Better bug fix for: · 83f90e06
      monty@mishka.local authored
      #9728  'Decreased functionality in "on duplicate key update
      #8147  'a column proclaimed ambigous in INSERT ... SELECT .. ON DUPLICATE'
      
      This ensures fields are uniquely qualified and also that one can't update other tables in the ON DUPLICATE KEY UPDATE part
      83f90e06
  14. 22 Jun, 2005 1 commit
  15. 21 Jun, 2005 1 commit
  16. 31 Mar, 2005 1 commit
  17. 16 Mar, 2005 1 commit
    • dlenev@brandersnatch.localdomain's avatar
      WL#874 "Extended LOAD DATA". · f1691140
      dlenev@brandersnatch.localdomain authored
      Now one can use user variables as target for data loaded from file
      (besides table's columns). Also LOAD DATA got new SET-clause in which
      one can specify values for table columns as expressions.
      
      For example the following is possible:
      LOAD DATA INFILE 'words.dat' INTO TABLE t1 (a, @b) SET c = @b + 1;
      
      This patch also implements new way of replicating LOAD DATA.
      Now we do it similarly to other queries.
      We store LOAD DATA query in new Execute_load_query event
      (which is last in the sequence of events representing LOAD DATA).
      When we are executing this event we simply rewrite part of query which
      holds name of file (we use name of temporary file) and then execute it
      as usual query. In the beggining of this sequence we use Begin_load_query
      event which is almost identical to Append_file event
      f1691140
  18. 16 Feb, 2005 1 commit
  19. 03 Feb, 2005 1 commit
    • guilhem@mysql.com's avatar
      WL#1062 "log charset info into all Query_log_event": · ed1696f6
      guilhem@mysql.com authored
      we store 7 bytes (1 + 2*3) in every Query_log_event.
      In the future if users want binlog optimized for small size and less safe,
      we could add --binlog-no-charset (and binlog-no-sql-mode etc): charset info
      is something by design optional (even if for now we don't offer possibility to disable it):
      it's not a binlog format change.
      We try to reduce the number of get_charset() calls in the slave SQL thread to a minimum
      by caching the charset read from the previous event (which will often be equal to the one of the current event).
      We don't use SET ONE_SHOT for charset-aware repl (we still do for timezones, will be fixed later).
      No more errors if one changes the global value of charset vars on master or slave
      (as we log charset info in all Query_log_event).
      Not fixing Load_log_event as it will be rewritten soon by Dmitri.
      Testing how mysqlbinlog behaves in rpl_charset.test.
      mysqlbinlog needs to know where charset file is (to be able to convert a charset number found
      in binlog (e.g. in User_var_log_event) to a charset name); mysql-test-run needs to pass
      the correct value for this option to mysqlbinlog.
      Many result udpates (adding charset info into every event shifts log_pos in SHOW BINLOG EVENTS).
      Roughly the same job is to be done for timezones :)
      ed1696f6
  20. 19 Jan, 2005 3 commits
    • ingo@mysql.com's avatar
      BUG#6034 - Error code 124: Wrong medium type. · ea8882be
      ingo@mysql.com authored
      Version for 5.0. Committed for merge.
      If the result table is one of the select tables in INSERT SELECT,
      we must not disable the result tables indexes before selecting.
      Now the preparation is split into two prepare methods.
      The first detects the situation and defers some preparations
      until the second phase.
      ea8882be
    • ingo@mysql.com's avatar
      BUG#6034 - Error code 124: Wrong medium type. · fd0fdcda
      ingo@mysql.com authored
      Version for 4.1. Committed for merge.
      If the result table is one of the select tables in INSERT SELECT,
      we must not disable the result tables indexes before selecting.
      mysql_execute_command() detects the match for other reasons and
      adds the flag OPTION_BUFFER_RESULT to the 'select_options'. 
      In this case the result is put into a temporary table first. 
      Hence, we can defer the preparation of the insert
      table until the result is to be used.
      fd0fdcda
    • ingo@mysql.com's avatar
      BUG#6034 - Error code 124: Wrong medium type. · 9a914a00
      ingo@mysql.com authored
      Version for 4.0. Committed for merge.
      If the result table is one of the select tables in INSERT SELECT,
      we must not disable the result tables indexes before selecting.
      mysql_execute_command() detects the match for other reasons and
      adds the flag OPTION_BUFFER_RESULT to the 'select_options'. 
      In this case the result is put into a temporary table first. 
      Hence, we can defer the preparation of the insert
      table until the result is to be used.
      9a914a00
  21. 16 Jan, 2005 1 commit
  22. 06 Dec, 2004 1 commit
  23. 03 Dec, 2004 1 commit
  24. 02 Dec, 2004 1 commit
    • jimw@mysql.com's avatar
      Prevent adding 'CREATE TABLE .. SELECT' query to the binary log when the · 13649d90
      jimw@mysql.com authored
      insertion of new records partially failed. It would get logged because of the
      logic to log a partially-failed 'INSERT ... SELECT' (which can't be rolled back
      in non-transactional tables), but 'CREATE TABLE ... SELECT' is always rolled
      back on failure, even for non-transactional tables. (Bug #6682)
      (Original fix reimplemented after review by Serg and Guilhem.)
      13649d90
  25. 02 Oct, 2004 1 commit
    • monty@mishka.local's avatar
      More fixes for strict mode: · be4ca46f
      monty@mishka.local authored
      More tests.
      Better error messages.
      Fixed bug when checking if we updated all needed columns for INSERT.
      Give an error if we encounter a wrong float value during parsing.
      Don't print DEFAULT for columns without a default value in SHOW CREATE/SHOW FIELDS.
      Fixed UPDATE IGNORE when using STRICT mode.
      be4ca46f
  26. 16 Jun, 2004 1 commit
  27. 16 Feb, 2004 1 commit
    • monty@mysql.com's avatar
      After merge fixes · f43093ec
      monty@mysql.com authored
      Added more DBUG statements
      Ensure that we are comparing end space with BINARY strings
      Use 'any_db' instead of '' to mean any database. (For HANDLER command)
      Only strip ' ' when comparing CHAR, not other space-like characters (like \t)
      f43093ec
  28. 06 Feb, 2004 1 commit
  29. 19 Dec, 2003 1 commit
    • guilhem@gbichot2's avatar
      Now merge is done. · d67bbe72
      guilhem@gbichot2 authored
      For previous commit I had run only rpl* tests, here the other ones had a 
      few surprises. Latest status:
      - all tests pass
      - all replication tests pass with Valgrind
      This is the final-final commit & push.
      Doc remains.
      d67bbe72
  30. 16 Dec, 2003 1 commit
  31. 10 Dec, 2003 1 commit
  32. 08 Oct, 2003 1 commit
  33. 29 Sep, 2003 1 commit
  34. 18 Aug, 2003 1 commit
    • monty@mashka.mysql.fi's avatar
      After merge fixes · 4f751216
      monty@mashka.mysql.fi authored
      Use server character set if --default-character-set is not used
      Added convert_string() for more efficient alloc+character-set convert of strings
      4f751216
  35. 18 Jul, 2003 1 commit
  36. 03 Jul, 2003 1 commit
  37. 01 Jul, 2003 1 commit