An error occurred fetching the project authors.
- 24 May, 2007 2 commits
-
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug28561
-
igor@olga.mysql.com authored
CHECK OPTION and a subquery in WHERE condition. The abort was triggered by setting the value of join->tables for subqueries in the function JOIN::cleanup. This function was called after an invocation of the JOIN::join_free method for subqueries used in WHERE condition.
-
- 23 May, 2007 2 commits
-
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/27563-bug-5.0-opt-mysql
-
evgen@moonbone.local 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.
-
- 22 May, 2007 4 commits
-
-
mhansson@dl145s.mysql.com authored
into dl145s.mysql.com:/users/mhansson/mysql/autopush/mysql-5.0o-pushee
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B28476-5.0-opt
-
gkodinov/kgeorge@magare.gmz 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
-
mhansson@dl145s.mysql.com authored
into dl145s.mysql.com:/users/mhansson/mysql/push/bug23856/mysql-5.0o-pushee
-
- 21 May, 2007 11 commits
-
-
igor@olga.mysql.com authored
-
evgen@moonbone.local 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.
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/27984/my50-27984
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/27984/my50-27984
-
holyfoot/hf@mysql.com/hfmain.(none) 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.
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/28361/my50-28361
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/27894/my50-27894
-
mhansson@dl145s.mysql.com authored
-
holyfoot/hf@mysql.com/hfmain.(none) authored
result max length changed for the 'decimal' fields so test results have to be fixed
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/work/B22855-5.0-opt
-
- 20 May, 2007 1 commit
-
-
holyfoot/hf@mysql.com/hfmain.(none) 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.
-
- 18 May, 2007 7 commits
-
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/d2/hf/mrg/mysql-5.0-opt
-
serg@sergbook.mysql.com authored
into sergbook.mysql.com:/usr/home/serg/Abk/mysql-5.0
-
serg@sergbook.mysql.com authored
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/d2/hf/mrg/mysql-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/d2/hf/mrg/mysql-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/d2/hf/mrg/mysql-4.1-opt
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/28261-bug-5.0-opt-mysql
-
- 17 May, 2007 4 commits
-
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug28337
-
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).
-
gkodinov/kgeorge@macbook.gmz 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).
-
igor@olga.mysql.com authored
subqueries in WHERE conditions. This bug was introduced by the patch for bug 27321.
-
- 16 May, 2007 9 commits
-
-
joerg@trift2. authored
into trift2.:/MySQL/M50/push-5.0
-
joerg@trift2. authored
into trift2.:/MySQL/M50/push-5.0
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/8663/my50-8663
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/8663/my50-8663
-
df@pippilotta.erinye.com authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build
-
df@pippilotta.erinye.com authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build
-
df@pippilotta.erinye.com authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build
-
df@pippilotta.erinye.com authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build
-
df@pippilotta.erinye.com authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build
-