after merging fix for it with main tree.

into  mysql.com:/home/dlenev/src/mysql-5.0-bg13525

Let us transfer triggers associated with table when we rename it (but only if
we are not changing database to which table belongs, in the latter case we will
emit error).

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

Add new parameter to do_eval so that only unescaped variables in input string is expanded and rest of string is left untouched.

into  mysql.com:/usr_rh9/home/elkin.rh9/MySQL/FIXES/5.0-bug17265

To quote Timour review lines:

The actual cause of the bug is that sql_base.cc:setup_wild()
sets "select_lex->with_wild = 0" (in the end of the function) once
it expands all wild-cards, and wild-card expansion is done during
the prepare phase. During this phase we replace all "*" with the
corresponding items, which for views happen to be references to
references. When we do execute, select_lex->with_wild = 0, and
all "*" are already replaced by the corresponding items, which
in the case of views need to be dereferenced first.

Fixed by refining the assert. Regression test for the bug is rpl_row_view01,
as was reported.

The problem was that error flag was not reset.

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into  mysql.com:/opt/local/work/mysql-5.0-runtime

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into  mysql.com:/home/cps/mysql/devel/im/5.0-im-fix-race

duration of the whole 'flush instances'. As a consequence,
it was possible to query instance map, while it is in the
inconsistent state. The patch was reworked after review.

Bug#14857 Reading dump files with single statement stored routines fails.Bug #14857  	Reading dump files with single statement stored routines fails.
 - Add tests, fixed by patch for 16878

into  mysql.com:/home/cps/mysql/devel/im/5.0-im-add-error-message

connections correctly".
Recommit with the max timeout value in sync with the comment.

 - Add comments with embeded veriosn info around the parts of the view syntax that are only supported by a certain version of MySQL Server

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into mysql.com:/home/hf/work/mysql-5.0.w2645

into  mysql.com:/usr/local/mysql/mysql-5.0

fails with --vardir option.

into  rurik.mysql.com:/home/igor/dev/mysql-5.0-0

Fix for BUG#13897 "failure to do SET SQL_MODE=N where N is a number > 31" (the original bug's title isn't the simplest
symptom). sys_var::check_set() was wrong. mysqlbinlog makes use of such SET SQL_MODE=N
(where N is interpreted like if SQL_MODE was a field of type SET), so
this bug affected recovery from binlogs if the server was running with certain SQL_MODE values,
for example the default values on Windows (STRICT_TRANS_TABLES); to work around this bug people
had to edit mysqlbinlog's output.

if the function, invoked in a non-binlogged caller (e.g. SELECT, DO), failed half-way on the master,
slave would stop and complain that error code between him and master mismatch. 
To solve this, when a stored function is invoked in a non-binlogged caller (e.g. SELECT, DO), we binlog the function
call as SELECT instead of as DO (see revision comment of sp_head.cc for more).
And: minor wording change in the help text.
This cset will cause conflicts in 5.1, I'll merge.

Fix for BUG#16559 "Replication Problems with Non transactional tables inside an interrupted trans.":
problem was: when a connection disconnects having an open transaction affecting MyISAM and InnoDB, the ROLLBACK event stored in the binary log
contained a non-zero error code (1053 because of the disconnection), so when slave applied the transaction, slave complained that its ROLLBACK succeeded
(error_code=0) while master's had 1053, so slave stopped. But internally generated binlog events such as this ROLLBACK
should always have 0 as error code, as is true in 4.1 and was accidentally broken in 5.0,
so that there is no false alarm.