- 14 Jun, 2006 10 commits
-
-
evgen@moonbone.local authored
After merge fix
-
evgen@moonbone.local authored
-
evgen@moonbone.local authored
into moonbone.local:/home/evgen/bk-trees/mysql-4.1-opt
-
sergefp@mysql.com authored
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/5.0/B18895
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/5.0/B18895
-
evgen@moonbone.local authored
into moonbone.local:/home/evgen/bk-trees/mysql-5.0-opt
-
gkodinov@mysql.com 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().
-
evgen@moonbone.local authored
into moonbone.local:/work/15962-bug-5.0-opt-mysql
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/5.0/B20195
-
- 13 Jun, 2006 4 commits
-
-
evgen@moonbone.local authored
into moonbone.local:/home/evgen/bk-trees/mysql-4.1-opt
-
gkodinov@mysql.com 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.
-
evgen@moonbone.local authored
into moonbone.local:/work/16377-bug-4.1-opt-mysql
-
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.
-
- 12 Jun, 2006 2 commits
-
-
evgen@moonbone.local authored
into moonbone.local:/home/evgen/bk-trees/mysql-4.1-opt
-
evgen@moonbone.local authored
into moonbone.local:/work/16716-bug-4.1-opt-mysql
-
- 11 Jun, 2006 1 commit
-
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/mysql-5.0-opt
-
- 08 Jun, 2006 2 commits
-
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/5.0/B15355
-
gkodinov@mysql.com 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.
-
- 06 Jun, 2006 1 commit
-
-
evgen@moonbone.local 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().
-
- 03 Jun, 2006 2 commits
-
-
igor@rurik.mysql.com authored
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/mysql-5.0-opt
-
- 02 Jun, 2006 6 commits
-
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/mysql-4.1-opt
-
igor@rurik.mysql.com 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.
-
gkodinov@mysql.com authored
-
gkodinov@mysql.com authored
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/5.0/B4981
-
gkodinov@mysql.com 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.
-
- 30 May, 2006 3 commits
-
-
evgen@moonbone.local authored
After merge fix
-
evgen@moonbone.local authored
-
evgen@moonbone.local authored
into moonbone.local:/work/18360-bug-4.1-mysql-opt
-
- 29 May, 2006 9 commits
-
-
evgen@moonbone.local authored
The IN() function uses agg_cmp_type() to aggregate all types of its arguments to find out some common type for comparisons. In this particular case the char() and the int was aggregated to double because char() can contain values like '1.5'. But all strings which do not start from a digit are converted to 0. thus 'a' and 'z' become equal. This behaviour is reasonable when all function arguments are constants. But when there is a field or an expression this can lead to false comparisons. In this case it makes more sense to coerce constants to the type of the field argument. The agg_cmp_type() function now aggregates types of constant and non-constant items separately. If some non-constant items will be found then their aggregated type will be returned. Thus after the aggregation constants will be coerced to the aggregated type.
-
evgen@moonbone.local authored
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
msvensson@shellback.(none) authored
-
msvensson@shellback.(none) authored
-
msvensson@devsrv-b.mysql.com authored
into devsrv-b.mysql.com:/users/msvensson/mysql-5.0
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-