The fix for bug 31887 was incomplete : it assumes that all the 
field types returned by the IS_NUM macro are descendants of 
Item_num and tries to zero-fill the values before doing constant
substitution with such fields when they are compared to constant string
values.
The only exception to this is Field_timestamp : it's in the IS_NUM
macro, but is not a descendant of Field_num.
Fixed by excluding timestamp fields (Field_timestamp) when zero-filling
when converting the constant to compare with to a string.
Note that this will not exclude the timestamp columns from const 
propagation.

--ps-protocol problem has been fixed.

           columns data types

The "SELECT @lastId, @lastId := Id FROM t" query returns
different result sets depending on the type of the Id column
(INT or BIGINT).

Note: this fix doesn't cover the case when a select query
references an user variable and stored function that
updates a value of that variable, in this case a result
is indeterminate.


The server uses incorrect assumption about a constantness of
an user variable value as a select list item: 

The server caches a last query number where that variable
was changed and compares this number with a current query
number. If these numbers are different, the server guesses,
that the variable is not updating in the current query, so
a respective select list item is a constant. However, in some
common cases the server updates cached query number too late.


The server has been modified to memorize user variable
assignments during the parse phase to take them into account
on the next (query preparation) phase independently of the
order of user variable references/assignments in a select
item list.

If [NOT] PRESERVE was not given, parser always defaulted to NOT
PRESERVE, making it impossible for the "not given = no change"
rule to work in ALTER EVENT. Leaving out the PRESERVE-clause
defaults to NOT PRESERVE on CREATE now, and to "no change" in
ALTER.

mysqldump creates stand-in tables before dumping the actual view.
Those tables were of the default type; if the view had more columns
than that (a pathological case, arguably), loading the dump would
fail. We now make the temporary stand-ins MyISAM tables to prevent
this.

mysqldump creates stand-in tables before dumping the actual view.
Those tables were of the default type; if the view had more columns
than that (a pathological case, arguably), loading the dump would
fail. We now make the temporary stand-ins MyISAM tables to prevent
this.

Problem: <=> operator may return wrong results 
comparing NULL and a DATE/DATETIME/TIME value.

Fix: properly check NULLs.

statement/stored procedure

View privileges are properly checked after the fix for bug no 
36086, so the method TABLE_LIST::get_db_name() must be used 
instead of field TABLE_LIST::db, as this only works for tables.
Bug appears when accessing views in prepared statements.

SUPER is not required to change binlog format for session

A user without SUPER privileges can change the value of the
session variable BINLOG_FORMAT, causing problems for a DBA.

This changeset requires a user to have SUPER privileges to
change the value of the session variable BINLOG_FORMAT, and
not only the global variable BINLOG_FORMAT.

SET col
                  
When reporting a duplicate key error the server was making incorrect assumptions 
on what the state of the value string to include in the error is.

Fixed by accessing the data in this string in a "safe" way (without relying on it
having a terminating 0).
      
Detected by code analysis and fixed a similar problem in reporting the foreign key
duplicate errors.

Added a rule that uses gcc to generate preprocessor
output (gcc -E) that can be compared to an already
generated output using the diff utility.

icheck has been removed and replaced by gcc -E
because icheck does not support C++.

      
The check_table_access function initializes per-table grant info and performs
access rights check. It wasn't called for SHOW STATUS statement thus left
grants info uninitialized. In some cases this led to server crash. In other
cases it allowed a user to check for presence/absence of arbitrary values in
any tables.
      
Now the check_table_access function is called prior to the statement
processing.

Problem: SELECT ... REGEXP BINARY NULL may lead to server crash/hang.

Fix: properly handle NULL regular expressions.

Incremental fixes: updating a comment and fixing a result file.

The assertion indicates that some data was left in the transaction
cache when the server was shut down, which means that a previous
statement did not commit or rollback correctly.

What happened was that a bug in the rollback of a transactional
table caused the transaction cache to be emptied, but not reset.
The error can be triggered by having a failing UPDATE or INSERT,
on a transactional table, causing an implicit rollback.

Fixed by always flushing the pending event to reset the state
properly.

This patch also fixes bugs 36963 and 35600.
                      
- In many places a view was confused with an anonymous derived
  table, i.e. access checking was skipped. Fixed by introducing a
  predicate to tell the difference between named and anonymous
  derived tables.
                      
- When inserting fields for "SELECT * ", there was no 
  distinction between base tables and views, where one should be
  made. View privileges are checked elsewhere.