1. 07 May, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#28133: Wrong DATE/DATETIME comparison in IN() function. · 7d473a1a
      evgen@moonbone.local authored
      The IN function was comparing DATE/DATETIME values either as ints or as
      strings. Both methods have their disadvantages and may lead to a wrong
      result.
      
      Now IN function checks whether all of its arguments has the STRING result
      types and at least one of them is a DATE/DATETIME item. If so it uses either
      an object of the in_datetime class or an object of the cmp_item_datetime
      class to perform its work. If the IN() function arguments are rows then
      row columns are checked whether the DATE/DATETIME comparator should be used
      to compare them.
      The in_datetime class is used to find occurence of the item to be checked
      in the vector of the constant DATE/DATETIME values. The cmp_item_datetime
      class is used to compare items one by one in the DATE/DATETIME context.
      Both classes obtain values from items with help of the get_datetime_value()
      function and cache the left item if it is a constant one.
      7d473a1a
  2. 27 Apr, 2007 3 commits
  3. 26 Apr, 2007 5 commits
    • evgen@moonbone.local's avatar
      Bug#16377: Wrong DATE/DATETIME comparison in BETWEEN function. · 7a1c61ef
      evgen@moonbone.local authored
      The BETWEEN function was comparing DATE/DATETIME values either as ints or as
      strings. Both methods have their disadvantages and may lead to a wrong
      result.
      
      Now BETWEEN function checks whether all of its arguments has the STRING result
      types and at least one of them is a DATE/DATETIME item. If so it sets up
      two Arg_comparator obects to compare with the compare_datetime() comparator
      and uses them to compare such items.
      
      Added two Arg_comparator object members and one flag to the
      Item_func_between class for the correct DATE/DATETIME comparison.
      The Item_func_between::fix_length_and_dec() function now detects whether
      it's used for DATE/DATETIME comparison and sets up newly added Arg_comparator
      objects to do this.
      The Item_func_between::val_int() now uses Arg_comparator objects to perform
      correct DATE/DATETIME comparison.
      The owner variable of the Arg_comparator class now can be set to NULL if the
      caller wants to handle NULL values by itself.
      Now the Item_date_add_interval::get_date() function ajusts cached_field type according to the detected type.
      7a1c61ef
    • evgen@moonbone.local's avatar
      Merge moonbone.local:/mnt/gentoo64/work/27590-bug-5.0-opt-mysql · 84c47ae0
      evgen@moonbone.local authored
      into  moonbone.local:/mnt/gentoo64/work/16377-bug-5.0-opt-mysql
      84c47ae0
    • evgen@moonbone.local's avatar
      Bug#27590: Wrong DATE/DATETIME comparison. · 4747fa0c
      evgen@moonbone.local authored
      DATE and DATETIME can be compared either as strings or as int. Both
      methods have their disadvantages. Strings can contain valid DATETIME value
      but have insignificant zeros omitted thus became non-comparable with
      other DATETIME strings. The comparison as int usually will require conversion
      from the string representation and the automatic conversion in most cases is
      carried out in a wrong way thus producing wrong comparison result. Another
      problem occurs when one tries to compare DATE field with a DATETIME constant.
      The constant is converted to DATE losing its precision i.e. losing time part.
      
      This fix addresses the problems described above by adding a special
      DATE/DATETIME comparator. The comparator correctly converts DATE/DATETIME
      string values to int when it's necessary, adds zero time part (00:00:00)
      to DATE values to compare them correctly to DATETIME values. Due to correct
      conversion malformed DATETIME string values are correctly compared to other
      DATE/DATETIME values.
      
      As of this patch a DATE value equals to DATETIME value with zero time part.
      For example '2001-01-01' equals to '2001-01-01 00:00:00'.
      
      The compare_datetime() function is added to the Arg_comparator class.
      It implements the correct comparator for DATE/DATETIME values.
      Two supplementary functions called get_date_from_str() and get_datetime_value()
      are added. The first one extracts DATE/DATETIME value from a string and the
      second one retrieves the correct DATE/DATETIME value from an item.
      The new Arg_comparator::can_compare_as_dates() function is added and used
      to check whether two given items can be compared by the compare_datetime()
      comparator.
      Two caching variables were added to the Arg_comparator class to speedup the
      DATE/DATETIME comparison.
      One more store() method was added to the Item_cache_int class to cache int
      values.
      The new is_datetime() function was added to the Item class. It indicates
      whether the item returns a DATE/DATETIME value.
      4747fa0c
    • gkodinov/kgeorge@magare.gmz's avatar
      Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · f4ec0f1c
      gkodinov/kgeorge@magare.gmz authored
      into  magare.gmz:/home/kgeorge/mysql/autopush/B27363-5.0-opt
      f4ec0f1c
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #27363: · bfa29e17
      gkodinov/kgeorge@magare.gmz authored
      Validity checks for nested set functions
      were not taking into account that the enclosed
      set function may be on a nest level that is
      lower than the nest level of the enclosing set
      function.
      Fixed by :
       - propagating max_sum_func_level
      up the enclosing set functions chain.
       - updating the max_sum_func_level of the 
         enclosing set function when the enclosed set
         function is aggregated above or on the same
         nest level of as the level of the enclosing 
         set function.
       - updating the max_arg_level of the enclosing
         set function on a reference that refers to
         an item above or on the same nest level
         as the level of the enclosing set function.
       - Treating both Item_field and Item_ref as possibly
         referencing items from outer nest levels.
      bfa29e17
  4. 25 Apr, 2007 1 commit
    • gshchepa/uchum@gshchepa.loc's avatar
      Fixed bug #27650: · 5983038a
      gshchepa/uchum@gshchepa.loc authored
      INSERT into InnoDB table may cause "ERROR 1062 (23000): Duplicate entry..."
      errors or lost records after multi-row INSERT of the form:
      "INSERT INTO t (id...) VALUES (NULL...) ON DUPLICATE KEY UPDATE id=VALUES(id)",
      where "id" is an AUTO_INCREMENT column.
      
      It happens because InnoDB handler forgets to save next insert id after
      updating of auto_increment column with new values. As result of that
      last insert id stored inside InnoDB dictionary tables differs from it's
      cached thd->next_insert_id value.
      5983038a
  5. 24 Apr, 2007 2 commits
  6. 23 Apr, 2007 2 commits
  7. 21 Apr, 2007 1 commit
  8. 20 Apr, 2007 12 commits
  9. 19 Apr, 2007 2 commits
  10. 18 Apr, 2007 2 commits
    • sergefp@mysql.com's avatar
      BUG#27939: Early NULLs filtering doesn't work for eq_ref access · 83e6352c
      sergefp@mysql.com authored
       - Turn it on for JT_EQ_REF access method
      83e6352c
    • igor@olga.mysql.com's avatar
      Fixed bug #27870. The bug that causes crashes manifests itself at some · 6ad81b4e
      igor@olga.mysql.com authored
      conditions when executing an equijoin query with WHERE condition
      containing a subquery predicate of the form join_attr NOT IN (SELECT ...).
      
      To resolve a problem of the correct evaluation of the expression
        attr NOT IN (SELECT ...)
      an array of guards is created to make it possible to filter out some 
      predicates of the EXISTS subquery into which the original subquery 
      predicate is transformed, in the cases when a takes the NULL value. 
      If attr is defined as a field that cannot be NULL than such an array 
      is not needed and is not created. 
      However if the field a occurred also an an equijoin predicate t2.a=t1.b
      and table t1 is accessed before table t2 then it may happen that the 
      the EXISTS subquery is pushed down to the condition evaluated just after
      table t1 has been accessed. In this case any occurrence of t2.a is 
      substituted for t1.b. When t1.b takes the value of NULL an attempt is 
      made to turn on the corresponding guard. This action caused a crash as 
      no guard array had been created.
      
      Now the code of Item_in_subselect::set_cond_guard_var checks that the guard
      array has been created before setting a guard variable on. Otherwise the
      method does nothing. It cannot results in returning a row that could be
      rejected as the condition t2.a=t1.b will be checked later anyway.        
      6ad81b4e
  11. 17 Apr, 2007 2 commits
  12. 15 Apr, 2007 4 commits
    • evgen@moonbone.local's avatar
      item.cc: · 7d71d580
      evgen@moonbone.local authored
        Fix warning after fix for bug#27321.
      7d71d580
    • evgen@moonbone.local's avatar
      subselect.test, subselect.result: · 51badadd
      evgen@moonbone.local authored
        After merge fix.
      51badadd
    • evgen@moonbone.local's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 922a5a96
      evgen@moonbone.local authored
      into  moonbone.local:/mnt/gentoo64/work/27321-bug-5.0-opt-mysql
      922a5a96
    • evgen@moonbone.local's avatar
      Bug#27321: Wrong subquery result in a grouping select. · 3113ce63
      evgen@moonbone.local authored
      The Item_outer_ref class based on the Item_direct_ref class was always used
      to represent an outer field. But if the outer select is a grouping one and the 
      outer field isn't under an aggregate function which is aggregated in that
      outer select an Item_ref object should be used to represent such a field.
      If the outer select in which the outer field is resolved isn't grouping then
      the Item_field class should be used to represent such a field.
      This logic also should be used for an outer field resolved through its alias
      name.
      
      Now the Item_field::fix_outer_field() uses Item_outer_field objects to
      represent aliased and non-aliased outer fields for grouping outer selects
      only.
      Now the fix_inner_refs() function chooses which class to use to access outer
      field - the Item_ref or the Item_direct_ref. An object of the chosen class
      substitutes the original field in the Item_outer_ref object.
      The direct_ref and the found_in_select_list fields were added to the
      Item_outer_ref class.
      3113ce63
  13. 14 Apr, 2007 3 commits