1. 11 May, 2006 1 commit
  2. 10 May, 2006 2 commits
  3. 09 May, 2006 1 commit
  4. 08 May, 2006 1 commit
    • unknown's avatar
      Bug#10418: LOAD_FILE does not behave like in manual if file does not exist · dd934da9
      unknown authored
      load_file() string-function should return NULL rather than throw an error if
      the file doesn't exist, as per the manual.
      
      
      mysql-test/t/outfile.test:
        expect NULL rather than error if file given to load_file() doesn't exist
      mysql-test/t/func_str.test:
        show that load_file() will return NULL rather than throw an error
        if file doesn't exist
      mysql-test/r/outfile.result:
        expect NULL rather than error if file given to load_file() doesn't exist
      mysql-test/r/func_str.result:
        expect NULL rather than error if file given to load_file() doesn't exist
      sql/item_strfunc.cc:
        load_file() should return NULL as per the docs if file not found,
        rather than throw an error
      dd934da9
  5. 07 May, 2006 3 commits
    • unknown's avatar
      Merge ibabaev@bk-internal.mysql.com:/home/bk/mysql-4.1 · e4e67d58
      unknown authored
      into  rurik.mysql.com:/home/igor/mysql-4.1
      
      
      e4e67d58
    • unknown's avatar
      Merge mysql.com:/usr_rh9/home/elkin.rh9/MySQL/BARE/4.1 · ce6a2d32
      unknown authored
      into  mysql.com:/usr_rh9/home/elkin.rh9/MySQL/FIXES/4.1-bug19136_unass_user_var
      
      
      sql/item_func.cc:
        Auto merged
      ce6a2d32
    • unknown's avatar
      Fixed bug #14927. · 375749b8
      unknown authored
      A query with a group by and having clauses could return a wrong
      result set if the having condition contained a constant conjunct 
      evaluated to FALSE.
      It happened because the pushdown condition for table with
      grouping columns lost its constant conjuncts.
      Pushdown conditions are always built by the function make_cond_for_table
      that ignores constant conjuncts. This is apparently not correct when
      constant false conjuncts are present.
      
      
      
      mysql-test/r/having.result:
        Added a test case for bug #14927.
      mysql-test/t/having.test:
        Added a test case for bug #14927.
      sql/sql_lex.cc:
        Fixed bug #14927.
        Initialized fields for having conditions in  st_select_lex::init_query().
      sql/sql_lex.h:
        Fixed bug #14927.
        Added a field to restore having condititions for execution in SP and PS.
      sql/sql_prepare.cc:
        Fixed bug #14927.
        Added code to restore havinf conditions for execution in SP and PS.
      sql/sql_select.cc:
        Fixed bug #14927.
        Performed evaluation of constant expressions in having clauses.
        If the having condition contains a constant conjunct that is always false
        an empty result set is returned after the optimization phase.
        In this case the corresponding EXPLAIN command now returns 
        "Impossible HAVING" in the last column.
      375749b8
  6. 06 May, 2006 7 commits
  7. 05 May, 2006 4 commits
    • unknown's avatar
      Bug#19136: Crashing log-bin and uninitialized user variables in a derived table · 4ab4631b
      unknown authored
      The reason of the bug is in that `get_var_with_binlog' performs missed
      assingment of
      the variables as side-effect. Doing that it eventually calls
      `free_underlaid_joins' to pass as an argument `thd->lex->select_lex' of the lex
      which belongs to the user query, not 
      to one which is emulated i.e SET @var1:=NULL.
      
      
      `get_var_with_binlog' is refined to supply a temporary lex to sql_set_variables's stack.
      
      
      mysql-test/r/rpl_user_variables.result:
        results changed
      mysql-test/t/rpl_user_variables.test:
        a problematic query to be binlogged is added
      sql/item_func.cc:
        BUG#19136: Crashing log-bin and uninitialized user variables
        
        The reason of the bug is in that how `get_var_with_binlog' performs missed
        assingment of the variables: `free_underlaid_joins' gets as an argument `thd->lex->select_lex'
        which belongs to the user query, not to one which is emulated i.e SET @var1:=NULL.
        
        `get_var_with_binlog' is refined to supply a temporary lex to sql_set_variables's stack.
      4ab4631b
    • unknown's avatar
      Merge mysql.com:/home/tomash/src/mysql_ab/mysql-4.1 · 8515e8f0
      unknown authored
      into  mysql.com:/home/tomash/src/mysql_ab/mysql-4.1-bug16372
      
      
      8515e8f0
    • unknown's avatar
      Merge mysql.com:/home/tomash/src/mysql_ab/mysql-4.1 · c29fc77c
      unknown authored
      into  mysql.com:/home/tomash/src/mysql_ab/mysql-4.1-bug16372
      
      
      c29fc77c
    • unknown's avatar
      Merge mysql.com:/home/tomash/src/mysql_ab/mysql-4.1 · 5f7fec79
      unknown authored
      into  mysql.com:/home/tomash/src/mysql_ab/mysql-4.1-bug16501
      
      
      5f7fec79
  8. 04 May, 2006 16 commits
    • unknown's avatar
      Merge paul@bk-internal.mysql.com:/home/bk/mysql-4.1 · e38edaef
      unknown authored
      into  polar.kitebird.com:/src/extern/MySQL/bk/mysql-4.1
      
      
      e38edaef
    • unknown's avatar
      .del-changelog-4.1.xml~8aa496ebed09d868: · ac5eb33a
      unknown authored
        Delete: Docs/changelog-4.1.xml
      
      
      BitKeeper/deleted/.del-changelog-4.1.xml~8aa496ebed09d868:
        Delete: Docs/changelog-4.1.xml
      ac5eb33a
    • unknown's avatar
      Merge polar.kitebird.com:/src/extern/MySQL/bk/mysql-4.0 · d2ae2263
      unknown authored
      into  polar.kitebird.com:/src/extern/MySQL/bk/mysql-4.1
      
      
      d2ae2263
    • unknown's avatar
      .del-changelog-4.0.xml~8f56ee8a913e848b: · b8984be3
      unknown authored
        Delete: Docs/changelog-4.0.xml
      
      
      BitKeeper/deleted/.del-changelog-4.0.xml~8f56ee8a913e848b:
        Delete: Docs/changelog-4.0.xml
      b8984be3
    • unknown's avatar
      Merge jamppa@bk-internal.mysql.com:/home/bk/mysql-4.1 · d1bd5eeb
      unknown authored
      into  ua141d10.elisa.omakaista.fi:/home/my/bk/mysql-4.1
      
      
      d1bd5eeb
    • unknown's avatar
      Fixed Bug#11324: · 02dcc76e
      unknown authored
      TIME_FORMAT using "%l:%i" returns 36:00 with 24:00:00 in TIME column
      
      
      mysql-test/r/date_formats.result:
        Added test case for Bug#11324,
        "TIME_FORMAT using "%l:%i" returns 36:00 with 24:00:00 in TIME column"
      mysql-test/t/date_formats.test:
        Added test case for Bug#11324,
        "TIME_FORMAT using "%l:%i" returns 36:00 with 24:00:00 in TIME column"
      02dcc76e
    • unknown's avatar
      Fix for Bug#11326. · bcb61e68
      unknown authored
      
      mysql-test/r/date_formats.result:
        Added test cases for Bug#11326
      mysql-test/t/date_formats.test:
        Added test cases for Bug#11326
      bcb61e68
    • unknown's avatar
      Merge jamppa@bk-internal.mysql.com:/home/bk/mysql-4.1 · 31ecb598
      unknown authored
      into  a193-229-222-105.elisa-laajakaista.fi:/home/my/bk/mysql-4.1
      
      
      31ecb598
    • unknown's avatar
      Merge mysql.com:/home/tomash/src/mysql_ab/mysql-4.1 · 0aa51931
      unknown authored
      into  mysql.com:/home/tomash/src/mysql_ab/mysql-4.1-bug16372
      
      
      0aa51931
    • unknown's avatar
      Merge mysql.com:/home/tomash/src/mysql_ab/mysql-4.1 · 144d2ec9
      unknown authored
      into  mysql.com:/home/tomash/src/mysql_ab/mysql-4.1-bug16501
      
      
      144d2ec9
    • unknown's avatar
      Merge mysql.com:/home/tomash/src/mysql_ab/mysql-4.1 · 4624d395
      unknown authored
      into  mysql.com:/home/tomash/src/mysql_ab/mysql-4.1-bug16372
      
      
      4624d395
    • 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 mysql.com:/home/tomash/src/mysql_ab/mysql-4.1 · a5a4f767
      unknown authored
      into  mysql.com:/home/tomash/src/mysql_ab/mysql-4.1-bug16501
      
      
      a5a4f767
    • 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
      test result fixed · 812a82ed
      unknown authored
      
      mysql-test/r/mysqltest.result:
        result fixed
      812a82ed
    • 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
  9. 03 May, 2006 5 commits