1. 11 Jul, 2007 4 commits
  2. 10 Jul, 2007 3 commits
  3. 09 Jul, 2007 1 commit
  4. 08 Jul, 2007 3 commits
  5. 07 Jul, 2007 8 commits
  6. 06 Jul, 2007 7 commits
  7. 05 Jul, 2007 6 commits
    • gshchepa/uchum@gleb.loc's avatar
      Merge gshchepa@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 0b00ebbb
      gshchepa/uchum@gleb.loc authored
      into  gleb.loc:/home/uchum/work/bk/5.0-opt
      0b00ebbb
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #29442. · c33f4d3d
      gshchepa/uchum@gleb.loc authored
      The SELECT INTO OUTFILE FIELDS ENCLOSED BY digit or minus sign,
      followed by the same LOAD DATA INFILE statement, used wrond encoding
      of non-string fields contained the enclosed character in their text
      representation.
      
      Example:
        SELECT 15, 9 INTO OUTFILE 'text' FIELDS ENCLOSED BY '5';
      
      Old encoded result in the text file:
        5155 595
               ^ was decoded as the 1st enclosing character of the 2nd field;
              ^ was skipped as garbage;
        ^    ^ was decoded as a pair of englosing characters of the 1st field;
            ^   was decoded as traling space of the first field;
          ^^ was decoded as a doubled enclosed character.
      
      New encoded result in the text file:
        51\55 595
        ^   ^ pair of enclosing characters of the 1st field;
          ^^ escaped enclosed character.
      c33f4d3d
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #29166: · 1532452a
      gkodinov/kgeorge@magare.gmz authored
      AsText() needs to know the maximum number of
      characters a IEEE double precision value can
      occupy to make sure there's enough buffer space.
      The number was too small to hold all possible
      values and this caused buffer overruns.
      Fixed by correcting the calculation of the 
      maximum digits in a string representation of an
      IEEE double precision value as printed by 
      String::qs_append(double).
      1532452a
    • svoj@june.mysql.com's avatar
      Merge mysql.com:/home/svoj/devel/mysql/BUG27564/mysql-4.1-engines · 9b5dace0
      svoj@june.mysql.com authored
      into  mysql.com:/home/svoj/devel/mysql/BUG27564/mysql-5.0-engines
      9b5dace0
    • svoj@mysql.com/june.mysql.com's avatar
      BUG#27564 - Valgrind: UDF does not cleanup correctly · c2120c40
      svoj@mysql.com/june.mysql.com authored
      Dropping an user defined function may cause server crash in
      case this function is still in use by another thread.
      
      The problem was that our hash implementation didn't update
      hash link list properly when hash_update() was called.
      c2120c40
    • igor@olga.mysql.com's avatar
      Fixed bug #29392. · 4c02004d
      igor@olga.mysql.com authored
      This bug may manifest itself for select queries over a multi-table view
      that includes an ORDER BY clause in its definition. If the select list of 
      the query contains references to the same view column with different
      aliases the names of the columns in the result output will be nevertheless
      the same, coinciding with one of the alias.
      
      The bug happened because the method Item_ref::get_tmp_table_item that
      was inherited by the class Item_direct_view_ref ignored the fact that
      the name of the view column reference must be inherited by the fields
      of the temporary table that was created in order to get the result rows
      sorted.
      4c02004d
  8. 04 Jul, 2007 2 commits
  9. 03 Jul, 2007 6 commits
    • gshchepa/uchum@gleb.loc's avatar
      loaddata.result, loaddata.test: · 79622efe
      gshchepa/uchum@gleb.loc authored
        Updated test case for bug #29294.
      79622efe
    • gshchepa/uchum@gleb.loc's avatar
      Merge gleb.loc:/home/uchum/work/bk/4.1-opt · 42699946
      gshchepa/uchum@gleb.loc authored
      into  gleb.loc:/home/uchum/work/bk/5.0-opt
      42699946
    • gshchepa/uchum@gleb.loc's avatar
      Merge gshchepa@bk-internal.mysql.com:/home/bk/mysql-4.1-opt · 0e8292c9
      gshchepa/uchum@gleb.loc authored
      into  gleb.loc:/home/uchum/work/bk/4.1-opt
      0e8292c9
    • gshchepa/uchum@gleb.loc's avatar
      loaddata.result, loaddata.test: · 1f85dac2
      gshchepa/uchum@gleb.loc authored
        Test case update for bug #29294.
      1f85dac2
    • gshchepa/uchum@gleb.loc's avatar
      sql_class.cc: · 5f592984
      gshchepa/uchum@gleb.loc authored
        Windows compilation error fix.
      5f592984
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #29294. · dbe4fb94
      gshchepa/uchum@gleb.loc authored
      The `SELECT 'r' INTO OUTFILE ... FIELDS ENCLOSED BY 'r' ' statement
      encoded the 'r' string to a 4 byte string of value x'725c7272'
      (sequence of 4 characters: r\rr).
      The LOAD DATA statement decoded this string to a 1 byte string of
      value x'0d' (ASCII Carriage Return character) instead of the original
      'r' character.
      The same error also happened with the FIELDS ENCLOSED BY clause
      followed by special characters: 'n', 't', 'r', 'b', '0', 'Z' and 'N'.
      
      NOTE 1: This is a result of the undocumented feature: the LOAD DATA INFILE
      recognises 2-byte input sequences like \n, \t, \r and \Z in addition
      to documented 2-byte sequences: \0 and \N. This feature should be
      documented (here backspace character is a default ESCAPED BY character,
      in the real-life example it may be any ESCAPED BY character).
      
      NOTE 2, changed behaviour:
      Now the `SELECT INTO OUTFILE' statement with the `FIELDS ENCLOSED BY'
      clause followed by one of: 'n', 't', 'r', 'b', '0', 'Z' or 'N' characters
      encodes this special character itself by doubling it ('r' --> 'rr'),
      not by prepending it with an escape character.
      dbe4fb94