specific to 5.0 version of the patch is motivated by the fact that a wrapper over 
MYSQLLOG::write can not help in 5.0 where query's charset is embedded into event instance in the constructor.

manual merge to account 5.0 specific names of TABLE class

  A pattern to generate binlog for DROPped temp table in close_temporary_tables
  was buggy: could not deal with a grave-accent-in-name table.

  The fix exploits `append_identifier()' for quoting and duplicating accents.

Binlog lacks encoding info about DROPped temporary table.

Idea of the fix is to switch temporary to system_charset_info when a temporary table
is DROPped for binlog. Since that is the server, that automatically, but not the client, who generates the query
the binlog should be updated on the server's encoding for the coming DROP.
The `write_binlog_with_system_charset()' is introduced to replace similar problematic places in the code.

or implicitly uses stored function gives "Table not locked" error'

CREATE TABLE ... SELECT ... statement which was explicitly or implicitly
(through view) using stored function gave "Table not locked" error.

The actual bug resides in the current locking scheme of CREATE TABLE SELECT
code, which first opens and locks tables of the SELECT statement itself,
and then, having SELECT tables locked, creates the .FRM, opens the .FRM and
acquires lock on it. This scheme opens a possibility for a deadlock, which
was present and ignored since version 3.23 or earlier. This scheme also
conflicts with the invariant of the prelocking algorithm -- no table can
be open and locked while there are tables locked in prelocked mode.

The patch makes an exception for this invariant when doing CREATE TABLE ...
SELECT, thus extending the possibility of a deadlock to the prelocked mode.
We can't supply a better fix in 5.0.

(Fixes core dump in rpl_failed_optimize.test)
Ensure we end active transcations if we do an admin command (like optimize, repair etc)

the fix from 5.0 with necessary modifications applied.

The problem is that now server works properly only with the 
row-based replication

The fix refines the algorithm of generating DROPs for binlog. 
Temp tables with common pseudo_thread_id are clustered into one query. 
Consequently one replication event per pseudo_thread_id is generated.

accounting non-ai32 in tmpkeyval. This changeset is supposed to be specifically for 4.1.
Another changeset is going to push into 5. 

  Backporting a changeset made for 5.0. Comments from there:

  The fix refines the algorithm of generating DROPs for binlog.
  Temp tables with common pseudo_thread_id are clustered into one query.
  Consequently one replication event per pseudo_thread_id is generated.

fixlet corrects return to DBUG_RETURN to restore the balance.

fixlet corrects return to DBUG_RETURN to restore the balance.

After review changes

Add missing DBUG_RETURN
Fixed stack overflow in NdbBlob (found by ndb_gis.test)
Fixed access to freed memory in ndb_cluster_real_free_share()

Added missing DBUG_xxx_RETURN statements
Fixed some usage of not initialized variables (as found by valgrind)
Ensure that we don't remove locked tables used as name locks from open table cache until unlock_table_names() are called.
This was fixed by having drop_locked_name() returning any table used as a name lock so that we can free it in unlock_table_names()
This will allow Tomas to continue with his work to use namelocks to syncronize things.

Note: valgrind still produces a lot of warnings about using not initialized code and shows memory loss errors when running the ndb tests

Loads of review comments fixed
inactivate => deactivate
table log => ddl log
Commented on Error Inject Module added
Put various #defines into enums
Fixed abort_and_upgrade_lock, removed unnecessary parameter
Fixed mysqlish method intro's
Fixed warning statements
5.1.7 was released still with partition states in clear text

Fixed io_size bug
Fixed bug in open that TRUNCATED before reading :)
file_entry => file_entry_buf
Don't open DDL log until first write call to DDL log
handler_type => handler_name
no => num

  Post-merge patches.

  More adaptions to make it work with existing code base.

The cause of this bug was a design flaw due to which the list of natural
join columns was incorrectly computed and stored for nested joins that
are not natural joins, but are operands (possibly indirect) of nested joins.

The patch corrects the flaw in a such a way, that the result columns of a
table reference are materialized only if it is a leaf table (that is, only
if it is a view, stored table, or natural/using join).

and new binlog format called "mixed" (which is statement-based except if only row-based is correct,
in this cset it means if UDF or UUID is used; more cases could be added in later 5.1 release):
SET GLOBAL|SESSION BINLOG_FORMAT=row|statement|mixed|default;
the global default is statement unless cluster is enabled (then it's row) as in 5.1-alpha.
It's not possible to use SET on this variable if a session is currently in row-based mode and has open temporary tables (because CREATE
TEMPORARY TABLE was not binlogged so temp table is not known on slave),  or if NDB is enabled (because
NDB does not support such change on-the-fly, though it will later), of if in a stored function (see below).
The added tests test the possibility or impossibility to SET, their effects, and the mixed mode,
including in prepared statements and in stored procedures and functions.
Caveats:
a) The mixed mode will not work for stored functions: in mixed mode, a stored function will
always be binlogged as one call and in a statement-based way (e.g. INSERT VALUES(myfunc()) or SELECT myfunc()).
b) for the same reason, changing the thread's binlog format inside a stored function is
refused with an error message.
c) the same problems apply to triggers; implementing b) for triggers will be done later (will ask
Dmitri).
Additionally, as the binlog format is now changeable by each user for his session, I remove the implication
which was done at startup, where row-based automatically set log-bin-trust-routine-creators to 1
(not possible anymore as a user can now switch to stmt-based and do nasty things again), and automatically
set --innodb-locks-unsafe-for-binlog to 1 (was anyway theoretically incorrect as it disabled
phantom protection).
Plus fixes for compiler warnings.

- Added empty constructors and virtual destructors to many classes and structs
- Removed some usage of the offsetof() macro to instead use C++ class pointers

(Needed for "list of pushes" web page and autopush)

  Moving assignments to table_map_id for thread-safe handling of
  table shares.

trigger starts trigger".

In short, the deadlock/crash happened when execution of statement, which used
stored functions or activated triggers, coincided with alteration of the
tables used by these functions or triggers (in highly concurrent environment).

Bug was caused by the incorrect handling of tables from prelocked set in
open_tables() functions in situations when refresh happened. This fix replaces
old smart but not very robust way of handling tables after refresh (which was
closing only old tables), with new one which simply closes all tables opened so
far and restarts open_tables().
Also fixed handling of temporary tables in close_tables_for_reopen().

No test case present since bug manifests itself only in concurrent environment.

  Table maps are now written on aquiring locks to tables and released
  at the end of each logical statement.

Started writing detailed error handler of
ALTER TABLE for partitioning.
Philosophical issue, should one always attempt to make recovery
automatic or should one rely on manual means also.

-flag was set on field intable share instead of table

post review fixes
Bug fix added missing setting of rw_set for table handler when update occurs via a view.   The missing setting of the rw_set resulted in fields not being updated for ndb tables

Fixed that fulltext query + union results in unexpected behaviour.

  Small fix after merge of fix for bug#16510