- 16 Jun, 2006 2 commits
-
-
unknown authored
into rurik.mysql.com:/home/igor/mysql-5.0-opt mysql-test/t/func_group.test: Auto merged sql/field.cc: Auto merged sql/opt_sum.cc: Auto merged mysql-test/r/func_group.result: SCCS merged
-
unknown authored
into rurik.mysql.com:/home/igor/mysql-5.0-opt sql/field.cc: Auto merged sql/opt_sum.cc: Auto merged
-
- 15 Jun, 2006 3 commits
-
-
unknown authored
into moonbone.local:/work/18175-bug-5.0-opt
-
unknown authored
resulted in a wrong error message. The nest_level counter indicates the depth of nesting for a subselect. It is needed to properly resolve aggregate functions in nested subselects. Obviously it shouldn't be incremented for UNION parts because they have the same level of nesting. This counter was incremented by 1 in the mysql_new_select() function for any new select and wasn't decremented for UNION parts. This resulted in wrongly reported error messages. Now the nest_level counter is decremented by 1 for any union part. mysql-test/t/union.test: Added test case for the bug#18175: The nest_level counter wasn't decremented for union parts which resulted in a wrong error message. mysql-test/r/union.result: Added test case for the bug#18175: The nest_level counter wasn't decremented for union parts which resulted in a wrong error message. sql/sql_yacc.yy: Fixed bug#18175: The nest_level counter wasn't decremented for union parts which resulted in a wrong error message. Now the nest_level counter is decremented by 1 for any union part.
-
unknown authored
into moonbone.local:/work/19789-bug-5.0-opt-mysql
-
- 14 Jun, 2006 14 commits
-
-
unknown authored
After merge fix mysql-test/r/func_time.result: After merge fix mysql-test/r/func_concat.result: After merge fix mysql-test/r/cast.result: After merge fix sql/item_cmpfunc.h: After merge fix sql/item_cmpfunc.cc: After merge fix sql/field.cc: After merge fix
-
unknown authored
mysql-test/r/cast.result: Auto merged mysql-test/t/func_time.test: Auto merged sql/item_cmpfunc.h: Auto merged sql/item_strfunc.cc: Auto merged sql/item_timefunc.cc: Auto merged sql/item_timefunc.h: Auto merged sql/opt_sum.cc: Auto merged sql/structs.h: Auto merged
-
unknown authored
into moonbone.local:/home/evgen/bk-trees/mysql-4.1-opt
-
unknown authored
-
unknown authored
into mysql.com:/home/kgeorge/mysql/5.0/B18895
-
unknown authored
into mysql.com:/home/kgeorge/mysql/5.0/B18895
-
unknown authored
into moonbone.local:/home/evgen/bk-trees/mysql-5.0-opt
-
unknown authored
The Field::eq() considered instances of Field_bit that differ only in bit_ptr/bit_ofs equal. This caused equality conditions optimization (build_equal_items_for_cond()) to make bad field substitutions that result in wrong predicates. Field_bit requires an overloaded eq() function that checks the bit_ptr/bit_ofs in addition to Field::eq(). mysql-test/r/select.result: Bug #18895: BIT values cause joins to fail - test case mysql-test/t/select.test: Bug #18895: BIT values cause joins to fail - test case sql/field.h: Bug #18895: BIT values cause joins to fail - eq() method overloaded for Field_bit
-
unknown authored
into moonbone.local:/work/15962-bug-5.0-opt-mysql
-
unknown authored
into mysql.com:/home/kgeorge/mysql/5.0/B20195
-
unknown authored
mysql-test/r/func_group.result: Added another test case for bug #18206. mysql-test/t/func_group.test: Added another test case for bug #18206.
-
unknown authored
into rurik.mysql.com:/home/igor/mysql-4.1-opt sql/field.cc: Auto merged
-
unknown authored
into rurik.mysql.com:/home/igor/mysql-5.0-opt mysql-test/t/ctype_utf8.test: Auto merged sql/opt_sum.cc: Auto merged mysql-test/r/ctype_utf8.result: Manual merge sql/field.cc: Manual merge
-
unknown authored
This bug in Field_string::cmp resulted in a wrong comparison with keys in partial indexes over multi-byte character fields. Given field a is declared as a varchar(16) collate utf8_unicode_ci INDEX(a(4)) gives us an example of such an index. Wrong key comparisons could lead to wrong result sets if the selected query execution plan used a range scan by a partial index over a utf8 character field. This also caused wrong results in many other cases. mysql-test/r/ctype_utf8.result: Added test cases for bug #14896. mysql-test/t/ctype_utf8.test: Added test cases for bug #14896.
-
- 13 Jun, 2006 4 commits
-
-
unknown authored
into moonbone.local:/home/evgen/bk-trees/mysql-4.1-opt
-
unknown authored
The INSERT DELAYED should not maintain its own private auto-increment counter, because this is assuming that other threads cannot insert into the table while the INSERT DELAYED thread is inserting, which is a wrong assumption. So the start of processing of a batch of INSERT rows in the INSERT DELAYED thread must be treated as a start of a new statement and cached next_insert_id must be cleared. mysql-test/r/delayed.result: test suite for the bug mysql-test/t/delayed.test: test suite for the bug sql/sql_insert.cc: Reset auto-increment cacheing before processing the next batch of inserts in the handler thread
-
unknown authored
into moonbone.local:/work/16377-bug-4.1-opt-mysql
-
unknown 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. mysql-test/r/cast.result: Fixed wrong test case result after bug fix#16377. sql/item_timefunc.h: Fixed bug#16377: result of DATE/TIME functions were compared as strings which can lead to a wrong result. The result_as_longlong() function is set to return TRUE for these classes: Item_date, Item_date_func, Item_func_curtime, Item_func_sec_to_time, Item_date_typecast, Item_time_typecast, Item_datetime_typecast, Item_func_makedate. sql/item_timefunc.cc: Fixed bug#16377: result of DATE/TIME functions were compared as strings which can lead to a wrong result.Correct val_int() methods are implemented for classes Item_date_typecast, Item_func_makedate, Item_time_typecast, Item_datetime_typecast. sql/item_cmpfunc.h: Fixed bug#16377: result of DATE/TIME functions were compared as strings which can lead to a wrong result. 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. sql/field.cc: Fixed bug#16377: result of DATE/TIME functions were compared as strings which can lead to a wrong result. Field::set_warning(), Field::set_datetime_warning() now use current_thd to get thd if table isn't set. sql/item_cmpfunc.cc: Fixed bug#16377: result of DATE/TIME functions were compared as strings which can lead to a wrong result. 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. sql/item.h: 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. mysql-test/t/func_time.test: Added test case fot bug#16377: result of DATE/TIME functions were compared as strings which can lead to a wrong result. mysql-test/r/func_time.result: Added test case fot bug#16377: result of DATE/TIME functions were compared as strings which can lead to a wrong result.
-
- 12 Jun, 2006 2 commits
- 11 Jun, 2006 1 commit
-
-
unknown authored
into rurik.mysql.com:/home/igor/mysql-5.0-opt
-
- 08 Jun, 2006 2 commits
-
-
unknown authored
into mysql.com:/home/kgeorge/mysql/5.0/B15355
-
unknown authored
query Problem: There was a wrong context assigned to the columns that were added in insert_fields() when expanding a '*'. When this is done in a prepared statement it causes fix_fields() to fail to find the table that these columns reference. Actually the right context is set in setup_natural_join_row_types() called at the end of setup_tables(). However when executed in a context of a prepared statement setup_tables() resets the context, but setup_natural_join_row_types() was not setting it to the correct value assuming it has already done so. Solution: The top-most, left-most NATURAL/USING join must be set as a first_name_resolution_table in context even when operating on prepared statements. mysql-test/r/join.result: testsuite for the bug mysql-test/t/join.test: testsuite for the bug sql/sql_base.cc: The context must be set even when executed as prepared statement.
-
- 07 Jun, 2006 1 commit
-
-
unknown authored
The st_lex::which_check_option_applicable() function controls for which statements WITH CHECK OPTION clause should be taken into account. REPLACE and REPLACE_SELECT wasn't in the list which results in allowing REPLACE to insert wrong rows in a such view. The st_lex::which_check_option_applicable() now includes REPLACE and REPLACE_SELECT in the list of statements for which WITH CHECK OPTION clause is applicable. mysql-test/t/replace.test: Added test case for bug#19789: REPLACE was allowed for a VIEW with CHECK OPTION enabled. mysql-test/r/replace.result: Added test case for bug#19789: REPLACE was allowed for a VIEW with CHECK OPTION enabled. sql/sql_lex.h: Fixed bug#19789: REPLACE was allowed for a VIEW with CHECK OPTION enabled. The st_lex::which_check_option_applicable() now includes REPLACE and REPLACE_SELECT in the list of statements for which WITH CHECK OPTION clause is applicable.
-
- 06 Jun, 2006 1 commit
-
-
unknown authored
To calculate its max_length the CONCAT() function is simply sums max_lengths of its arguments but when the collation of an argument differs from the collation of the CONCAT() max_length will be wrong. This may lead to a data truncation when a tmp table is used, in UNIONS for example. The Item_func_concat::fix_length_and_dec() function now recalculates the max_length of an argument when the mbmaxlen of the argument differs from the mbmaxlen of the CONCAT(). mysql-test/t/func_concat.test: Added test case for bug#15962:CONCAT() in UNION may lead to a data trucation. mysql-test/r/func_concat.result: Added test case for bug#15962:CONCAT() in UNION may lead to a data trucation. sql/item_strfunc.cc: Fixed bug#15962: CONCAT() in UNION may lead to a data trucation. The Item_func_concat::fix_length_and_dec() function now recalculates the max_length of an argument when the mbmaxlen of the argument differs from the mbmaxlen of the CONCAT().
-
- 03 Jun, 2006 2 commits
- 02 Jun, 2006 6 commits
-
-
unknown authored
into rurik.mysql.com:/home/igor/mysql-4.1-opt
-
unknown authored
The bug report revealed two problems related to min/max optimization: 1. If the length of a constant key used in a SARGable condition for for the MIN/MAX fields is greater than the length of the field an unwanted warning on key truncation is issued; 2. If MIN/MAX optimization is applied to a partial index, like INDEX(b(4)) than can lead to returning a wrong result set. mysql-test/r/func_group.result: Added test cases for bug #18206. mysql-test/t/func_group.test: Added test cases for bug #18206. sql/opt_sum.cc: Fixed bug #18206. Suppressed the warning about data truncation when store_val_in_field was used to store keys for the field used in MIN/MAX optimization. Blocked MIN/MAX optimization for partial keys, such as in INDEX(b(4)). sql/sql_select.cc: Fixed bug #18206. Added a parameter for the function store_val_in_field allowing to control setting warnings about data truncation in the function. sql/sql_select.h: Fixed bug #18206. Added a parameter for the function store_val_in_field allowing to control setting warnings about data truncation in the function.
-
unknown authored
-
unknown authored
-
unknown authored
into mysql.com:/home/kgeorge/mysql/5.0/B4981 mysql-test/t/select.test: Auto merged sql/opt_range.cc: Auto merged mysql-test/r/select.result: merged
-
unknown authored
3.23 regression test failure The member SEL_ARG::min_flag was not initialized, due to which the condition for no GEOM_FLAG in function key_or did not choose "Range checked for each record" as the correct access method. mysql-test/r/select.result: testcase for 'Range checked' access method mysql-test/t/select.test: testcase for 'Range checked' access method sql/opt_range.cc: All of the class members initialized
-
- 30 May, 2006 2 commits