An error occurred fetching the project authors.
- 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.
-
- 15 Jul, 2008 1 commit
-
-
Gleb Shchepa authored
Note: item->null_value is not updated before a call to item->store(), item->is_null() is not too (in common case).
-
- 14 Jul, 2008 1 commit
-
-
Gleb Shchepa authored
and value-list The server returns unexpected results if a right side of the NOT IN clause consists of NULL value and some constants of the same type, for example: SELECT * FROM t WHERE NOT t.id IN (NULL, 1, 2) may return 3, 4, 5 etc if a table contains these values. The Item_func_in::val_int method has been modified: unnecessary resets of an Item_func_case::has_null field value has been moved outside of an argument comparison loop. (Also unnecessary re-initialization of the null_value field has been moved).
-
- 28 Mar, 2008 1 commit
-
-
iggy@amd64.(none) authored
- Backported the 5.1 DBUG to 5.0. - Avoid memory cleanup race on Windows client for CTRL-C
-
- 22 Feb, 2008 1 commit
-
-
anozdrin/alik@quad. authored
between 5.0 and 5.1. The problem was that in the patch for Bug#11986 it was decided to store original query in UTF8 encoding for the INFORMATION_SCHEMA. This approach however turned out to be quite difficult to implement properly. The main problem is to preserve the same IS-output after dump/restore. So, the fix is to rollback to the previous functionality, but also to fix it to support multi-character-set-queries properly. The idea is to generate INFORMATION_SCHEMA-query from the item-tree after parsing view declaration. The IS-query should: - be completely in UTF8; - not contain character set introducers. For more information, see WL4052.
-
- 13 Feb, 2008 1 commit
-
-
gshchepa/uchum@host.loc authored
type conversion. Instead of copying of whole character string from a temporary buffer, the server copied a short-living pointer to that string into a long-living structure. That has been fixed.
-
- 30 Jan, 2008 2 commits
-
-
mkindahl@dl145h.mysql.com authored
-
mkindahl@dl145h.mysql.com authored
-
- 09 Dec, 2007 1 commit
-
-
igor@olga.mysql.com authored
with a fix for bug 32694.
-
- 08 Dec, 2007 1 commit
-
-
timour/tkatchaounov@lapi.mysql.com authored
The problem was that when convert_constant_item is called for subqueries, this happens when we already started executing the top-level query, and the field argument of convert_constant_item pointed to a valid table row. In turn convert_constant_item used the field buffer to compute the value of its item argument. This copied the item's value into the field, and made equalities with outer references always true. The fix saves/restores the original field's value when it belongs to an outer table.
-
- 23 Nov, 2007 1 commit
-
-
Problem: INTERVAL function implementation doesn't handle NULL range values. Fix: skip NULL ranges looking for a proper one.
-
- 21 Nov, 2007 1 commit
-
-
Problem: caching 00000000-00000099 dates as integer values we're improperly shifting them up twice in the get_datetime_value(). Fix: don't shift cached DATETIME values up for the second time.
-
- 17 Nov, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
Comparison of a BIGINT NOT NULL column with a constant arithmetic expression that evaluates to NULL caused error 1048: "Column '...' cannot be null". Made convert_constant_item() check if the constant expression is NULL before attempting to store it in a field. Attempts to store NULL in a NOT NULL field caused query errors.
-
- 10 Nov, 2007 2 commits
-
-
gshchepa/uchum@gleb.loc authored
After adding an index the <VARBINARY> IN (SELECT <BINARY> ...) clause returned a wrong result: the VARBINARY value was illegally padded with zero bytes to the length of the BINARY column for the index search. (<VARBINARY>, ...) IN (SELECT <BINARY>, ... ) clauses are affected too.
-
BETWEEN was more lenient with regard to what it accepted as a DATE/DATETIME in comparisons than greater-than and less-than were. ChangeSet makes < > comparisons similarly robust with regard to trailing garbage (" GMT-1") and "missing" leading zeros. Now all three comparators behave similarly in that they throw a warning for "junk" at the end of the data, but then proceed anyway if possible. Before < > fell back on a string- (rather than date-) comparison when a warning-condition was raised in the string-to-date conversion. Now the fallback only happens on actual errors, while warning- conditions still result in a warning being to delivered to the client.
-
- 29 Oct, 2007 1 commit
-
-
JOIN, and ORDER BY Problem: improper maximum length calculation of the CASE function leads to decimal value truncation (storing/retrieving decimal field values). Fix: accurately calculate maximum length/unsigned flag/decimals parameters of the CASE function.
-
- 24 Oct, 2007 1 commit
-
-
bar@mysql.com/bar.myoffice.izhnet.ru authored
Additional fix for valgrind warning
-
- 17 Oct, 2007 1 commit
-
-
kaa@polly.(none) authored
CPUs / Intel's ICC compile The bug is a combination of two problems: 1. IA64/ICC MySQL binaries use glibc's qsort(), not the one in mysys. 2. The order relation implemented by join_tab_cmp() is not transitive, i.e. it is possible to choose such a, b and c that (a < b) && (b < c) but (c < a). This implies that result of a sort using the relation implemented by join_tab_cmp() depends on the order in which elements are compared, i.e. the result is implementation-specific. Since choose_plan() uses qsort() to pre-sort the join tables using join_tab_cmp() as a compare function, the results of the sorting may vary depending on qsort() implementation. It is neither possible nor important to implement a better ordering algorithm in join_tab_cmp(). Therefore the only way to fix it is to force our own qsort() to be used by renaming it to my_qsort(), so we don't depend on linker to decide that. This patch also "fixes" bug #20530: qsort redefinition violates the standard.
-
- 11 Oct, 2007 2 commits
-
-
cmiller@zippy.cornsilk.net authored
-
gkodinov/kgeorge@magare.gmz authored
The special case with NULL as a regular expression was handled at prepare time. But in this special case the item was not marked as fixed. This caused an assertion at execution time. Fixed my marking the item as fixed even when known to return NULL at prepare time.
-
- 10 Oct, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
precision > 0 && scale <= precision'. A sign of a resulting item of the IFNULL function was not updated and the maximal length of this result was calculated improperly. Correct algorithm was copy&pasted from the IF function implementation.
-
- 05 Oct, 2007 1 commit
-
-
bar@mysql.com/bar.myoffice.izhnet.ru authored
Problem: The "regex" library written by Henry Spencer does not support tricky character sets like UCS2. Fix: convert tricky character sets to UTF8 before calling regex functions.
-
- 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.
-
- 13 Aug, 2007 1 commit
-
-
monty@mysql.com/nosik.monty.fi authored
Faster thr_alarm() Added 'Opened_files' status variable to track calls to my_open() Don't give warnings when running mysql_install_db Added option --source-install to mysql_install_db I had to do the following renames() as used polymorphism didn't work with Forte compiler on 64 bit systems index_read() -> index_read_map() index_read_idx() -> index_read_idx_map() index_read_last() -> index_read_last_map()
-
- 15 Jul, 2007 4 commits
-
-
evgen@moonbone.local authored
A typo fixed.
-
evgen@moonbone.local authored
Fixed compiler warning.
-
evgen@moonbone.local authored
A comment changed.
-
evgen@moonbone.local authored
The get_time_value function is added. It is used to obtain TIME values both from items the can return time as an integer and from items that can return time only as a string. The Arg_comparator::compare_datetime function now uses pointer to a getter function to obtain values to compare. Now this function is also used for comparison of TIME values. The get_value_func variable is added to the Arg_comparator class. It points to a getter function for the DATE/DATETIME/TIME comparator.
-
- 12 Jul, 2007 1 commit
-
-
evgen@moonbone.local authored
Time values were compared by the BETWEEN function as strings. This led to a wrong result in cases when some of arguments are less than 100 hours and other are greater. Now if all 3 arguments of the BETWEEN function are of the TIME type then they are compared as integers.
-
- 11 Jul, 2007 1 commit
-
-
evgen@moonbone.local authored
Time values were compared as strings. This led to a wrong comparison result when comparing values one of which is under 100 hours and another is over 100 hours. Now when the Arg_comparator::set_cmp_func function sees that both items to compare are of the TIME type it sets the comparator to the Arg_comparator::compare_e_int or the Arg_comparator::compare_int_unsigned functions.
-
- 11 Jun, 2007 1 commit
-
-
evgen@moonbone.local authored
Post merge fix.
-
- 05 Jun, 2007 1 commit
-
-
evgen@moonbone.local authored
integer constants. This bug is introduced by the fix for bug#16377. Before the fix the Item_func_between::fix_length_and_dec method converted the second and third arguments to the type of the first argument if they were constant and the first argument is of the DATE/DATETIME type. That approach worked well for integer constants and sometimes produced bad result for string constants. The fix for the bug#16377 wrongly removed that code at all and as a result of this the comparison of a DATETIME field and an integer constant was carried out in a wrong way and sometimes led to wrong result sets. Now the Item_func_between::fix_length_and_dec method converts the second and third arguments to the type of the first argument if they are constant, the first argument is of the DATE/DATETIME type and the DATETIME comparator isn't applicable.
-
- 30 May, 2007 1 commit
-
-
kaa@polly.local authored
Got rid of log_01[], because we don't really need it. Division and log_10[] can always be used instead, which is also a more precise way. This is for bug #28121.
-
- 29 May, 2007 1 commit
-
-
evgen@moonbone.local authored
type assertion. The bug was introduced by the patch for bug #16377. The "+ INTERVAL" (Item_date_add_interval) function detects its result type by the type of its first argument. But in some cases it returns STRING as the result type. This happens when, for example, the first argument is a DATE represented as string. All this makes the get_datetime_value() function misinterpret such result and return wrong DATE/DATETIME value. To avoid such cases in the fix for #16377 the code that detects correct result field type on the first execution was added to the Item_date_add_interval::get_date() function. Due to this the result field type of the Item_date_add_interval item stored by the send_fields() function differs from item's result field type at the moment when the item is actually sent. It causes an assertion failure. Now the get_datetime_value() detects that the DATE value is returned by some item not only by checking the result field type but also by comparing the returned value with the 100000000L constant - any DATE value should be less than this value. Removed result field type adjusting code from the Item_date_add_interval::get_date() function.
-
- 28 May, 2007 1 commit
-
-
kaa@polly.local authored
When storing a large number to a FLOAT or DOUBLE field with fixed length, it could be incorrectly truncated if the field's length was greater than 31. This patch also does some code cleanups to be able to reuse code which is common between Field_float::store() and Field_double::store().
-
- 24 May, 2007 1 commit
-
-
jani@linux-th5m.site authored
-
- 17 May, 2007 1 commit
-
-
evgen@moonbone.local authored
is involved. The Arg_comparator::compare_datetime() comparator caches its arguments if they are constants i.e. const_item() returns true. The Item_func_get_user_var::const_item() returns true or false based on the current query_id and the query_id where the variable was created. Thus even if a query can change its value its const_item() still will return true. All this leads to a wrong comparison result when an object of the Item_func_get_user_var class is involved. Now the Arg_comparator::can_compare_as_dates() and the get_datetime_value() functions never cache result of the GET_USER_VAR() function (the Item_func_get_user_var class).
-
- 16 May, 2007 1 commit
-
-
msvensson@pilot.blaudden authored
Made year 2000 handling more uniform Removed year 2000 handling out from calc_days() The above removes some bugs in date/datetimes with year between 0 and 200 Now we get a note when we insert a datetime value into a date column For default values to CREATE, don't give errors for warning level NOTE Fixed some compiler failures Added library ws2_32 for windows compilation (needed if we want to compile with IOCP support) Removed duplicate typedef TIME and replaced it with MYSQL_TIME Better (more complete) fix for: Bug#21103 "DATE column not compared as DATE" Fixed properly Bug#18997 "DATE_ADD and DATE_SUB perform year2K autoconversion magic on 4-digit year value" Fixed Bug#23093 "Implicit conversion of 9912101 to date does not match cast(9912101 as date)"
-
- 15 May, 2007 1 commit
-
-
evgen@moonbone.local authored
function. A wrong condition was used to check that the Arg_comparator::can_compare_as_dates() function calculated the value of the string constant. When comparing a non-const STRING function with a constant DATETIME function it leads to saving an arbitrary value as a cached value of the DATETIME function. Now the Arg_comparator::set_cmp_func() function initializes the const_value variable to the impossible DATETIME value (-1) and this const_value is cached only if it was changed by the Arg_comparator::can_compare_as_dates() function.
-
- 14 May, 2007 1 commit
-
-
tnurnberg@blasphemy.mysql.com authored
Made year 2000 handling more uniform Removed year 2000 handling out from calc_days() The above removes some bugs in date/datetimes with year between 0 and 200 Now we get a note when we insert a datetime value into a date column For default values to CREATE, don't give errors for warning level NOTE Fixed some compiler failures Added library ws2_32 for windows compilation (needed if we want to compile with IOCP support) Removed duplicate typedef TIME and replaced it with MYSQL_TIME Better (more complete) fix for: Bug#21103 "DATE column not compared as DATE" Fixed properly Bug#18997 "DATE_ADD and DATE_SUB perform year2K autoconversion magic on 4-digit year value" Fixed Bug#23093 "Implicit conversion of 9912101 to date does not match cast(9912101 as date)"
-