1. 19 Mar, 2008 1 commit
  2. 22 Feb, 2008 1 commit
    • kaa@kaamos.(none)'s avatar
      Fix for bug #33049: Assert while running test-as3ap test(mysql-bench · 0a29b8b0
      kaa@kaamos.(none) authored
                          suite)
      
      Under some circumstances a combination of aggregate functions and
      GROUP BY in a SELECT query over a VIEW could lead to incorrect
      calculation of the result type of the aggregate function. This in
      turn could result in incorrect results, or assertion failures on debug
      builds.
      
      Fixed by changing the logic in Item_sum_hybrid::fix_fields() so that
      the argument's item is dereferenced before calling its type() method.
      0a29b8b0
  3. 14 Feb, 2008 1 commit
  4. 13 Feb, 2008 3 commits
  5. 12 Feb, 2008 3 commits
  6. 11 Feb, 2008 1 commit
  7. 10 Feb, 2008 4 commits
  8. 08 Feb, 2008 3 commits
  9. 07 Feb, 2008 7 commits
  10. 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
  11. 05 Feb, 2008 1 commit
  12. 01 Feb, 2008 2 commits
    • kaa@mbp.local's avatar
      Merge mbp.local:/Users/kaa/src/opt/bug25162/my50-bug25162 · e80794b3
      kaa@mbp.local authored
      into  mbp.local:/Users/kaa/src/opt/mysql-5.0-opt
      e80794b3
    • kaa@mbp.local's avatar
      Fix for bug #25162: Backing up DB from 5.1 adds 'USING BTREE' to KEYs · 663453d5
      kaa@mbp.local authored
                          on table creates
      
      The problem was in incompatible syntax for key definition in CREATE
      TABLE.
      
      5.0 supports only the following syntax for key definition (see "CREATE
      TABLE syntax" in the manual):
      
      {INDEX|KEY} [index_name] [index_type] (index_col_name,...)
      
      While 5.1 parser supports the above syntax, the "preferred" syntax was
      changed to:
      
      {INDEX|KEY} [index_name] (index_col_name,...) [index_type]
      
      The above syntax is used in 5.1 for the SHOW CREATE TABLE output, which
      led to dumps generated by 5.1 being incompatible with 5.0.
      
      Fixed by changing the parser in 5.0 to support both 5.0 and 5.1 syntax
      for key definition.
      663453d5
  13. 31 Jan, 2008 1 commit
    • evgen@moonbone.local's avatar
      Bug#30787: Stored function ignores user defined alias. · f967e247
      evgen@moonbone.local authored
      Simple subselects are pulled into upper selects. This operation substitutes the
      pulled subselect for the first item from the select list of the subselect.
      If an alias is defined for a subselect it is inherited by the replacement item.
      As this is done after fix_fields phase this alias isn't showed if the
      replacement item is a stored function. This happens because the Item_func_sp::make_field
      function makes send field from its result_field and ignores the defined alias.
      
      Now when an alias is defined the Item_func_sp::make_field function sets it for
      the returned field.
      f967e247
  14. 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
  15. 20 Jan, 2008 1 commit
  16. 18 Jan, 2008 2 commits
  17. 17 Jan, 2008 1 commit
  18. 14 Jan, 2008 1 commit
    • mhansson/martin@linux-st28.site's avatar
      Bug#33143: Incorrect ORDER BY for ROUND()/TRUNCATE() result · effe27e3
      mhansson/martin@linux-st28.site authored
      The ROUND(X, D) function would change the Item::decimals field during
      execution to achieve the effect of a dynamic number of decimal digits.
      This caused a series of bugs:
      Bug #30617:Round() function not working under some circumstances in InnoDB
      Bug #33402:ROUND with decimal and non-constant cannot round to 0 decimal places
      Bug #30889:filesort and order by with float/numeric crashes server
      Fixed by never changing the number of shown digits for DECIMAL when
      used with a nonconstant number of decimal digits.
      effe27e3
  19. 12 Jan, 2008 1 commit
  20. 11 Jan, 2008 3 commits
  21. 10 Jan, 2008 1 commit