1. 13 Feb, 2008 2 commits
  2. 12 Feb, 2008 5 commits
  3. 11 Feb, 2008 2 commits
  4. 10 Feb, 2008 9 commits
  5. 08 Feb, 2008 2 commits
  6. 07 Feb, 2008 7 commits
  7. 06 Feb, 2008 1 commit
    • gshchepa/uchum@host.loc's avatar
      Fixed bug#30059. · 8715855a
      gshchepa/uchum@host.loc authored
      Server handles truncation for assignment of too-long values
      into CHAR/VARCHAR/TEXT columns in a different ways when the
      truncated characters are spaces:
      1. CHAR(N) columns silently ignore end-space truncation;
      2. TEXT columns post a truncation warning/error in the
         non-strict/strict mode.
      3. VARCHAR columns always post a truncation note in
         any mode.
      
      Space truncation processing has been synchronised over
      CHAR/VARCHAR/TEXT columns: current behavior of VARCHAR
      columns has been propagated as standard.
      
      Binary-encoded string/BLOB columns are not affected.
      8715855a
  8. 05 Feb, 2008 1 commit
  9. 01 Feb, 2008 4 commits
  10. 31 Jan, 2008 3 commits
  11. 30 Jan, 2008 1 commit
  12. 27 Jan, 2008 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #33833. · 5e14047e
      igor@olga.mysql.com authored
      Two disjuncts containing equalities of the form key=const1 and key=const2 can
      be merged into one if const1 is equal to const2. To check it the common 
      collation of the constants were used rather than the collation of the field key.
      For example when the default collation of the constants was cases insensitive
      while the collation of the field was case sensitive, then two or-ed equality 
      predicates key='b' and key='B' incorrectly were merged into one f='b'. As a 
      result ref access was used instead of range access and wrong result sets were 
      returned in many cases. 
      Fixed the problem by comparing constant in the or-ed predicate with collation of
      the key field.
      5e14047e
  13. 25 Jan, 2008 1 commit
  14. 24 Jan, 2008 1 commit