1. 04 May, 2007 6 commits
  2. 03 May, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#23656: Wrong conversion result of a DATETIME to integer using CAST function. · 7f9411c1
      evgen@moonbone.local authored
      The generic string to int conversion was used by the Item_func_signed and
      the Item_func_unsigned classes to convert DATE/DATETIME values to the
      SIGNED/UNSIGNED type. But this conversion produces wrong results for such
      values.
      
      Now if the item which result has to be converted can return its result as
      longlong then the item->val_int() method is used to allow the item to carry
      out the conversion itself and return the correct result.
      This condition is checked in the Item_func_signed::val_int() and the
      Item_func_unsigned::val_int() functions.
      7f9411c1
  3. 02 May, 2007 1 commit
  4. 30 Apr, 2007 3 commits
  5. 29 Apr, 2007 13 commits
  6. 28 Apr, 2007 3 commits
    • gshchepa/uchum@gshchepa.loc's avatar
      Fixed bug #13191. · 3adcb94e
      gshchepa/uchum@gshchepa.loc authored
      INSERT...ON DUPLICATE KEY UPDATE may cause error 1032: 
      "Can't find record in ..." if we are inserting into
      InnoDB table unique index of partial key with
      underlying UTF-8 string field.
      
      This error occurs because INSERT...ON DUPLICATE uses a wrong
      procedure to copy string fields of multi-byte character sets
      for index search.
      3adcb94e
    • gshchepa/uchum@gshchepa.loc's avatar
      Merge gshchepa.loc:/home/uchum/work/bk-trees/mysql-4.1-opt · d85c76f6
      gshchepa/uchum@gshchepa.loc authored
      into  gshchepa.loc:/home/uchum/work/bk-trees/mysql-5.0-opt
      d85c76f6
    • gshchepa/uchum@gshchepa.loc's avatar
      Fixed bug #20710. · 3322b3c0
      gshchepa/uchum@gshchepa.loc authored
      This bug occurs when error message length exceeds allowed limit: my_error()
      function outputs "%s" sequences instead of long string arguments.
      
      Formats like %-.64s are very common in errmsg.txt files, however my_error()
      function simply ignores precision of those formats.
      3322b3c0
  7. 27 Apr, 2007 4 commits
  8. 26 Apr, 2007 9 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
    • svoj@mysql.com/april.(none)'s avatar
      Merge mysql.com:/home/svoj/devel/mysql/merge/mysql-4.1-engines · 29d2d5dc
      svoj@mysql.com/april.(none) authored
      into  mysql.com:/home/svoj/devel/mysql/merge/mysql-5.0-engines
      29d2d5dc
    • svoj@mysql.com/april.(none)'s avatar
      Merge svojtovich@bk-internal.mysql.com:/home/bk/mysql-5.0-build · ce55046f
      svoj@mysql.com/april.(none) authored
      into  mysql.com:/home/svoj/devel/mysql/merge/mysql-5.0-engines
      ce55046f
    • svoj@mysql.com/april.(none)'s avatar
      Merge svojtovich@bk-internal.mysql.com:/home/bk/mysql-4.1-build · f6989772
      svoj@mysql.com/april.(none) authored
      into  mysql.com:/home/svoj/devel/mysql/merge/mysql-4.1-engines
      f6989772
    • joerg@trift-lap.fambruehe's avatar
      Merge trift-lap.fambruehe:/MySQL/M50/clone-5.0 · 03f4492b
      joerg@trift-lap.fambruehe authored
      into  trift-lap.fambruehe:/MySQL/M50/push-5.0
      03f4492b
    • joerg@trift-lap.fambruehe's avatar
      Merge trift-lap.fambruehe:/MySQL/M41/push-4.1 · 5af470ee
      joerg@trift-lap.fambruehe authored
      into  trift-lap.fambruehe:/MySQL/M50/push-5.0
      5af470ee
    • joerg@trift-lap.fambruehe's avatar
      Merge trift-lap.fambruehe:/MySQL/M41/mysql-4.1 · 69d39592
      joerg@trift-lap.fambruehe authored
      into  trift-lap.fambruehe:/MySQL/M41/push-4.1
      69d39592