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.

in open_table()

Problem: repeating "CREATE... ( AUTOINCREMENT) ... SELECT" may lead to
an assertion failure.

Fix: reset table->auto_increment_field_not_null after each record 
writing.

      
The replication filtering rules were inappropiately applied when
executing BINLOG pseudo-query.  The rules are supposed to be active
only at times when the slave's sql thread executes an event.
            
Fixed with correcting a condition to call replication rules only if
the slave sql thread executes the event.

  INSERT .. SELECT .. ON DUPLICATE KEY UPDATE col=DEFAULT

In order to get correct values from update fields that
belongs to the SELECT part in the INSERT .. SELECT .. ON
DUPLICATE KEY UPDATE statement, the server adds referenced
fields to the select list. Part of the code that does this
transformation is shared between implementations of
the DEFAULT(col) function and the DEFAULT keyword (in
the col=DEFAULT expression), and an implementation of
the DEFAULT keyword is incomplete.

            returns unexpected result

If:
  1. a table has a not nullable BIT column c1 with a length
     shorter than 8 bits and some additional not nullable
     columns c2 etc, and
  2. the WHERE clause is like: (c1 = constant) AND c2 ...,
the SELECT query returns unexpected result set.


The server stores BIT columns in a tricky way to save disk
space: if column's bit length is not divisible by 8, the
server places reminder bits among the null bits at the start
of a record. The rest bytes are stored in the record itself,
and Field::ptr points to these rest bytes.

However if a bit length of the whole column is less than 8,
there are no remaining bytes, and there is nothing to store in
the record at its regular place. In this case Field::ptr points
to bytes actually occupied by the next column in a record.
If both columns (BIT and the next column) are NOT NULL,
the Field::eq function incorrectly deduces that this is the
same column, so query transformation/equal item elimination
code (see build_equal_items_for_cond) may mix these columns
and damage conditions containing references to them.

      
When switching to indexed ORDER BY we must be sure to reset the index read
flag if we are switching from a covering index to non-covering.