1. 07 Jul, 2007 1 commit
  2. 06 Jul, 2007 1 commit
  3. 05 Jul, 2007 1 commit
  4. 03 Jul, 2007 4 commits
    • 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
  5. 26 Jun, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #29251. · f8bf427b
      gshchepa/uchum@gleb.loc 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.
      f8bf427b
  6. 25 Jun, 2007 1 commit
  7. 20 Jun, 2007 1 commit
  8. 19 Jun, 2007 2 commits
  9. 18 Jun, 2007 5 commits
  10. 15 Jun, 2007 1 commit
  11. 14 Jun, 2007 2 commits
  12. 13 Jun, 2007 7 commits
  13. 12 Jun, 2007 1 commit
  14. 11 Jun, 2007 2 commits
  15. 10 Jun, 2007 1 commit
  16. 08 Jun, 2007 3 commits
  17. 07 Jun, 2007 3 commits
  18. 06 Jun, 2007 3 commits