An error occurred fetching the project authors.
- 11 Dec, 2008 1 commit
-
-
Gleb Shchepa authored
IF(..., CAST(longtext AS UNSIGNED), signed_val) (was: LEFT JOIN on inline view crashes server) Select from a LONGTEXT column wrapped with an expression like "IF(..., CAST(longtext_column AS UNSIGNED), smth_signed)" failed an assertion or crashed the server. IFNULL function was affected too. LONGTEXT column item has a maximum length of 32^2-1 bytes, at the same time this is a maximum possible length of any MySQL item. CAST(longtext_column AS UNSIGNED) returns some unsigned numeric result of length 32^2-1, so the result of IF/IFNULL function of this number and some other signed number will have text length of (32^2-1)+1=32^2 (one byte for the minus sign) - there is integer overflow, and the length is equal to zero. That caused assert/crash. The bug has been fixed by the same solution as in the CASE function implementation.
-
- 28 Nov, 2008 1 commit
-
-
Sergey Glukhov authored
-
- 26 Nov, 2008 1 commit
-
-
Tatiana A. Nurnberg authored
We pretended that TIMEDIFF() would always return positive results; this gave strange results in comparisons of the TIMEDIFF(low,hi)<TIME(0) type that rendered a negative result, but still gave false in comparison. We also inadvertantly dropped the sign when converting times to decimal. CAST(time AS DECIMAL) handles signs of the times correctly. TIMEDIFF() marked up as signed. Time/date comparison code switched to signed for clarity.
-
- 17 Nov, 2008 1 commit
-
-
Alexey Botchkov authored
Item_func_div didn't calculate the precision of the result properly. The result of 5/0.0001 is 5000 so we have to add decimals of the divisor to the planned precision. per-file comments: mysql-test/r/type_newdecimal.result Bug#31616 div_precision_increment description looks wrong test result fixed mysql-test/t/type_newdecimal.test Bug#31616 div_precision_increment description looks wrong test case sql/item_func.cc Bug#31616 div_precision_increment description looks wrong precision must be increased with args[1]->decimals parameter
-
- 11 Nov, 2008 1 commit
-
-
Sergey Vojtovich authored
With fix for bug 25951 index hints are ignored for fulltext searches, as handling of fulltext indexes is different from handling regular indexes. Meaning it is not possible to implement true index hints support for fulltext indexes within the scope of current fulltext architecture. The problem is that prior to fix for bug 25951, some useful index hints still could be given for boolean mode searches. This patch implements special index hints support for fulltext indexes with the following characteristics: - all index hints are still ignored for NLQ mode searches - it cannot work without an index; - for 5.1 and up index hints FOR ORDER BY and FOR GROUP BY are still ignored for fulltext indexes; - boolean mode searches honor USE/FORCE/IGNORE INDEX hints; - as opposed to index hints for regular indexes, index hints for fulltext BOOLEAN mode searches affect the usage of the index for the whole query.
-
- 30 Jul, 2008 1 commit
-
-
Georgi Kodinov authored
min() and max() functions are implemented in MySQL as macros. This means that max(a,b) is expanded to: ((a) > (b) ? (a) : (b)) Note how 'a' is quoted two times. Now imagine 'a' is a recursive function call that's several 10s of levels deep. And the recursive function does max() with a function arg as well to dive into recursion. This means that simple function call can take most of the clock time. Identified and fixed several such calls to max()/min() : including the IF() sql function implementation.
-
- 29 Mar, 2008 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
-
- 28 Feb, 2008 1 commit
-
-
davi@mysql.com/endora.local authored
The problem is that passing anything other than a integer to a limit clause in a prepared statement would fail. This limitation was introduced to avoid replication problems (e.g: replicating the statement with a string argument would cause a parse failure in the slave). The solution is to convert arguments to the limit clause to a integer value and use this converted value when persisting the query to the log.
-
- 15 Feb, 2008 1 commit
-
-
Problem: SLEEP(0) never returns on 64-bit Mac OS X due to a bug in pthread_cond_timedwait(). Fix: when given a very short timeout just return immediately.
-
- 31 Jan, 2008 1 commit
-
-
evgen@moonbone.local authored
Simple subselects are pulled into upper selects. This operation substitutes the pulled subselect for the first item from the select list of the subselect. If an alias is defined for a subselect it is inherited by the replacement item. As this is done after fix_fields phase this alias isn't showed if the replacement item is a stored function. This happens because the Item_func_sp::make_field function makes send field from its result_field and ignores the defined alias. Now when an alias is defined the Item_func_sp::make_field function sets it for the returned field.
-
- 14 Jan, 2008 1 commit
-
-
mhansson/martin@linux-st28.site authored
The ROUND(X, D) function would change the Item::decimals field during execution to achieve the effect of a dynamic number of decimal digits. This caused a series of bugs: Bug #30617:Round() function not working under some circumstances in InnoDB Bug #33402:ROUND with decimal and non-constant cannot round to 0 decimal places Bug #30889:filesort and order by with float/numeric crashes server Fixed by never changing the number of shown digits for DECIMAL when used with a nonconstant number of decimal digits.
-
- 06 Dec, 2007 1 commit
-
-
additional fixes for BDB and correct assignment of both signed and unsigned 64-bit data to unsigned system variables
-
- 27 Nov, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
There's currently no way of knowing the determinicity of an UDF. And the optimizer and the sequence() UDFs were making wrong assumptions about what the is_const member means. Plus there was no implementation of update_system_tables() causing the optimizer to overwrite the information returned by the <udf>_init function. Fixed by equating the assumptions about the semantics of is_const and providing a implementation of update_used_tables(). Added a TODO item for the UDF API change needed to make a better implementation.
-
- 26 Nov, 2007 1 commit
-
-
thek@adventure.(none) authored
Sending several "KILL QUERY" statements to target a connection running "SELECT SLEEP" could freeze the server. The locking order in Item_func_sleep was wrong and this could lead to a dead lock. This patch solves the issue by resolving the locking order properly.
-
- 29 Oct, 2007 1 commit
-
-
gluh@mysql.com/eagle.(none) authored
There are two problems with ROUND(X, D) on an exact numeric (DECIMAL, NUMERIC type) field of a table: 1) The implementation of the ROUND function would change the number of decimal places regardless of the value decided upon in fix_length_and_dec. When the number of decimal places is not constant, this would cause an inconsistent state where the number of digits was less than the number of decimal places, which crashes filesort. Fixed by not allowing the ROUND operation to add any more decimal places than was decided in fix_length_and_dec. 2) fix_length_and_dec would allow the number of decimals to be greater than the maximium configured value for constant values of D. This led to the same crash as in (1). Fixed by not allowing the above in fix_length_and_dec.
-
- 24 Oct, 2007 1 commit
-
-
svoj@mysql.com/june.mysql.com authored
ucs2 doesn't provide required by fulltext ctype array. Crash happens because fulltext attempts to use unitialized ctype array. Fixed by converting ucs2 fields to compatible utf8 analogue.
-
- 17 Oct, 2007 1 commit
-
-
dkatz@damien-katzs-computer.local authored
Previously, UDF *_init functions were passed constant strings with erroneous lengths. The length came from the containing variable's size, not the length of the value itself. Now the *_init functions get the constant as a null terminated string with the correct length supplied too.
-
- 04 Oct, 2007 2 commits
-
-
df@pippilotta.erinye.com authored
-
anozdrin/alik@station. authored
This actually, fix for the patch for bug-27354. The problem with the patch was that Item_func_sp::used_tables() was updated, but Item_func_sp::const_item() was not. So, for Item_func_sp, we had the following inconsistency: - used_tables() returned RAND_TABLE, which means that the item can produce "random" results; - but const_item() returned TRUE, which means that the item is a constant one. The fix is to change Item_func_sp::const_item() behaviour: it must return TRUE (an item is a constant one) only if a stored function is deterministic and each of its arguments (if any) is a constant item.
-
- 28 Sep, 2007 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
When calculating the result length of an integer DIV function the number of decimals was used without checking the result type first. Thus an uninitialized number of decimals was used for some types. This caused an excessive amount of memory to be allocated for the field's buffer and crashed the server. Fixed by using the number of decimals only for data types that can have decimals and thus have valid decimals number.
-
- 22 Sep, 2007 1 commit
-
-
evgen@sunlight.local authored
type of the result. There are several functions that accept parameters of different types. The result field type of such functions was determined based on the aggregated result type of its arguments. As the DATE and the DATETIME types are represented by the STRING type, the result field type of the affected functions was always STRING for DATE/DATETIME arguments. The affected functions are COALESCE, IF, IFNULL, CASE, LEAST/GREATEST, CASE. Now the affected functions aggregate the field types of their arguments rather than their result types and return the result of aggregation as their result field type. The cached_field_type member variable is added to the number of classes to hold the aggregated result field type. The str_to_date() function's result field type now defaults to the MYSQL_TYPE_DATETIME. The agg_field_type() function is added. It aggregates field types with help of the Field::field_type_merge() function. The create_table_from_items() function now uses the item->tmp_table_field_from_field_type() function to get the proper field when the item is a function with a STRING result type.
-
- 05 Sep, 2007 1 commit
-
-
dkatz@damien-katzs-computer.local authored
Previously, UDF *_init functions were passed constant strings with erroneous lengths. The length came from the containing variable's size, not the length of the value itself. Now the *_init functions get the constant as a null terminated string with the correct length supplied too.
-
- 03 Aug, 2007 1 commit
-
-
bar@mysql.com/bar.myoffice.izhnet.ru authored
(Regression, caused by a patch for the bug 22646). Problem: when result type of date_format() was changed from binary string to character string, mixing date_format() with a ascii column in CONCAT() stopped to work. Fix: - adding "repertoire" flag into DTCollation class, to mark items which can return only pure ASCII strings. - allow character set conversion from pure ASCII to other character sets.
-
- 02 Aug, 2007 1 commit
-
-
Problem: thd->thread_specific_used flag is not set executing a statement containig connection_id() function using PS protocol, that leads to improper binlog event creation. Fix: set the flag in the Item_func_connection_id::fix_fields().
-
- 01 Aug, 2007 1 commit
-
-
restores from mysqlbinlog out Problem: using "mysqlbinlog | mysql" for recoveries the connection_id() result may differ from what was used when issuing the statement. Fix: if there is a connection_id() in a statement, write to binlog SET pseudo_thread_id= XXX; before it and use the value later on.
-
- 19 Jul, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
Optimization of queries with DETERMINISTIC functions in the WHERE clause was not effective: sequential scan was always used. Now a SF with the DETERMINISTIC flags is treated as constant when it's arguments are constants (or a SF doesn't has arguments).
-
- 16 Jun, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
DECIMAL column was used instead of BIGINT for the minimal possible BIGINT (-9223372036854775808). The Item_func_neg::fix_length_and_dec has been adjusted to to inherit the type of the argument in the case when it's an Item_int object whose value is equal to LONGLONG_MIN.
-
- 15 Jun, 2007 1 commit
-
-
igor@olga.mysql.com authored
of its arguments was evaluated to NULL, while the predicate LOCATE(str,NULL) IS NULL erroneously was evaluated to FALSE. This happened because the Item_func_locate::fix_length_and_dec method by mistake set the value of the maybe_null flag for the function item to 0. In consequence of this the function was considered as the one that could not ever return NULL.
-
- 13 Jun, 2007 2 commits
-
-
igor@olga.mysql.com authored
was erroneously converted to double, while the result of ROUND(<decimal expr>, <int literal>) was preserved as decimal. As a result of such a conversion the value of ROUND(D,A) could differ from the value of ROUND(D,val(A)) if D was a decimal expression. Now the result of the ROUND function is never converted to double if the first argument is decimal.
-
joerg@trift2. authored
Improved check for thread identity in the "embedded" case, provided by Monty. This finishes the fixes for bug#27078.
-
- 12 Jun, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
- fixed wrong test case for bug 20903 - closed the dangling connections in trigger.test - GET_LOCK() and RELEASE_LOCK() now produce more detailed log - fixed an omission in GET_LOCK() : assign the thread_id when acquiring the lock.
-
- 03 Jun, 2007 1 commit
-
-
evgen@moonbone.local authored
Corrected test case result for the bug#28494. item_func.h, item_func.cc: Corrected function names after fix for the bug#28494.
-
- 02 Jun, 2007 2 commits
-
-
evgen@moonbone.local authored
Post fix for bug#28494. The Item_func_set_user_var::check method now silently doesn't use result_field if it isn't defined.
-
evgen@moonbone.local authored
This is an additional fix. Item::val_xxx methods are supposed to use original data source and Item::val_xxx_result methods to use the item's result field. But for the Item_func_set_user_var class val_xxx_result methods were mapped to val_xxx methods. This leads, in particular, to producing bad sort keys and thus wrong order of the result set of queries with group by/order by clauses. The set of val_xxx_result methods is added to the Item_func_set_user_var class. It's the same as the val_xxx set of method but uses the result_field to return a value.
-
- 31 May, 2007 1 commit
-
-
evgen@moonbone.local authored
The end_update() function uses the Item::save_org_in_field() function to save original values of items into the group buffer. But for the Item_func_set_user_var this method was mapped to the save_in_field method. The latter function wrongly decides to use the result_field. This leads to saving incorrect value in the grouping buffer and wrong result of the whole query. The can_use_result_field argument of the bool type is added to the Item_func_set_user_var::save_in_field() function. If it is set to FALSE then the item's result field won't be used. Otherwise it will be detected whether the result field will be used (old behaviour). Two wrapping functions for the function above are added to the Item_func_set_user_var class: the save_in_field(Field *field, bool no_conversions) - it calls the above function with the can_use_result_field set to TRUE. the save_org_in_field(Field *field) - same, but the can_use_result_field is set to FALSE.
-
- 29 May, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
longer showing SP names. SHOW CREATE VIEW uses Item::print() methods to reconstruct the statement text from the parse tree. The print() method for stored procedure calls needs allocate space to print the function's quoted name. It was incorrectly calculating the length of the buffer needed (was too short). Fixed to reflect the actual space needed.
-
- 23 May, 2007 2 commits
-
-
evgen@moonbone.local authored
If a stored function or a trigger was killed it had aborted but no error was thrown. This allows the caller statement to continue without a notice. This may lead to a wrong data being inserted/updated to/deleted as in such cases the correct result of a stored function isn't guaranteed. In the case of triggers it allows the caller statement to ignore kill signal and to waste time because of re-evaluation of triggers that always will fail because thd->killed flag is still on. Now the Item_func_sp::execute() and the sp_head::execute_trigger() functions check whether a function or a trigger were killed during execution and throws an appropriate error if so. Now the fill_record() function stops filling record if an error was reported through thd->net.report_error.
-
mhansson@dl145s.mysql.com authored
being used without being def Inside method Item_func_unsigned::val_int, the variable value can be returned without being initialized when the CAST argument is of type DECIMAL and has a NULL value. This gives a run-time error when building debug binaries using Visual C++ 2005. Solution: Initialize value to 0
-
- 16 May, 2007 1 commit
-
-
msvensson@pilot.blaudden authored
- Since isinf() portability across various platforms and compilers is a complicated question, we should not use it directly. Instead, the my_isinf() macro should be used, which is defined as an alias to the system-defined isinf() if it is safe to use, or a workaround implementation otherwise
-
- 14 May, 2007 1 commit
-
-
df@pippilotta.erinye.com authored
-