(Backported from mysql-5.1-new)

  Rearrange out of order options in option struct.

into  snake-hub.snake.net:/src/extern/MySQL/bk/mysql-5.0

  Fix out of order entries in option struct.

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.