An error occurred fetching the project authors.
  1. 12 Oct, 2006 1 commit
  2. 11 Oct, 2006 1 commit
  3. 04 Oct, 2006 1 commit
    • kaa@polly.local's avatar
      Fixes a number of problems with time/datetime <-> string conversion functions: · 609a3cd2
      kaa@polly.local authored
      - bug #11655 "Wrong time is returning from nested selects - maximum time exists
      - input and output TIME values were not validated properly in several conversion functions
      - bug #20927 "sec_to_time treats big unsigned as signed"
      - integer overflows were not checked in several functions. As a result, input values like 2^32 or 3600*2^32 were treated as 0
      - BIGINT UNSIGNED values were treated as SIGNED in several functions
      - in cases where both input string truncation and out-of-range TIME value occur, only 'truncated incorrect time value' warning was produced
      609a3cd2
  4. 02 Oct, 2006 1 commit
    • Kristofer.Pettersson@naruto.'s avatar
      Bug#21811 Odd casting with date + INTERVAL arithmetic · 887f3b9d
      Kristofer.Pettersson@naruto. authored
      - Type casting was not consequent, thus when adding a DATE type with
        a WEEK interval the result type was DATETIME and not DATE as is the
        norm.
      - By changing the order of the date internal enumerations the deviant
        type casting is resolved (Item_date_add_interval::fix_length_and_dec()
        which determines result type for this operation assumes that addition
        of any interval with value <= INTERVAL_DAY to date value will result
        in date). There are two independant places to change:
        interval_names[] and interval_type.
      887f3b9d
  5. 22 Sep, 2006 1 commit
    • Kristofer.Pettersson@naruto.'s avatar
      Bug#21811 Odd casting with date + INTERVAL arithmetic · 2f33711f
      Kristofer.Pettersson@naruto. authored
      - The definition of the result type of a type_date function didn't
        include INTERVAL_WEEK
      - This patch adds an explicit test for INTERVAL_WEEK which results 
        in the result type for an item_date_add_intervall operation 
        being DATE rather than DATETIME when one parameter is
        INTERVAL_WEEK.
      2f33711f
  6. 17 Aug, 2006 1 commit
  7. 10 Aug, 2006 1 commit
    • tnurnberg@salvation.intern.azundris.com's avatar
      Bug#19844: time_format in Union truncates values · 17039285
      time_format() claimed %H and %k would return at most two digits
      (hours 0-23), but this coincided neither with actual behaviour
      nor with docs.  this is not visible in simple queries; forcing
      a temp-table is probably the easiest way to see this.  adjusted
      the return-length appropriately; the alternative would be to
      adjust the docs to say that behaviour for > 99 hours is undefined.
      ---
      Bug#19844: time_format in Union truncates values
      
      time_format() claimed %H and %k would return at most two digits
      (hours 0-23), but this coincided neither with actual behaviour
      nor with docs.  this is not visible in simple queries; forcing
      a temp-table is probably the easiest way to see this.  adjusted
      the return-length appropriately; the alternative would be to
      adjust the docs to say that behaviour for > 99 hours is undefined.
      17039285
  8. 07 Aug, 2006 1 commit
  9. 29 Jul, 2006 1 commit
  10. 18 Jul, 2006 1 commit
  11. 12 Jul, 2006 1 commit
  12. 04 Jul, 2006 1 commit
  13. 27 Jun, 2006 1 commit
  14. 16 Jun, 2006 1 commit
  15. 13 Jun, 2006 1 commit
    • 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
  16. 24 May, 2006 1 commit
    • monty@mysql.com's avatar
      Remove dflt_field from field structure as this was only needed when createing... · 97b941d9
      monty@mysql.com authored
      Remove dflt_field from field structure as this was only needed when createing temporary table and I found another soultion that doesn't increase the size of the field structure for all table instances. (Better fix for bug #19089)
      Fixed compiler warnings
      Fixed valgrind warning in Item_date_add_intervall::eq. (Recoding of bugfix #19490)
      97b941d9
  17. 16 May, 2006 1 commit
    • tnurnberg@mysql.com's avatar
      Bug#18997: DATE_ADD and DATE_SUB perform year2K autoconversion magic on 4-digit year value · d1311e1a
      tnurnberg@mysql.com authored
      if input year for date_add() / date_sub() with INTERVAL is low enough for
      calc_daynr() to possibly return incorrect results (calc_daynr() has no information
      on whether the year is low because it was a two-digit year ('77) or because it
      was a really low four-digit year (0077) and will indiscriminately try to turn the
      value into a four-digit year by adding 1900 or 2000 respectively), the functions
      will now throw NULL.
      d1311e1a
  18. 13 May, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      Fixed bug #19490. The bug that caused server crash manifested · 90f22704
      igor@rurik.mysql.com authored
      itself when executing queries referring to a view with GROUP BY
      an expression containing non-constant interval.
      It happened because Item_date_add_interval::eq neglected the
      fact that the method can be applied to an expression of the form
          date(col) + interval time_to_sec(col) second
      at the time when col could not be evaluated yet.
      An attempt to evaluate time_to_sec(col) in this method resulted
      in a crash.
      90f22704
  19. 04 May, 2006 2 commits
  20. 02 May, 2006 1 commit
  21. 25 Apr, 2006 1 commit
  22. 17 Apr, 2006 1 commit
    • bar@mysql.com's avatar
      item_timefunc.cc: · a9e30921
      bar@mysql.com authored
        5.0 additional fix for b#18691
        Handle DECIMAL the same with INT and REAL.
      a9e30921
  23. 13 Apr, 2006 1 commit
    • bar@mysql.com's avatar
      Bug#18691: Converting number to UNICODE string returns invalid result. · 45293fc3
      bar@mysql.com authored
      Conversion from int and real numbers to UCS2 didn't work fine: 
      CONVERT(100, CHAR(50) UNICODE)
      CONVERT(103.9, CHAR(50) UNICODE)
      
      The problem appeared because numbers have binary charset, so,
      simple charset recast binary->ucs2 was performed
      instead of real conversion.
      
      Fixed to make numbers pretend to be non-binary.
      45293fc3
  24. 11 Apr, 2006 1 commit
  25. 07 Apr, 2006 2 commits
  26. 28 Mar, 2006 1 commit
  27. 02 Mar, 2006 1 commit
  28. 02 Feb, 2006 1 commit
  29. 18 Jan, 2006 1 commit
    • andrey@lmy004.'s avatar
      - fix bug #16435 (Weekly events execute every second) (WL#1034 Internal CRON) · 0322cb1d
      andrey@lmy004. authored
      Before the interval expression was considered to be in seconds, now it is
      just a number and the type of interval is considered.
      
      - this changeset introduces also fix for bug#16432 (Events: error re interval
        misrepresents the facts)
        the code of event_timed::set_interval() was refactored anyway so it is meaningful to
        fix the bug in the same changeset.
      0322cb1d
  30. 16 Jan, 2006 1 commit
    • gvb@phoenix.(none)'s avatar
      date_formats.test: · 8c69d6ab
      gvb@phoenix.(none) authored
        fix for bug #15828 after review
        doing val_str now before testing of null value secures the function for null values returned by dynamic functions - the fix before was incomplete andy covered constant null values
      8c69d6ab
  31. 14 Jan, 2006 2 commits
  32. 13 Jan, 2006 1 commit
  33. 27 Dec, 2005 1 commit
  34. 22 Dec, 2005 1 commit
  35. 23 Nov, 2005 1 commit
    • monty@mysql.com's avatar
      Table definition cache, part 2 · e42c9809
      monty@mysql.com authored
      The table opening process now works the following way:
      - Create common TABLE_SHARE object
      - Read the .frm file and unpack it into the TABLE_SHARE object
      - Create a TABLE object based on the information in the TABLE_SHARE
        object and open a handler to the table object
      
      Other noteworthy changes:
      - In TABLE_SHARE the most common strings are now LEX_STRING's
      - Better error message when table is not found
      - Variable table_cache is now renamed 'table_open_cache'
      - New variable 'table_definition_cache' that is the number of table defintions that will be cached
      - strxnmov() calls are now fixed to avoid overflows
      - strxnmov() will now always add one end \0 to result
      - engine objects are now created with a TABLE_SHARE object instead of a TABLE object.
      - After creating a field object one must call field->init(table) before using it
      
      - For a busy system this change will give you:
       - Less memory usage for table object
       - Faster opening of tables (if it's has been in use or is in table definition cache)
       - Allow you to cache many table definitions objects
       - Faster drop of table
      e42c9809
  36. 21 Nov, 2005 1 commit
    • bar@mysql.com's avatar
      cast.result: · 3d1c1d7f
      bar@mysql.com authored
        Fixing test results accordingly.
      item_timefunc.cc:
        Displaying BINARY or CHAR in error messages,
        depending on the character set.
      3d1c1d7f
  37. 20 Nov, 2005 1 commit
    • bell@sanja.is.com.ua's avatar
      Inefficient usage of String::append() fixed. · 806f9e24
      bell@sanja.is.com.ua authored
      Bad examples of usage of a string with its length fixed.
      The incorrect length in the trigger file configuration descriptor
        fixed (BUG#14090).
      A hook for unknown keys added to the parser to support old .TRG files.
      806f9e24