the option is useless on windows. It was removed from listing of
mysqlmanager --help on Windows

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-real-bug21726-fix

into  booka.:/home/alik/MySQL/devel/5.0-rt

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-real-bug21726-fix

wrong results in order by in some rare cases.

invocations of LAST_INSERT_ID.

Reding of LAST_INSERT_ID inside stored function wasn't noted by caller,
and no LAST_INSERT_ID_EVENT was issued for binary log.

The solution is to add THD::last_insert_id_used_bin_log, which is much
like THD::last_insert_id_used, but is reset only for upper-level
statements.  This new variable is used to issue LAST_INSERT_ID_EVENT.

into  ua141d10.elisa.omakaista.fi:/home/my/bk/mysql-5.0

into  mockturtle.local:/home/dlenev/src/mysql-5.0-rt-merge

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21081

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-real-bug21726

Non-upper-level INSERTs (the ones in the body of stored procedure,
stored function, or trigger) into a table that have AUTO_INCREMENT
column didn't affected the result of LAST_INSERT_ID() on this level.

The problem was introduced with the fix of bug 6880, which in turn was
introduced with the fix of bug 3117, where current insert_id value was
remembered on the first call to LAST_INSERT_ID() (bug 3117) and was
returned from that function until it was reset before the next
_upper-level_ statement (bug 6880).

The fix for bug#21726 brings back the behaviour of version 4.0, and
implements the following: remember insert_id value at the beginning
of the statement or expression (which at that point equals to
the first insert_id value generated by the previous statement), and
return that remembered value from LAST_INSERT_ID() or @@LAST_INSERT_ID.

Thus, the value returned by LAST_INSERT_ID() is not affected by values
generated by current statement, nor by LAST_INSERT_ID(expr) calls in
this statement.

Version 5.1 does not have this bug (it was fixed by WL 3146).

into  mysql.com:/home/svoj/devel/mysql/merge/mysql-5.0-engines

into  mysql.com:/home/svoj/devel/mysql/merge/mysql-5.0-engines

into  mysql.com:/home/svoj/devel/mysql/merge/mysql-4.1-engines

into  mysql.com:/home/svoj/devel/mysql/merge/mysql-4.1-engines

into  mockturtle.local:/home/dlenev/src/mysql-5.0-bg20670-2

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21081

into  chilla.local:/home/mydev/mysql-4.0-bug20719

into  chilla.local:/home/mydev/mysql-5.0-bug20627

into  mysql.com:/home/svoj/devel/mysql/engines/mysql-5.0-engines

Was introduced with patch for bug#21675.

into  chilla.local:/home/mydev/mysql-5.0-bug20627

into  chilla.local:/home/mydev/mysql-4.1-bug22384

into  mysql.com:/home/svoj/devel/mysql/engines/mysql-5.0-engines

into  chilla.local:/home/mydev/mysql-5.0-bug22384

into  mockturtle.local:/home/dlenev/src/mysql-5.0-rt-merge

into  mockturtle.local:/home/dlenev/src/mysql-5.0-rt-merge

  After merge fix

into  moonbone.local:/work/5505-bug-5.0-opt-mysql

On an INSERT into an updatable but non-insertable view an error message was
issued stating the view being not updatable. This can lead to a confusion of a
user.

A new error message is introduced. Is is showed when a user tries to insert
into a non-insertable view.

into  chilla.local:/home/mydev/mysql-5.0-bug22384

create_tmp_table()".

The fix for bug 21787 "COUNT(*) + ORDER BY + LIMIT returns wrong
result" introduced valgrind warnings which occured during execution
of information_schema.test and sp-prelocking.test in version 5.0.
There were no user visible effects.

The latter fix made create_tmp_table() dependant on
THD::lex::current_select value. Valgrind warnings occured when this
function was executed and THD::lex::current_select member pointed
to uninitialized SELECT_LEX instance.

This fix tries to remove this dependancy by moving some logic
outside of create_tmp_table() function.

into  chilla.local:/home/mydev/mysql-4.1-bug22384

into  mysql.com:/home/svoj/devel/mysql/BUG21617/mysql-5.0-engines

into  mysql.com:/home/svoj/devel/mysql/BUG21617/mysql-4.1-engines

Crash may happen when selecting from a merge table that has underlying
tables with less indexes than in a merge table itself.

If number of keys in merge table is not bigger than requested key number,
return error.

into  mysql.com:/home/svoj/devel/mysql/BUG21675/mysql-5.0-engines