When innodb detects a deadlock it calls ha_rollback_trans() to rollback the 
main transaction. But such action isn't allowed from inside of triggers and
functions. When it happen the 'Explicit or implicit commit' error is thrown
even if there is no commit/rollback statements in the trigger/function. This
leads to the user confusion.

Now the convert_error_code_to_mysql() function doesn't call the 
ha_rollback_trans() function directly but rather calls the
mark_transaction_to_rollback function and returns an error.
The sp_rcontext::find_handler() now doesn't allow errors to be caught by the
trigger/function error handlers when the thd->is_fatal_sub_stmt_error flag
is set. Procedures are still allowed to catch such errors.
The sp_rcontext::find_handler function now accepts a THD handle as a parameter.
The transaction_rollback_request and the is_fatal_sub_stmt_error flags are 
added to the THD class. The are initialized by the THD class constructor.
Now the ha_autocommit_or_rollback function rolls back main transaction
when not in a sub statement and the thd->transaction_rollback_request
is set.
The THD::restore_sub_statement_state function now resets the 
thd->is_fatal_sub_stmt_error flag on exit from a sub-statement.

into  dl145s.mysql.com:/users/mhansson/mysql/autopush/mysql-5.0o-pushee

into  magare.gmz:/home/kgeorge/mysql/autopush/B28476-5.0-opt

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

into  dl145s.mysql.com:/users/mhansson/mysql/push/bug23856/mysql-5.0o-pushee

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.

into  mysql.com:/home/hf/work/27984/my50-27984

into  mysql.com:/home/hf/work/27984/my50-27984

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.

into  mysql.com:/home/hf/work/28361/my50-28361

into  mysql.com:/home/hf/work/27894/my50-27894

result max length changed for the 'decimal' fields
so test results have to be fixed

into  magare.gmz:/home/kgeorge/mysql/work/B22855-5.0-opt

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.

into  mysql.com:/d2/hf/mrg/mysql-5.0-opt

into  sergbook.mysql.com:/usr/home/serg/Abk/mysql-5.0

into  mysql.com:/d2/hf/mrg/mysql-5.0-opt

into  mysql.com:/d2/hf/mrg/mysql-5.0-opt

into  mysql.com:/d2/hf/mrg/mysql-4.1-opt

into  moonbone.local:/mnt/gentoo64/work/28261-bug-5.0-opt-mysql

into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug28337

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).

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).

subqueries in WHERE conditions.
This bug was introduced by the patch for bug 27321.

into  trift2.:/MySQL/M50/push-5.0

into  trift2.:/MySQL/M50/push-5.0

into  mysql.com:/home/hf/work/8663/my50-8663

into  mysql.com:/home/hf/work/8663/my50-8663

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build-work

into  adventure.(none):/home/thek/Development/cpp/mysql-5.0-runtime

 - Problem was reported as a SP variable using itself as 
   right value inside SUBSTR caused corruption of data. 
 - This bug could not be verified in either 5.0bk or 5.1bk
 - Added test case to prevent future regressions.