1. 03 Mar, 2008 1 commit
    • kaa@kaamos.(none)'s avatar
      Fix for bug #31781: multi-table UPDATE with temp-pool enabled fails · bd53f960
      kaa@kaamos.(none) authored
                          with errno 17
      
      my_create() did not perform any checks for the case when a file is
      successfully created by a call to open(), but the call to
      my_register_filename() later fails because the number of open files
      has exceeded the my_open_files limit. This can happen on platforms 
      which do not have getrlimit(), and hence we do not know the real limit
      for open files. In such a case an error was returned to a caller
      although the file has actually been created. Since callers assume
      my_create() to return an error only when it failed to create a file,
      they did not perform any cleanups, leaving an 'orphaned' file on the
      file system.
      
      Fixed by adding a check for the above case to my_create() and ensuring
      the newly created file is deleted before returning an error.
      
      Creating a deterministic test case in the test suite is impossible,
      because the exact steps required to reproduce the above situation
      depend on the platform and/or environment (OS per-user limits, queries
      executed by previous tests, startup parameters). The patch was
      manually tested on Windows using examples posted in the bug report.
      bd53f960
  2. 27 Feb, 2008 1 commit
  3. 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
  4. 14 Feb, 2008 1 commit
  5. 13 Feb, 2008 3 commits
  6. 12 Feb, 2008 3 commits
  7. 11 Feb, 2008 1 commit
  8. 10 Feb, 2008 4 commits
  9. 08 Feb, 2008 3 commits
  10. 07 Feb, 2008 7 commits
  11. 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
  12. 05 Feb, 2008 1 commit
  13. 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
  14. 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
  15. 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
  16. 20 Jan, 2008 1 commit
  17. 18 Jan, 2008 2 commits
  18. 17 Jan, 2008 1 commit
  19. 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
  20. 12 Jan, 2008 1 commit
  21. 11 Jan, 2008 3 commits