1. 14 Jun, 2006 10 commits
  2. 13 Jun, 2006 4 commits
    • evgen@moonbone.local's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-4.1-opt · 111dc927
      evgen@moonbone.local authored
      into moonbone.local:/home/evgen/bk-trees/mysql-4.1-opt
      111dc927
    • gkodinov@mysql.com's avatar
      Bug #20195: INSERT DELAYED with auto_increment is assigned wrong values · 8d94b8ca
      gkodinov@mysql.com authored
      The INSERT DELAYED should not maintain its own private auto-increment
      counter, because this is assuming that other threads cannot insert
      into the table while the INSERT DELAYED thread is inserting, which is
      a wrong assumption.
      
      So the start of processing of a batch of INSERT rows in the 
      INSERT DELAYED thread must be treated as a start of a new statement
      and cached next_insert_id must be cleared.
      8d94b8ca
    • evgen@moonbone.local's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-4.1-opt · d4942a26
      evgen@moonbone.local authored
      into moonbone.local:/work/16377-bug-4.1-opt-mysql
      d4942a26
    • evgen@moonbone.local's avatar
      Fixed bug#16377: result of DATE/TIME functions were compared as strings which · 67de8c46
      evgen@moonbone.local authored
      can lead to a wrong result.
      
      All date/time functions has the STRING result type thus their results are
      compared as strings. The string date representation allows a user to skip 
      some of leading zeros. This can lead to wrong comparison result if a date/time 
      function result is compared to such a string constant.
      
      The idea behind this bug fix is to compare results of date/time functions
      and data/time constants as ints, because that date/time representation is 
      more exact. To achieve this the agg_cmp_type() is changed to take in the
      account that a date/time field or an date/time item should be compared 
      as ints.
      
      This bug fix is partially back ported from 5.0.
      
      The agg_cmp_type() function now accepts THD as one of parameters. 
      In addition, it now checks if a date/time field/function is present in the
      list. If so, it tries to coerce all constants to INT to make date/time
      comparison return correct result. The field for the constant coercion is
      taken from the Item_field or constructed from the Item_func. In latter case
      the constructed field will be freed after conversion of all constant items.
      Otherwise the result is same as before - aggregated with help of the
      item_cmp_type() function.
      
      From the Item_func_between::fix_length_and_dec() function removed the part
      which was converting date/time constants to int if possible. Now this is 
      done by the agg_cmp_type() function.
      
      The new function result_as_longlong() is added to the Item class. 
      It indicates that the item is a date/time item and result of it can be
      compared as int. Such items are date/time fields/functions.
      
      Correct val_int() methods are implemented for classes Item_date_typecast, 
      Item_func_makedate, Item_time_typecast, Item_datetime_typecast. All these
      classes are derived from Item_str_func and Item_str_func::val_int() converts
      its string value to int without regard to the date/time type of these items.
      
      Arg_comparator::set_compare_func() and Arg_comparator::set_cmp_func()
      functions are changed to substitute result type of an item with the INT_RESULT
      if the item is a date/time item and another item is a constant. This is done
      to get a correct result of comparisons like date_time_function() = string_constant.
      67de8c46
  3. 12 Jun, 2006 2 commits
  4. 11 Jun, 2006 1 commit
  5. 08 Jun, 2006 2 commits
    • gkodinov@mysql.com's avatar
      Merge mysql.com:/home/kgeorge/mysql/5.0/teamclean · c9bb9413
      gkodinov@mysql.com authored
      into  mysql.com:/home/kgeorge/mysql/5.0/B15355
      c9bb9413
    • gkodinov@mysql.com's avatar
      Bug #15355: Common natural join column not resolved in prepared statement nested · 395affb8
      gkodinov@mysql.com authored
        query
      Problem:
      There was a wrong context assigned to the columns that were added in insert_fields()
      when expanding a '*'. When this is done in a prepared statement it causes 
      fix_fields() to fail to find the table that these columns reference.
      Actually the right context is set in setup_natural_join_row_types() called at the 
      end of setup_tables(). However when executed in a context of a prepared statement
      setup_tables() resets the context, but setup_natural_join_row_types() was not
      setting it to the correct value assuming it has already done so.
      
      Solution:
      The top-most, left-most NATURAL/USING join must be set as a 
      first_name_resolution_table in context even when operating on prepared statements.
      395affb8
  6. 06 Jun, 2006 1 commit
    • evgen@moonbone.local's avatar
      Fixed bug#15962: CONCAT() in UNION may lead to a data trucation. · d027dd7c
      evgen@moonbone.local authored
      To calculate its max_length the CONCAT() function is simply sums max_lengths
      of its arguments but when the collation of an argument differs from the 
      collation of the CONCAT() max_length will be wrong. This may lead to a data
      truncation when a tmp table is used, in UNIONS for example.
      
      The Item_func_concat::fix_length_and_dec() function now recalculates the 
      max_length of an argument when the mbmaxlen of the argument differs from the
      mbmaxlen of the CONCAT().
      d027dd7c
  7. 03 Jun, 2006 2 commits
  8. 02 Jun, 2006 6 commits
  9. 30 May, 2006 3 commits
  10. 29 May, 2006 9 commits