1. 25 May, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #28522: · 2ee30b0b
      gshchepa/uchum@gleb.loc authored
      sometimes `mysqldump --hex-blob' overruned output buffer by '\0' byte.
      
      The dump_table() function has been fixed to reserve 1 byte more for the
      last '\0' byte of dumped string.
      2ee30b0b
  2. 23 May, 2007 2 commits
    • evgen@moonbone.local's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 55906317
      evgen@moonbone.local authored
      into  moonbone.local:/mnt/gentoo64/work/27563-bug-5.0-opt-mysql
      55906317
    • evgen@moonbone.local's avatar
      Bug#27563: Stored functions and triggers wasn't throwing an error when killed. · d1d58b5f
      evgen@moonbone.local authored
      If a stored function or a trigger was killed it had aborted but no error
      was thrown. This allows the caller statement to continue without a notice.
      This may lead to a wrong data being inserted/updated to/deleted as in such
      cases the correct result of a stored function isn't guaranteed. In the case
      of triggers it allows the caller statement to ignore kill signal and to
      waste time because of re-evaluation of triggers that always will fail
      because thd->killed flag is still on.
      
      Now the Item_func_sp::execute() and the sp_head::execute_trigger() functions
      check whether a function or a trigger were killed during execution and
      throws an appropriate error if so.
      Now the fill_record() function stops filling record if an error was reported
      through thd->net.report_error.
      d1d58b5f
  3. 22 May, 2007 4 commits
  4. 21 May, 2007 11 commits
  5. 20 May, 2007 1 commit
  6. 18 May, 2007 7 commits
  7. 17 May, 2007 4 commits
    • igor@olga.mysql.com's avatar
      Merge olga.mysql.com:/home/igor/mysql-5.0-opt · 2189c571
      igor@olga.mysql.com authored
      into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug28337
      2189c571
    • evgen@moonbone.local's avatar
      Bug#28261: Wrong DATETIME comparison result when the GET_USER_VAR function · 0e3c4f67
      evgen@moonbone.local authored
      is involved.
      
      The Arg_comparator::compare_datetime() comparator caches its arguments if
      they are constants i.e. const_item() returns true. The
      Item_func_get_user_var::const_item() returns true or false based on
      the current query_id and the query_id where the variable was created.
      Thus even if a query can change its value its const_item() still will return
      true. All this leads to a wrong comparison result when an object of the
      Item_func_get_user_var class is involved.
      
      Now the Arg_comparator::can_compare_as_dates() and the
      get_datetime_value() functions never cache result of the GET_USER_VAR()
      function (the Item_func_get_user_var class).
      0e3c4f67
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug#22855: · a9b348c7
      gkodinov/kgeorge@macbook.gmz authored
      Conversion errors when constructing the condition for an
      IN predicates were treated as if the affected column contains
      NULL. If such a IN predicate is inside NOT we get wrong 
      results.
      Corrected the handling of conversion errors in an IN predicate 
      that is resolved by unique_subquery (through 
      subselect_uniquesubquery_engine).
      a9b348c7
    • igor@olga.mysql.com's avatar
      Fixed bug #28337: wrong results for grouping queries with correlated · 8c34ae26
      igor@olga.mysql.com authored
      subqueries in WHERE conditions.
      This bug was introduced by the patch for bug 27321.
      8c34ae26
  8. 16 May, 2007 10 commits