mirror of
https://github.com/MariaDB/server.git
synced 2025-01-18 04:53:01 +01:00
47311e8e87
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. |
||
|---|---|---|
| .. | ||
| include | ||
| lib | ||
| misc | ||
| ndb | ||
| r | ||
| std_data | ||
| suite/jp | ||
| t | ||
| create-test-result | ||
| fix-result | ||
| init_db.sql | ||
| install_test_db.sh | ||
| Makefile.am | ||
| my_create_tables.c | ||
| my_manage.c | ||
| my_manage.h | ||
| mysql-test-run.pl | ||
| mysql-test-run.sh | ||
| mysql_test_run_new.c | ||
| README | ||
| README.gcov | ||
| resolve-stack | ||
| suppress.purify | ||
This directory contains a test suite for the MySQL daemon. To run the currently existing test cases, simply execute ./mysql-test-run in this directory. It will fire up the newly built mysqld and test it. Note that you do not have to have to do "make install", and you could actually have a co-existing MySQL installation. The tests will not conflict with it. All tests must pass. If one or more of them fail on your system, please read the following manual section for instructions on how to report the problem: http://dev.mysql.com/doc/mysql/en/mysql-test-suite.html If you want to use an already running MySQL server for specific tests, use the --extern option to mysql-test-run. Please note that in this mode, the test suite expects you to provide the names of the tests to run. For example, here is the command to run the "alias" and "analyze" tests with an external server: mysql-test-run --extern alias analyze To match your setup, you might also need to provide --socket, --user, and other relevant options. With no test cases named on the command line, mysql-test-run falls back to the normal "non-extern" behavior. The reason for this is that some tests cannot run with an external server. You can create your own test cases. To create a test case, create a new file in the t subdirectory using a text editor. The file should have a .test extension. For example: xemacs t/test_case_name.test In the file, put a set of SQL statements that create some tables, load test data, and run some queries to manipulate it. We would appreciate it if you name your test tables t1, t2, t3 ... (to not conflict too much with existing tables). Your test should begin by dropping the tables you are going to create and end by dropping them again. This ensures that you can run the test over and over again. If you are using mysqltest commands (like result file names) in your test case, you should create the result file as follows: mysql-test-run --record test_case_name or mysqltest --record < t/test_case_name.test If you only have a simple test cases consisting of SQL statements and comments, you can create the test case in one of the following ways: mysql-test-run --record test_case_name mysql test < t/test_case_name.test > r/test_case_name.result mysqltest --record --record-file=r/test_case_name.result < t/test_case_name.test When this is done, take a look at r/test_case_name.result - If the result is incorrect, you have found a bug. In this case, you should edit the test result to the correct results so that we can verify that the bug is corrected in future releases. To submit your test case, put your .test file and .result file(s) into a tar.gz archive, add a README that explains the problem, ftp the archive to ftp://support.mysql.com/pub/mysql/secret/ and send a mail to bugs@lists.mysql.com