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.

 - Use myisam as default storage engine when running mysqld in --bootstrap mode

Bug#33031 app linked to libmysql.lib crash if run as service in vista under 
localsystem
  

There are some problems using DllMain hook functions on Windows that 
automatically do global and per-thread initialization for libmysqld.dll

1)per-thread initialization(DLL_THREAD_ATTACH)
MySQL internally counts number of active threads that and causes a delay in in 
my_end() if not all threads are exited. But,there are threads that can be 
started either by Windows internally (often in TCP/IP scenarios) or by user 
himself - those threads are not necessarily using libmysql.dll functionality, 
but nonetheless the contribute to the count of open threads.

2)process-initialization (DLL_PROCESS_ATTACH)
my_init() calls WSAStartup that itself loads DLLs and can lead to a deadlock in 
Windows loader.

Fix is to remove dll initialization code from libmysql.dll in general case. I
still leave an environment variable LIBMYSQL_DLLINIT, which if set to any value 
will cause the old behavior (DLL init hooks will be called). This env.variable 
exists only to prevent breakage of existing Windows-only applications that 
don't do mysql_thread_init() and work ok today. Use of LIBMYSQL_DLLINIT is 
discouraged and it will be removed in 6.0