1. 14 Jul, 2007 1 commit
  2. 09 Jul, 2007 1 commit
  3. 08 Jul, 2007 2 commits
  4. 07 Jul, 2007 1 commit
  5. 06 Jul, 2007 2 commits
  6. 05 Jul, 2007 2 commits
    • unknown's avatar
      Merge chilla.local:/home/mydev/mysql-4.1-ateam · 8b1b1151
      unknown authored
      into  chilla.local:/home/mydev/mysql-4.1-axmrg
      
      8b1b1151
    • unknown's avatar
      BUG#27564 - Valgrind: UDF does not cleanup correctly · 632ed804
      unknown 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.
      
      
      mysys/hash.c:
        The following requirement wasn't met by hash_update() function
        causing corruption of hash links list:
        
        After a record was unlinked from the old chain during update, it
        holds random position. By the chance this position is equal to
        position for the first element in the new chain. That means
        updated record is the only record in the new chain.
      632ed804
  7. 04 Jul, 2007 1 commit
  8. 03 Jul, 2007 4 commits
    • unknown's avatar
      Merge gshchepa@bk-internal.mysql.com:/home/bk/mysql-4.1-opt · 2cfb62a2
      unknown authored
      into  gleb.loc:/home/uchum/work/bk/4.1-opt
      
      2cfb62a2
    • unknown's avatar
      loaddata.result, loaddata.test: · c30e513b
      unknown authored
        Test case update for bug #29294.
      
      
      mysql-test/t/loaddata.test:
        Test case update for bug #29294.
      mysql-test/r/loaddata.result:
        Test case update for bug #29294.
      c30e513b
    • unknown's avatar
      sql_class.cc: · a4c295f3
      unknown authored
        Windows compilation error fix.
      
      
      sql/sql_class.cc:
        Windows compilation error fix.
      a4c295f3
    • unknown's avatar
      Fixed bug #29294. · 36bb14d6
      unknown 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.
      
      
      sql/sql_class.h:
        Fixed bug #29294.
        The ESCAPE_CHARS macro constant is defined to enumerate
        symbolic names of espace-sequences like  '\n', '\t' etc.
        The select_export::is_ambiguous_field_sep field has been added
        to distinguish special values of the field_sep field from
        another values (see ESCAPE_CHARS).
      sql/sql_class.cc:
        Fixed bug #29294.
        The select_export::send_data method has been modified to
        encode special values of the field_sep field by
        doubling of those values instead of prepending them with a
        value of the escape_char field.
        Example: The SELECT 'r' INTO OUTFILE FIELDS ENCLOSED BY 'r'
        now produces the 'rr' output string instead of x'5c72'
        (i.e. instead of sequence of 2 bytes: \ and r).
      sql/sql_load.cc:
        Fixed bug #29294.
        Added commentary for the READ_INFO::unescape method.
      mysql-test/t/loaddata.test:
        Updated test case for bug #29294.
      mysql-test/r/loaddata.result:
        Updated test case for bug #29294.
      36bb14d6
  9. 26 Jun, 2007 2 commits
    • unknown's avatar
      Fixed bug #29251. · 5e0349cc
      unknown authored
      Sometimes special 0 ENUM values was ALTERed to normal
      empty string ENUM values.
      
      Special 0 ENUM value has the same string representation
      as normal ENUM value defined as '' (empty string).
      The do_field_string function was used to convert
      ENUM data at an ALTER TABLE request, but this
      function doesn't care about numerical "indices" of
      ENUM values, i.e. do_field_string doesn't distinguish
      a special 0 value from an empty string value.
      
      A new copy function called do_field_enum has been added to
      copy special 0 ENUM values without conversion to an empty
      string.
      
      
      sql/field_conv.cc:
        Fixed bug #29251.
        The Copy_field::get_copy_func method has been modified to
        return a pointer to the do_field_enum function if a conversion
        between two columns of incompatible enum types is required.
        The do_field_enum function has been added for the correct
        conversion of special 0 enum values.
      mysql-test/t/type_enum.test:
        Updated test case for bug #29251.
      mysql-test/r/type_enum.result:
        Updated test case for bug #29251.
      5e0349cc
    • unknown's avatar
      Merge maint1.mysql.com:/data/localhome/tsmith/bk/41 · 9e451f51
      unknown authored
      into  maint1.mysql.com:/data/localhome/tsmith/bk/maint/41
      
      9e451f51
  10. 25 Jun, 2007 1 commit
  11. 23 Jun, 2007 1 commit
  12. 22 Jun, 2007 1 commit
    • unknown's avatar
      Fix for bug #29079: Semantics of "bigint" depend on platform specifics (size, signedness of char ?) · 2960b680
      unknown authored
      Problem: long and long long types mess in a comparison may lead to wrong results on some platforms.
      Fix: prefer [unsigned] long long as [u]longlong as it's used unconditionally in many places.
      
      
      include/my_global.h:
        Fix for bug #29079: Semantics of "bigint" depend on platform specifics (size, signedness of char ?)
          - use [unsigned] long long as [u]longlong if sizeof(long long) == 8, to avoid type mess,
            as we use [unsigned] long long unconditionally in many places, for example in constants 
            with [U]LL suffix.
      2960b680
  13. 20 Jun, 2007 1 commit
  14. 19 Jun, 2007 4 commits
  15. 18 Jun, 2007 6 commits
  16. 15 Jun, 2007 1 commit
  17. 14 Jun, 2007 2 commits
  18. 13 Jun, 2007 7 commits