An error occurred fetching the project authors.
- 07 Nov, 2007 1 commit
-
-
Problem: calling non-constant argument's val_xxx() methods in the ::fix_length_and_dec() is inadmissible. Fix: call the method only for constant arguments.
-
- 04 Dec, 2006 1 commit
-
-
Set null_value in case of wrong data.
-
- 09 Nov, 2006 1 commit
-
-
As get_arg0_date() in the Item_func_last_day::get_date() returns 0000-00-00 date sometimes, we have to check ltime->month for 0 after the call.
-
- 08 Nov, 2006 1 commit
-
-
Problem: After introducing of LC_TIME_NAMES variable, the function date_format() can return international non-ascii characters in month and weekday names. Thus, it cannot return a binary string anymore, because inserting a result of date_format() into a column with non-utf8 character set produces garbage. Fix: date_format() now returns a character string, using "collation_connection" to detect character set and collation for the returned value. This allows to insert results of date_format() properly into columns with various character sets.
-
- 01 Nov, 2006 1 commit
-
-
petr/cps@mysql.com/owlet.local authored
(4.1 version, with post-review fixes) The fix for another Bug (6439) limited FROM_UNIXTIME() to TIMESTAMP_MAX_VALUE which is 2145916799 or 2037-12-01 23:59:59 GMT, however unix timestamp in general is not considered to be limited by this value. All dates up to power(2,31)-1 are valid. This patch extends allowed TIMESTAMP range so, that max TIMESTAMP value is power(2,31)-1. It also corrects FROM_UNIXTIME() and UNIX_TIMESTAMP() functions, so that max allowed UNIX_TIMESTAMP() is power(2,31)-1. FROM_UNIXTIME() is fixed accordingly to allow conversion of dates up to 2038-01-19 03:14:07 UTC. The patch also fixes CONVERT_TZ() function to allow extended range of dates. The main problem solved in the patch is possible overflows of variables, used in broken-time representation to time_t conversion (required for UNIX_TIMESTAMP).
-
- 11 Oct, 2006 1 commit
-
-
Kristofer.Pettersson@naruto. authored
-
- 05 Oct, 2006 1 commit
-
-
The problem appears when we have a space followed by a non-format symbol. Fix: properly skip spaces.
-
- 04 Oct, 2006 1 commit
-
-
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
-
- 22 Sep, 2006 1 commit
-
-
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.
-
- 17 Aug, 2006 1 commit
-
-
jimw@rama.(none) authored
Fix when __attribute__() is stubbed out, add ATTRIBUTE_FORMAT() for specifying __attribute__((format(...))) safely, make more use of the format attribute, and fix some of the warnings that this turns up (plus a bonus unrelated one).
-
- 10 Aug, 2006 1 commit
-
-
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.
-
- 18 Jul, 2006 1 commit
-
-
Please use "ul" when merging this changeset to 5.0.
-
- 04 Jul, 2006 1 commit
-
-
bar@mysql.com authored
(implemented by by Josh Chamas)
-
- 27 Jun, 2006 1 commit
-
-
kroki@mysql.com authored
Dec. 31st, 9999 is still a valid date, only starting with Jan 1st 10000 things become invalid (Bug #12356)
-
- 13 Jun, 2006 1 commit
-
-
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.
-
- 04 May, 2006 2 commits
-
-
jani@ua141d10.elisa.omakaista.fi authored
TIME_FORMAT using "%l:%i" returns 36:00 with 24:00:00 in TIME column
-
jani@ua141d10.elisa.omakaista.fi authored
-
- 02 May, 2006 1 commit
-
-
ramil@mysql.com authored
-
- 25 Apr, 2006 1 commit
-
-
ramil@mysql.com authored
-
- 13 Apr, 2006 1 commit
-
-
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.
-
- 16 Jan, 2006 1 commit
-
-
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
-
- 14 Jan, 2006 2 commits
-
-
gvb@phoenix.(none) authored
fix for bug #15828 after review
-
gvb@phoenix.(none) authored
fix for bug#15828 after review
-
- 13 Jan, 2006 1 commit
-
-
gvb@phoenix.(none) authored
problem was not checking 2nd parameter of str_to_date against NULL
-
- 01 Nov, 2005 1 commit
-
-
monty@mysql.com authored
Removed wrong fix for bug #14009 (use of abs() on null value causes problems with filesort) Mark that add_time(), time_diff() and str_to_date() can return null values
-
- 25 Oct, 2005 1 commit
-
-
evgen@moonbone.local authored
collation By default constant strings in second parameter of date_time() have case insensitive collation. Because of this expressions date_format(f,'%m') and date_format(f,'%M') wrongly becomes equal, which results in choosing wrong column to sort by. Now if second parameter of date_format() is constant then it's collation is changed to case sensitive.
-
- 19 Jul, 2005 1 commit
-
-
monty@mishka.local authored
-
- 24 Jun, 2005 1 commit
-
-
ramil@mysql.com authored
-
- 05 Jun, 2005 1 commit
-
-
serg@serg.mylan authored
'#pragma interface' (that comes with the #include'd header file)
-
- 03 Jun, 2005 1 commit
-
-
monty@mysql.com authored
Ensure that 'null_value' is not accessed before val() is called in FIELD() functions Fixed initialization of key maps. This fixes some problems with keys when you have more than 64 keys Fixed that ROLLUP don't always create a temporary table. This fix ensures that func_gconcat.test results are now predictable
-
- 02 Jun, 2005 1 commit
-
-
kent@mysql.com authored
Set #pragma implementation" earlier Many files: Need to include <my_global.h> before #ifdef USE_PRAGMA_IMPLEMENTATION
-
- 26 May, 2005 1 commit
-
-
msvensson@neptunus.(none) authored
Added some more ifdefs for "#pragma interface"
-
- 25 Apr, 2005 1 commit
-
-
dlenev@brandersnatch.localdomain authored
"'func_sapdb' fails on 64bit build hosts")
-
- 28 Mar, 2005 1 commit
-
-
dlenev@brandersnatch.localdomain authored
result" (and similar bug in ADDTIME/SUBTIME). Both Item_func_add_time/Item_func_timediff::val_str() now use calc_time_diff() function which was backported from 5.0 (and which was was fixed to properly handle microseconds part of its second argument). Also now we correctly set sign of result in case when first argument is negative and second is positive.
-
- 27 Jan, 2005 1 commit
-
-
bar@mysql.com authored
CAST now always return a well-formed character string.
-
- 26 Jan, 2005 1 commit
-
-
dlenev@brandersnatch.localdomain authored
does not work well together". Now using simplier and more correct implementation of st_lex::unlink_first_table()/link_first_table_back() (It also nicely handles case when global table list is created because of implictly used time zone tables). (2nd attempt) Fix for bug #7705 "CONVERT_TZ() crashes with subquery/WHERE on index column". Implemented new approach for caching objects for constant time zone arguments. Now instead of determining whenever these arguments are constants and performing time zone lookup at fix_fields() stage, we do it on first get_date() invocation. Cleanup of global @@time_zone variable handling.
-
- 24 Jan, 2005 1 commit
-
-
serg@serg.mylan authored
-
- 12 Jan, 2005 1 commit
-
-
dlenev@brandersnatch.localdomain authored
-
- 30 Dec, 2004 2 commits
-
-
dlenev@brandersnatch.localdomain authored
correctly even with zero month and day" and bug #7515 "from_unixtime(0) now returns NULL instead of the Epoch" into 4.1 tree.
-
dlenev@mysql.com authored
the Epoch". (With after review fixes).
-