type, which some time ago became part of Open_table_context class.
Apparently standalone enum type was erroneously re-introduced
during one of merges.

which was introduced by fix for bug 47459 "Assertion in
Diagnostics_area::set_eof_status on OPTIMIZE TABLE.

thd->in_multi_stmt_transaction() and thd->active_transaction().

          data is selected or not

Temporary and permanent tables should live in different 
namespaces.  In this case, resolving a permanent table
name gave the temporary table, resulting in a name
collision.

      
The bug happened under the following condition:
  - there was a user variable of type REAL, containing NULL value
  - there was a table with a NOT_NULL column of any type but REAL, having
    default value (or auto increment);
  - a row was inserted into the table with the user variable as value.
    A warning was emitted here.

The problem was that handling of NULL values of REAL type was not properly
implemented: it didn't expect that REAL NULL value can be assigned to other
data type.

Basically, the problem was that set_field_to_null() was used instead of
set_field_to_null_with_conversions().

The fix is to use the right function, or more generally, to allow conversion of
REAL NULL values to other data types.

  
  Problem:
  item->name was NULL for Item_user_var_as_out_param
  which made strcmp(something, item->name) crash in the LOAD XML code.
  
  Fix:
  - item_func.h: Adding set_name() in constuctor for Item_user_var_as_out_param
  - sql_load.cc: Changing the condition in write_execute_load_query_log_event() which
  distiguished between Item_user_var_as_out_param and Item_field
  from
    if (item->name == NULL)
  to
    if (item->type() == Item::FIELD_ITEM)
  - loadxml.result, loadxml.test: adding tests

          table

If a temporary table A exists, and a (permanent) table 
with the same name is attempted created with 
"CREATE TABLE ... AS SELECT", the create would fail with 
an error.
   1050: Table 'A' already exists

The error occured in MySQL 5.1 releases, but is not
present in MySQL 5.5.   This patch adds a regression
test to ensure that the problem does not reoccur.

Problem: after introduction of "WL#2649 Number-to-string conversions"

This query:
  SET NAMES cp850; -- Or any other non-latin1 ASCII-based character set
  SELECT * FROM t1
  WHERE datetime_column='2010-01-01 00:00:00'
started to add extra character set conversion: 
  SELECT * FROM t1
  WHERE CONVERT(datetime_column USING cp850)='2010-01-01 00:00:00';

so index on DATETIME column was not used anymore.
Fix:
  avoid convertion of NUMERIC/DATETIME items
  (i.e. those with derivation DERIVATION_NUMERIC).

Fixes a bug where bool* was used as an argument to a function where the parameter
was of type bool.

There were two problems here:
  1. misleading error message
  2. abusing KILL QUERY in the test case

1. The server reported "'DELETE FROM t1' failed: 1689: Wait on a lock was
aborted due to a pending exclusive lock", while the proper error message
should be "'DELETE FROM t1' failed: 1317: Query execution was interrupted".

The problem is that the server has two different flags for
signalling that a query is being killed: THD::killed and
mysys_var::abort. The test case triggers a race: sometimes
mysys_var::abort is set earlier than THD::killed. That leads
to the following situation:

  - thr_lock() checks mysys_var::abort and returns error status,
    since mysys_var::abort is set;

  - the caller (mysql_lock_tables()) gets an error from thr_lock(),
    but THD::killed is not set, so it decides that thr_lock() couldn't
    get a lock due to a pending exclusive lock.

This is a known issue with the server and it's not going to be fixed soon.

5.5 differs from 5.1 here as follows: when thr_lock() returns an error:
  - 5.1 continues trying thr_lock() until success;
  - 5.5 propagates the error

2. The test case uses KILL QUERY is a highly concurent environment.

The fix is to wait for the dying statement to rest in peace before
executing another DELETE FROM t1.

thread_temporary_used is not initialized causing
valgrind's warnings.

Update the result file to minor tweaks of the comments in the
test case.

Clarified error messages related to unsafe statements:
 - avoid the internal technical term "row injection"
 - use 'binary log' instead of 'binlog'
 - avoid the word 'unsafeness'

Fix for bug #46947 "Embedded SELECT without FOR UPDATE is
causing a lock", with after-review fixes.

SELECT statements with subqueries referencing InnoDB tables
were acquiring shared locks on rows in these tables when they
were executed in REPEATABLE-READ mode and with statement or
mixed mode binary logging turned on.

This was a regression which were introduced when fixing
bug 39843.

The problem was that for tables belonging to subqueries
parser set TL_READ_DEFAULT as a lock type. In cases when
statement/mixed binary logging at open_tables() time this
type of lock was converted to TL_READ_NO_INSERT lock at
open_tables() time and caused InnoDB engine to acquire
shared locks on reads from these tables. Although in some
cases such behavior was correct (e.g. for subqueries in
DELETE) in case of SELECT it has caused unnecessary locking.

This patch tries to solve this problem by rethinking our
approach to how we handle locking for SELECT and subqueries.
Now we always set TL_READ_DEFAULT lock type for all cases
when we read data. When at open_tables() time this lock
is interpreted as TL_READ_NO_INSERT or TL_READ depending
on whether this statement as a whole or call to function
which uses particular table should be written to the
binary log or not (if yes then statement should be properly
serialized with concurrent statements and stronger lock
should be acquired).

Test coverage is added for both InnoDB and MyISAM.

This patch introduces an "incompatible" change in locking
scheme for subqueries used in SELECT ... FOR UPDATE and
SELECT .. IN SHARE MODE.
In 4.1 the server would use a snapshot InnoDB read for 
subqueries in SELECT FOR UPDATE and SELECT .. IN SHARE MODE
statements, regardless of whether the binary log is on or off.
If the user required a different type of read (i.e. locking read),
he/she could request so explicitly by providing FOR UPDATE/IN SHARE MODE
clause for each individual subquery.
On of the patches for 5.0 broke this behaviour (which was not documented
or tested), and started to use locking reads fora all subqueries in SELECT ... 
FOR UPDATE/IN SHARE MODE. This patch restored 4.1 behaviour.

Stored routine DDL statements use statement-based replication
regardless of the current binlog format. The problem here was
that if a DDL statement failed during metadata lock acquisition
or opening of mysql.proc, the binlog format would not be reset
before returning. So the following DDL or DML statements are 
binlogged with a wrong binlog format, which causes the slave 
to stop.

The problem can be resolved by grabbing an exclusive MDL lock firstly
instead of clearing the current binlog format. So that the binlog
format will not be affected when the lock grab returns directly with
an error. The same way is taken to open a proc table for update.

           parallel mode
      
The failure has nothing to do with parallel, but rather on the
order the tests are executed. In this case, the test
binlog_tmp_table (lets call it test2) was not ensuring that the
binary logs would be reset when it started. Later the test issues
a mysqlbinlog .../master-bin.000002 | mysql ... If the test that
was executed before this one (lets call it test1) had issued a
flush logs, then the file in use in test1 (master-bin.000002)
would not actually match the one that was expected. Eventually,
this would cause the statements logged in test1 to be replayed,
instead of the ones logged in the beginning of test2.
    
We fix this by:
  1. adding RESET MASTER to the beginning of binlog_tmp_table
  2. setting dynamically the file to use in binlog_tmp_table
     
Only #1 was needed, but the two make the tests cases more robust.

      
The problem is that message resource  (message.rc) is compiled as part of static library
sql.lib rather than with executable mysqld.exe. resource files do not work in static
libraries.
      
The fix is to add message.rc to mysqld.exe source files list.

Statements with CONNECTION_ID were forced to be kept in the transactional
cache and by consequence non-transactional changes that were supposed to
be flushed ahead of the transaction were kept in the transactional cache.

This happened because after BUG#51894 any statement whose thd's
thread_specific_used was set was kept in the transactional cache. The idea
was to keep changes on temporary tables in the transactional cache. However,
the thread_specific_used was set not only for statements that accessed
temporary tables but also when the CONNECTION_ID was used.

To fix the problem, we created a new variable to keep track of updates
to temporary tables.

The bug was a side effect of WL#5030 (fix header files) and
WL#5161 (CMake).

The problem was that CMake-generated config.h (and my_config.h
as a copy of it) had a header guard. GNU autotools-generated
[my_]config.h did not. During WL#5030 the order of header files
was changed, so the following started to happen (using GNU autotools,
in embedded server):
  - my_config.h included, defining HAVE_OPENSSL
  - my_global.h included, un-defining  HAVE_OPENSSL
  - zlib.h included, including config.h,
    defining HAVE_OPENSSL again.

The fix is to check HAVE_OPENSSL in conjuction with EMBEDDED_LIBRARY.
More common fix would be to define a macros as HAVE_OPENSSL && !EMBEDDED_LIBRARY
and use it instead of HAVE_OPENSSL.

The bug was a side effect of WL#5030 (fix header files) and
WL#5161 (CMake).

The problem was that CMake-generated config.h (and my_config.h
as a copy of it) had a header guard. GNU autotools-generated
[my_]config.h did not. During WL#5030 the order of header files
was changed, so the following started to happen (using GNU autotools,
in embedded server):
  - my_config.h included, defining HAVE_OPENSSL
  - my_global.h included, un-defining  HAVE_OPENSSL
  - zlib.h included, including config.h,
    defining HAVE_OPENSSL again.

The fix is to change the order of header file, moving zlib.h
to the top of the header list. More proper fix would be to wrap
unguarded auto-generated [my_]config.h by guarded non-generated
header file.

          transaction
BUG#52616 Temp table prevents switch binlog format from STATEMENT to ROW

Post-merge fixes.