An error occurred fetching the project authors.
  1. 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
  2. 07 Sep, 2006 1 commit
  3. 04 Sep, 2006 1 commit
  4. 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
  5. 27 Jun, 2006 1 commit
  6. 19 Jun, 2006 1 commit
  7. 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
  8. 17 May, 2006 1 commit
  9. 02 May, 2006 1 commit
  10. 25 Apr, 2006 1 commit
  11. 24 Jun, 2005 1 commit
  12. 30 Dec, 2004 1 commit
  13. 15 Nov, 2004 1 commit
  14. 21 Jun, 2004 2 commits
  15. 18 Jun, 2004 1 commit
    • dlenev@brandersnatch.localdomain's avatar
      WL#1264 "Per-thread time zone support infrastructure". · 09ba29e5
      dlenev@brandersnatch.localdomain authored
      Added basic per-thread time zone functionality (based on public
      domain elsie-code). Now user can select current time zone
      (from the list of time zones described in system tables).
      All NOW-like functions honor this time zone, values of TIMESTAMP
      type are interpreted as values in this time zone, so now
      our TIMESTAMP type behaves similar to Oracle's TIMESTAMP WITH
      LOCAL TIME ZONE (or proper PostgresSQL type).
        
      WL#1266 "CONVERT_TZ() - basic time with time zone conversion 
      function".
        
      Fixed problems described in Bug #2336 (Different number of warnings 
      when inserting bad datetime as string or as number). This required
      reworking of datetime realted warning hadling (they now generated 
      at Field object level not in conversion functions).
        
      Optimization: Now Field class descendants use table->in_use member
      instead of current_thd macro.
      09ba29e5
  16. 13 May, 2004 1 commit
  17. 28 Apr, 2004 1 commit
    • monty@mysql.com's avatar
      Fixed http address in some scripts (Bug #3460) · f10d098f
      monty@mysql.com authored
      Output TIMESTAMP in 4.1 format for 4.1 tables (or for TIMESTAMP(19)) (portability fix)
      Fixed that INTERVAL can handle big integers. (Bug #3498)
      Fixed that hostname="" works identical as hostname="%" for table/column grants (Bug #3473)
      f10d098f
  18. 25 Mar, 2004 1 commit
  19. 23 Mar, 2004 1 commit
  20. 15 Mar, 2004 1 commit
  21. 19 Dec, 2003 1 commit
    • monty@mysql.com's avatar
      Fixes after merge with 4.0 · 031390a9
      monty@mysql.com authored
      Cleaned up embedded library access and query cache handling
      Changed min stack size to 128K (to allow longer MyISAM keys)
      Fixed wrong priority for XOR (should be less than NEG to get -1^1 to work)
      031390a9
  22. 12 Dec, 2003 1 commit
    • monty@mysql.com's avatar
      Fix autoincrement for signed columns (Bug #1366) · f995a5f4
      monty@mysql.com authored
      Fixed problem with char > 128 in QUOTE() function. (Bug #1868)
      Disable creation of symlinks if my_disable_symlink is set
      Fixed searching of TEXT with end space. (Bug #1651)
      Fixed caching bug in multi-table-update where same table was used twice. (Bug #1711)
      Fixed problem with UNIX_TIMESTAMP() for timestamps close to 0. (Bug #1998)
      Fixed timestamp.test
      f995a5f4
  23. 10 Dec, 2003 1 commit
  24. 07 Dec, 2003 1 commit
    • gluh@gluh.mysql.r18.ru's avatar
      WL#1175: more default_week_formats for iso compatibility · 48317785
      gluh@gluh.mysql.r18.ru authored
      New formats added for 'week()' function and 'default_week_format' option(4 - 7).
      Next formats is supported now:
      *Value* *Meaning*
        `0'     Week starts on Sunday; First Sunday of the year starts week 1.
        	  Week() returns 0-53.
        `1'     Week starts on Monday; Weeks numbered according to ISO 8601:1988.
      	  Week() returns 0-53.
        `2'     Week starts on Sunday; First Sunday of the year starts week 1.
        	  Week() returns 1-53.
        `3'     Week starts on Monday; Weeks numbered according to ISO 8601:1988.
      	  Week() returns 1-53.
        `4'     Week starts on Sunday; Weeks numbered according to ISO 8601:1988.
      	  Week() returns 0-53.
        `5'     Week starts on Monday;  First Monday of the year starts week 1.
        	  Week() returns 0-53.
        `6'     Week starts on Sunday; Weeks numbered according to ISO 8601:1988.
      	  Week() returns 1-53.
        `7'     Week starts on Monday;  First Monday of the year starts week 1.
        	  Week() returns 1-53.
      48317785
  25. 17 Nov, 2003 1 commit
  26. 30 Oct, 2003 1 commit
  27. 11 Aug, 2003 1 commit
  28. 19 Jun, 2003 1 commit
  29. 11 Jun, 2003 1 commit
  30. 19 Feb, 2003 1 commit
  31. 14 Dec, 2002 1 commit
    • monty@mashka.mysql.fi's avatar
      Fixes for binary protocol (complement to last push) · d49167ba
      monty@mashka.mysql.fi authored
      Changed timestamp to return string in YYYY-MM-DD HH:MM:SS format.
      DATE_ADD() and related functions now returns correct DATE/DATETIME type depending on argument types.
      Now all tests passes, still some work left to remove warnings in log files from mysql-test-run
      d49167ba
  32. 24 Nov, 2002 1 commit
  33. 22 Nov, 2002 1 commit
  34. 12 Nov, 2002 1 commit
  35. 06 Nov, 2002 1 commit
  36. 05 Nov, 2002 1 commit
  37. 04 Nov, 2001 2 commits
  38. 03 Nov, 2001 1 commit