1. 29 Feb, 2008 1 commit
  2. 28 Feb, 2008 1 commit
    • gshchepa/uchum@host.loc's avatar
      Fixed bug #34620: item_row.cc:50: Item_row::illegal_method_call(const char*): · c5110674
      gshchepa/uchum@host.loc authored
                        Assertion `0' failed
      
      If ROW item is a part of an expression that also has
      aggregate function calls (COUNT/SUM/AVG...), a
      "splitting" with an Item::split_sum_func2 function
      is applied to that ROW item.
      Current implementation of Item::split_sum_func2
      replaces this Item_row with a newly created
      Item_aggregate_ref reference to it.
      Then the row cache tries to work with the
      Item_aggregate_ref object as with the Item_row object:
      row cache calls row-emulation methods such as cols and
      element_index. Item_aggregate_ref (like it's parent
      Item_ref) inherits dummy implementations of those
      methods from the hierarchy root Item, and call to
      them leads to failed assertions and wrong data
      output.
      
      Row-emulation virtual functions (cols, element_index, addr,
      check_cols, null_inside and bring_value) of Item_ref have
      been overloaded to forward calls to an underlying item
      reference.
      
      c5110674
  3. 27 Feb, 2008 1 commit
  4. 25 Feb, 2008 1 commit
    • kaa@kaamos.(none)'s avatar
      Fix for bug #33834: FRAC_SECOND: Applicability not clear in · 5a4e12cb
      kaa@kaamos.(none) authored
                          documentation
      
      While the manual mentions FRAC_SECOND only for the TIMESTAMPADD()
      function, it was also possible to use FRAC_SECOND with DATE_ADD(),
      DATE_SUB() and +/- INTERVAL.
      
      Fixed the parser to match the manual, i.e. using FRAC_SECOND for 
      anything other than TIMESTAMPADD()/TIMESTAMPDIFF() now produces a 
      syntax error.
      
      Additionally, the patch allows MICROSECOND to be used in TIMESTAMPADD/
      TIMESTAMPDIFF and marks FRAC_SECOND as deprecated.
      5a4e12cb
  5. 14 Feb, 2008 1 commit
  6. 13 Feb, 2008 3 commits
  7. 12 Feb, 2008 3 commits
  8. 11 Feb, 2008 1 commit
  9. 10 Feb, 2008 4 commits
  10. 08 Feb, 2008 3 commits
  11. 07 Feb, 2008 7 commits
  12. 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
  13. 05 Feb, 2008 1 commit
  14. 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
  15. 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
  16. 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
  17. 20 Jan, 2008 1 commit
  18. 18 Jan, 2008 2 commits
  19. 17 Jan, 2008 1 commit
  20. 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
  21. 12 Jan, 2008 1 commit
  22. 11 Jan, 2008 2 commits