An error occurred fetching the project authors.
- 11 Apr, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
The function CRC32() returns unsigned integer. But the metadata (the unsigned flag) for the function was set incorrectly. As a result type arithmetics based on the function's metadata (like finding the concise type of an temporary table column to hold the result) returned incorrect results. Fixed by returning correct type information. This fix is based on code contributed by Martin Friebe (martin@hybyte.com) on 2007-03-30.
-
- 28 Mar, 2007 1 commit
-
-
msvensson@pilot.blaudden authored
- Add extra test case from bug#27073 - Change "if" to be optimized for count > 0
-
- 10 Mar, 2007 1 commit
-
-
evgen@moonbone.local authored
When the SUBSTRING() function was used over a LONGTEXT field the max_length of the SUBSTRING() result was wrongly calculated and set to 0. As the max_length parameter is used while tmp field creation it limits the length of the result field and leads to printing an empty string instead of the correct result. Now the Item_func_substr::fix_length_and_dec() function correctly calculates the max_length parameter.
-
- 09 Mar, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
Fixed boundry checks in the INSERT() function: were one off.
-
- 02 Mar, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
to return NULL for non-NULL arguments. This is not the case as it can return NULL for invalid hexidecimal strings. Fixed by setting the maybe_null flag.
-
- 23 Feb, 2007 1 commit
-
-
msvensson@pilot.blaudden authored
- Return empty string also if count is unsigned and value is 0
-
- 11 Jan, 2007 1 commit
-
-
evgen@moonbone.local authored
correctly. The Item_func::print method was used to print the Item_func_encode and the Item_func_decode objects. The last argument to ENCODE and DECODE functions is a plain C string and thus Item_func::print wasn't able to print it. The print() method is added to the Item_func_encode class. It correctly prints the Item_func_encode and the Item_func_decode objects.
-
- 19 Dec, 2006 1 commit
-
-
tsmith/tim@siva.hindu.god authored
Handling of large signed/unsigned values was not consistent, so some string functions could return bogus results. The current fix is to simply patch up the val_str() methods for those string items. It would be good clean this code up in general, to make similar problems much harder to make. This is left as an exercise for the reader.
-
- 20 Nov, 2006 1 commit
-
-
monty@mysql.com/nosik.monty.fi authored
(Mostly in DBUG_PRINT() and unused arguments) Fixed bug in query cache when used with traceing (--with-debug) Fixed memory leak in mysqldump Removed warnings from mysqltest scripts (replaced -- with #)
-
- 16 Nov, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
-
- 08 Nov, 2006 1 commit
-
-
cmiller@zippy.cornsilk.net authored
on large length Problem: Most (all) of the numeric inputs were being coerced into int (32 bit) sized variables. Works OK for sane inputs; any input larger than 2^32 (or 2^31 for signed vars) exihibited predictable wrapping behavior (up to about 10^18) and then started having really strange behaviour past that point (since the conversion to 64 bit int from the DECIMAL type can do weird things on out of range numbers). Solution: 1) Add many tests. 2) Convert input from (u)long type to (u)longlong. 3) Do (sometimes multiple) sanity checks on input, keeping in mind that sometimes a negative longlong is not a negative longlong (if the unsigned_flag is set). 4) Emulate existing behavior w/rt negative and "small" out-of-bounds values.
-
- 09 Sep, 2006 1 commit
-
-
igor@rurik.mysql.com authored
-
- 07 Sep, 2006 1 commit
-
-
igor@rurik.mysql.com authored
equal constant under any circumstances. In fact this substitution can be allowed if the field is not of a type string or if the field reference serves as an argument of a comparison predicate.
-
- 19 Jul, 2006 1 commit
-
-
igor@olga.mysql.com authored
for class Item_func_trim. For 4.1 it caused wrong output for EXPLAIN EXTENDED commands if expressions with the TRIM function of two arguments were used. For 5.0 it caused an error message when trying to select from a view with the TRIM function of two arguments. This unexpected error message was due to the fact that the print method for the class Item_func_trim was inherited from the class Item_func. Yet the TRIM function does not take a list of its arguments. Rather it takes the arguments in the form: [{BOTH | LEADING | TRAILING} [remstr] FROM] str) | [remstr FROM] str
-
- 07 Jul, 2006 1 commit
-
-
bar@myoffice.izhnet.ru authored
Adding test case. item_strfunc.cc: bug#11728 string function LEFT, strange undocumented behaviour Fixing LEFT and RIGHT return NULL if the second argument is NULL.
-
- 06 Jul, 2006 1 commit
-
-
igor@olga.mysql.com authored
The implementation of the method Item_func_reverse::val_str for the REVERSE function modified the argument of the function. This led to wrong results for expressions that contained REVERSE(ref) if ref occurred somewhere else in the expressions.
-
- 13 Jun, 2006 1 commit
-
-
ramil@mysql.com authored
-
- 28 May, 2006 1 commit
-
-
evgen@moonbone.local authored
argument can lead to a wrong result. md5() and sha() functions treat their arguments as case sensitive strings. But when they are compared their arguments were compared as a case insensitive strings which leads to two functions with different arguments and thus different results to being identical. This can lead to a wrong decision made in the range optimizer and thus lead to a wrong result set. Item_func_md5::fix_length_and_dec() and Item_func_sha::fix_length_and_dec() functions now set binary collation on their arguments.
-
- 18 May, 2006 1 commit
-
-
jimw@mysql.com authored
The 'decimals' member of Item_func was being improperly initialized, which resulted in improper results when handling large numeric values.
-
- 08 May, 2006 1 commit
-
-
tnurnberg@mysql.com authored
load_file() string-function should return NULL rather than throw an error if the file doesn't exist, as per the manual.
-
- 14 Mar, 2006 1 commit
-
-
jimw@mysql.com authored
Results of string functions were being converted to decimals by first being converted to integers, resulting in a loss of precision.
-
- 24 Nov, 2005 1 commit
-
-
jimw@mysql.com authored
-
- 11 Oct, 2005 1 commit
-
-
monty@mysql.com authored
- CHAR() now returns binary string as default - CHAR(X*65536+Y*256+Z) is now equal to CHAR(X,Y,Z) independent of the character set for CHAR() - Test for both ETIMEDOUT and ETIME from pthread_cond_timedwait() (Some old systems returns ETIME and it's safer to test for both values than to try to write a wrapper for each old system) - Fixed new introduced bug in NOT BETWEEN X and X - Ensure we call commit_by_xid or rollback_by_xid for all engines, even if one engine has failed - Use octet2hex() for all conversion of string to hex - Simplify and optimize code
-
- 06 Oct, 2005 1 commit
-
-
monty@mysql.com authored
Ensure that ccache is also used for C programs mysql: Ensure that 'delimiter' works the same way in batch mode as in normal mode mysqldump: Change to use ;; (instead of //) as a stored procedure/trigger delimiter Fixed test cases by adding missing DROP's and rename views to be of type 'v#' Removed MY_UNIX_PATH from fn_format() Removed current_db_used from TABLE_LIST Removed usage of 'current_thd' in Item_splocal Removed some compiler warnings A bit faster longlong2str code
-
- 22 Sep, 2005 1 commit
-
-
jimw@mysql.com authored
-
- 08 Aug, 2005 1 commit
-
-
patg@krsna.patg.net authored
BUG #11104 Took out the offset-=delimiter_length-1 out of the for loop. It was causing basically this: select substring_index('the king of the the hill', 'the', -2) to not work. The first iteration, offset would be initialised to 24, then strstr would point at 'the king of the the* hill' ('*'means right before the character following), returning a offset of 16. The for loop would then decrement offset by two (3 - 1), to 14, now pointing at "the king of th*e the hill", _skipping_ past the 'e' in the second to last 'the', and therefore strstr would never have a chance of matching the second to last 'the', then moving on to the 'the' at the begginning of the string! In a nutshell, offset was being decremented by too great a value, preventing the second to last 'the' from being ever found, hence the result of 'king of the the hill' from the query that is reported in the bug report func_str.test: BUG #11104 Added tests to make sure fix addresses issues in original bug report func_str.result: BUG #11104 New results for new tests
-
- 01 Aug, 2005 1 commit
-
-
patg@krsna.patg.net authored
needed to be fixed in earlier versions) Fixed the iteration of how substrings are handled with negative indexes in SUBSTRING_INDEX
-
- 28 Jul, 2005 1 commit
-
-
monty@mysql.com authored
-
- 22 Jul, 2005 1 commit
-
-
jimw@mysql.com authored
client via mysql_fetch_fields(). (Bug #11311)
-
- 13 Jul, 2005 1 commit
-
-
gluh@eagle.intranet.mysql.r18.ru authored
added out of range handling
-
- 29 Jun, 2005 1 commit
-
-
igor@rurik.mysql.com authored
Added test cases for bug #11469. item_strfunc.h: Fixed bug #11469: wrong implementation of the not_null_tables method for CONCAT_WS.
-
- 28 Jun, 2005 1 commit
-
-
bell@sanja.is.com.ua authored
-
- 23 Jun, 2005 1 commit
-
-
igor@rurik.mysql.com authored
Added a test case for bug #10124. sql_select.h, item_subselect.cc, sql_select.cc: Fixed bug #10124. The copy method of the store_key classes can return STORE_KEY_OK=0, STORE_KEY_FATAL=1, STORE_KEY_CONV=2 now. field.cc: Fixed bug #10124. When ussuing a warning the store methods return 2 instead of 1 now.
-
- 20 Jun, 2005 1 commit
-
-
msvensson@neptunus.(none) authored
- Print warning that says display width is not supported for datatype TIMESTAMP, if user tries to create a TIMESTAMP column with display width. - Use display width for TIMESTAMP only in type_timestamp test to make sure warning is displayed correctly.
-
- 01 Jun, 2005 1 commit
-
-
jimw@mysql.com authored
-
- 01 Apr, 2005 1 commit
-
-
monty@mysql.com authored
CAST() now produces warnings when casting a wrong INTEGER or CHAR values. This also applies to implicite string to number casts. (Bug #5912) ALTER TABLE now fails in STRICT mode if it generates warnings. Inserting a zero date in a DATE, DATETIME or TIMESTAMP column during TRADITIONAL mode now produces an error. (Bug #5933)
-
- 24 Mar, 2005 1 commit
-
-
bar@mysql.com authored
in some cases, because "charset(x) = 'string'" was considered as "x is not null" due to incorrect not_null_tables().
-
- 16 Mar, 2005 1 commit
-
-
bar@mysql.com authored
not always correct for NULL values. Now they always result a non NULL value even the argument is NULL. It is more usefull for debugging purposes.
-
- 09 Mar, 2005 1 commit
-
-
igor@rurik.mysql.com authored
Added a test case for bug #8669. item_strfunc.cc: Fixed bug #8669. Function AES_DECRYPT can return NULL value.
-
- 23 Feb, 2005 1 commit
-
-
gluh@gluh.mysql.r18.ru authored
-