- 25 May, 2007 1 commit
-
-
unknown authored
sometimes `mysqldump --hex-blob' overruned output buffer by '\0' byte. The dump_table() function has been fixed to reserve 1 byte more for the last '\0' byte of dumped string. client/mysqldump.c: Fixed bug #28522. The dump_table() function has been fixed to reserve 1 byte more for the last '\0' byte of dumped string. mysql-test/t/mysqldump.test: Updated test case for bug #28522. mysql-test/r/mysqldump.result: Updated test case for bug #28522.
-
- 23 May, 2007 2 commits
-
-
unknown authored
into moonbone.local:/mnt/gentoo64/work/27563-bug-5.0-opt-mysql sql/item_func.cc: Auto merged sql/sp_head.cc: Auto merged sql/sql_base.cc: Auto merged
-
unknown 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. sql/item_func.cc: Bug#27563: Stored functions and triggers wasn't throwing an error when killed. Now the Item_func_sp::execute() function checks whether a trigger was killed during execution and throws an appropriate error if so. sql/sp_head.cc: Bug#27563: Stored functions and triggers wasn't throwing an error when killed. Now the sp_head::execute_trigger() function checks whether a function was killed during execution and throws an appropriate error if so. sql/sql_base.cc: Bug#27563: Stored functions and triggers wasn't throwing an error when killed. Now the fill_record() function stops filling record if an error was reported through thd->net.report_error. mysql-test/r/kill.result: Added a test case for the bug#27563: Stored functions and triggers wasn't throwing an error when killed. mysql-test/t/kill.test: Added a test case for the bug#27563: Stored functions and triggers wasn't throwing an error when killed.
-
- 22 May, 2007 4 commits
-
-
unknown authored
into dl145s.mysql.com:/users/mhansson/mysql/autopush/mysql-5.0o-pushee sql/sql_select.cc: Auto merged
-
unknown authored
into magare.gmz:/home/kgeorge/mysql/autopush/B28476-5.0-opt sql/sql_base.cc: Auto merged sql/table.h: Auto merged
-
unknown authored
When processing the USE/FORCE index hints the optimizer was not checking if the indexes specified are enabled (see ALTER TABLE). Fixed by: Backporting the fix for bug 20604 to 5.0 mysql-test/r/key.result: Test for BUG 20604. The important part of the test is the explain output that tests what indexes are used. mysql-test/r/myisam.result: Bug #28476: test cases mysql-test/t/key.test: Bug 20604: The minimal test case that reveals the bug. The optimizer for aggregates relies on keys disabled with ALTER TABLE ... DISABLE KEYS not being in the set TABLE::keys_in_use_for_query. When the execution engine tries to use a disabled index, MyISAM returns an error. mysql-test/t/myisam.test: Bug #28476: test cases sql/sql_base.cc: Bug #28476: - Ignore disabled indexes in USE/FORCE index sql/sql_select.cc: Bug 20604 : The intersection operation between table->s->keys_in_use and table->keys_in_use_for_query is no longer necessary. We can trust that the latter is a subset of the former. sql/table.h: Bug 20604: Added comments to TABLE_SHARE::keys_in_use and TABLE::keys_in_use_for_query.
-
unknown authored
into dl145s.mysql.com:/users/mhansson/mysql/push/bug23856/mysql-5.0o-pushee sql/item_sum.cc: Auto merged sql/sql_select.cc: Auto merged mysql-test/r/func_gconcat.result: Bug#23856: Manually merged mysql-test/t/func_gconcat.test: Bug#23856: Manually merged
-
- 21 May, 2007 11 commits
-
-
unknown authored
-
unknown authored
mode. When a new DATE/DATETIME field without default value is being added by the ALTER TABLE the '0000-00-00' value is used as the default one. But it wasn't checked whether such value was allowed by the set sql mode. Due to this '0000-00-00' values was allowed for DATE/DATETIME fields even in the NO_ZERO_DATE mode. Now the mysql_alter_table() function checks whether the '0000-00-00' value is allowed for DATE/DATETIME fields by the set sql mode. The new error_if_not_empty flag is used in the mysql_alter_table() function to indicate that it should abort if the table being altered isn't empty. The new new_datetime_field field is used in the mysql_alter_table() function for error throwing purposes. The new error_if_not_empty parameter is added to the copy_data_between_tables() function to indicate the it should return error if the source table isn't empty. mysql-test/t/alter_table.test: Added a test case for the bug#27507: Wrong DATETIME value was allowed by ALTER TABLE in the NO_ZERO_DATE mode. mysql-test/r/alter_table.result: Added a test case for the bug#27507: Wrong DATETIME value was allowed by ALTER TABLE in the NO_ZERO_DATE mode. sql/sql_table.cc: Bug#27507: Wrong DATETIME value was allowed by ALTER TABLE in the NO_ZERO_DATE mode. Now the mysql_alter_table() function checks whether the '0000-00-00' value is allowed for DATE/DATETIME fields by the set sql mode. The new error_if_not_empty flag is used in the mysql_alter_table() function to indicate that it should abort if the table being altered isn't empty. The new new_datetime_field field is used in the mysql_alter_table() function for error throwing purposes. The new error_if_not_empty parameter is added to the copy_data_between_tables() function to indicate the it should return error if the source table isn't empty.
-
unknown authored
into mysql.com:/home/hf/work/27984/my50-27984
-
unknown authored
into mysql.com:/home/hf/work/27984/my50-27984 mysql-test/r/type_newdecimal.result: merging mysql-test/t/type_newdecimal.test: merging
-
unknown authored
decimal_round failed to perform a correct rounding of a decimal number if its first nine digits were '9'. It just sets those digits to 0. mysql-test/r/type_newdecimal.result: Bug #27984 Long Decimal Maths produces truncated results. test result mysql-test/t/type_newdecimal.test: Bug #27984 Long Decimal Maths produces truncated results. test case strings/decimal.c: Bug #27984 Long Decimal Maths produces truncated results. when to == from we break the data if we do to->buf[0]=0 So now doing this after the data is moved and only if we really need to set to->buf[0] to zero
-
unknown authored
into mysql.com:/home/hf/work/28361/my50-28361
-
unknown authored
-
unknown authored
into mysql.com:/home/hf/work/27894/my50-27894
-
unknown authored
-
unknown authored
result max length changed for the 'decimal' fields so test results have to be fixed mysql-test/r/ps_2myisam.result: Bug #28361 Buffer overflow in DECIMAL code on Windows test result fixed mysql-test/r/ps_3innodb.result: Bug #28361 Buffer overflow in DECIMAL code on Windows test result fixed mysql-test/r/ps_4heap.result: Bug #28361 Buffer overflow in DECIMAL code on Windows test result fixed mysql-test/r/ps_5merge.result: Bug #28361 Buffer overflow in DECIMAL code on Windows test result fixed mysql-test/r/ps_7ndb.result: Bug #28361 Buffer overflow in DECIMAL code on Windows test result fixed
-
unknown authored
into magare.gmz:/home/kgeorge/mysql/work/B22855-5.0-opt sql/item_subselect.cc: Auto merged mysql-test/r/subselect3.result: manual merge mysql-test/t/subselect3.test: manual merge
-
- 20 May, 2007 1 commit
-
-
unknown authored
my_decimal in some cases can contain more decimal digits than is officially supported (DECIMAL_MAX_PRECISION), so we need to prepare bigger buffer for the resulting string. mysql-test/r/type_newdecimal.result: bug #28361 Buffer overflow in DECIMAL code on Windows test result mysql-test/t/type_newdecimal.test: bug #28361 Buffer overflow in DECIMAL code on Windows test case This test case doesn't fall in most cases even without the fix Still valgrind shows the problemn sql/my_decimal.h: bug #28361 Buffer overflow in DECIMAL code on Windows DECIMAL_MAX_POSSIBLE_PRECISION introduced to be used in places, when we need to check for the number of digits technicaly possible in my_decimal. DECIMAL_MAX_STR_LENGTH fixed as it has to fit for the MAX_POSSIBLE_PRECISION
-
- 18 May, 2007 7 commits
-
-
unknown authored
into mysql.com:/d2/hf/mrg/mysql-5.0-opt mysql-test/r/ps.result: Auto merged mysql-test/t/ps.test: Auto merged sql/item.cc: Auto merged
-
unknown authored
into sergbook.mysql.com:/usr/home/serg/Abk/mysql-5.0 mysql-test/r/ps.result: Auto merged mysql-test/t/ps.test: Auto merged sql/item.cc: Auto merged
-
unknown authored
mysql-test/r/sp_trans.result: added cleanup mysql-test/r/strict.result: added cleanup mysql-test/t/sp_trans.test: added cleanup mysql-test/t/strict.test: added cleanup
-
unknown authored
into mysql.com:/d2/hf/mrg/mysql-5.0-opt
-
unknown authored
into mysql.com:/d2/hf/mrg/mysql-5.0-opt mysql-test/r/ps.result: Auto merged mysql-test/t/ps.test: Auto merged sql/item.cc: Auto merged
-
unknown authored
into mysql.com:/d2/hf/mrg/mysql-4.1-opt
-
unknown authored
into moonbone.local:/mnt/gentoo64/work/28261-bug-5.0-opt-mysql
-
- 17 May, 2007 4 commits
-
-
unknown authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug28337
-
unknown 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). mysql-test/t/type_datetime.test: A test case is added for the bug#28261: Wrong DATETIME comparison result when the GET_USER_VAR function is involved. mysql-test/r/type_datetime.result: A test case is added for the bug#28261: Wrong DATETIME comparison result when the GET_USER_VAR function is involved. sql/item_cmpfunc.cc: Bug#28261: Wrong DATETIME comparison result when the GET_USER_VAR function 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).
-
unknown authored
Conversion errors when constructing the condition for an IN predicates were treated as if the affected column contains NULL. If such a IN predicate is inside NOT we get wrong results. Corrected the handling of conversion errors in an IN predicate that is resolved by unique_subquery (through subselect_uniquesubquery_engine). mysql-test/r/subselect3.result: Bug#22855: test case mysql-test/t/subselect3.test: Bug#22855: test case sql/item_subselect.cc: Bug#22855: corrected the handling of conversion errors and NULL key values in IN predicate that is resolved by index lookup.
-
unknown authored
subqueries in WHERE conditions. This bug was introduced by the patch for bug 27321. mysql-test/r/subselect.result: Added a test case for bug #28337. mysql-test/t/subselect.test: Added a test case for bug #28337. sql/item.cc: Fixed bug #28337: wrong results for grouping queries with correlated subqueries in WHERE conditions. This bug was introduced by the patch for bug 27321. Now in the Item_field::fix_outer_field function we create an Item_outer_ref object for an outer reference only if it is used in the SELECT list or in the HAVING clause of the subquery against which the reference is resolved.
-
- 16 May, 2007 10 commits
-
-
unknown authored
into trift2.:/MySQL/M50/push-5.0
-
unknown authored
into trift2.:/MySQL/M50/push-5.0
-
unknown authored
into mysql.com:/home/hf/work/8663/my50-8663
-
unknown authored
into mysql.com:/home/hf/work/8663/my50-8663
-
unknown authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build
-
unknown authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build
-
unknown authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build
-
unknown authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build
-
unknown authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build
-
unknown authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build-work
-