mysql-test/r/lock_multi_bug38499.result:
  Update test case result.
mysql-test/r/lock_multi_bug38691.result:
  Update test case result.
mysql-test/t/lock_multi_bug38499.test:
  Do not sync .frm files.
mysql-test/t/lock_multi_bug38691.test:
  Do not sync .frm files.

client/mysql.cc:
  Remove leading whitespace.
  Remove extra text after #else directive.
client/mysqldump.c:
  Function does not take a parameter.
mysys/array.c:
  buffer is a uchar pointer.
sql/item.cc:
  Assert if it should not happen.
storage/myisam/mi_check.c:
  Cast to expected type. This is probably a bug, but it is
  casted in a similar way in another part of the code.
storage/ndb/include/mgmapi/ndb_logevent.h:
  Apply fix from cluster team.
tests/mysql_client_test.c:
  Remove extraneous slash.

sql/opt_range.cc:
  Removed duplicate code (if statement must have been duplicated during earlier merge).
sql/sql_partition.cc:
  After mergeing bug#46362 and bug#20577, the NULL partition was also searched
  when col = const, fixed by checking if = or range.

When a connection is dropped any remaining temporary table is also automatically
dropped and the SQL statement of this operation is written to the binary log in
order to drop such tables on the slave and keep the slave in sync. Specifically,
the current code base creates the following type of statement:
DROP /*!40005 TEMPORARY */ TABLE IF EXISTS `db`.`table`;

Unfortunately, appending the database to the table name in this manner circumvents
the replicate-rewrite-db option (and any options that check the current database).
To solve the issue, we started writing the statement to the binary as follows:
use `db`; DROP /*!40005 TEMPORARY */ TABLE IF EXISTS `table`;

Slave does not correctly handle "expected errors" leading to inconsistencies
between the mater and slave. Specifically, when a statement changes both
transactional and non-transactional tables, the transactional changes are
automatically rolled back on the master but the slave ignores the error and
does not roll them back thus leading to inconsistencies.
      
To fix the problem, we automatically roll back a statement that fails on
the slave but note that the transaction is not rolled back unless a "rollback"
command is in the relay log file.

mysql-test/extra/rpl_tests/rpl_mixing_engines.test:
  Enabled item 13.e which was disabled because of the bug fixed by the
  current and removed item 14 which was introduced by mistake.

The crash happens because select_union object is used as result set
for queries which have derived tables.
select_union use temporary table as data storage and if
fields count exceeds 10(count of values for procedure ANALYSE())
then we get a crash on fill_record() function.


mysql-test/r/analyse.result:
  test result
mysql-test/r/subselect.result:
  result fix
mysql-test/t/analyse.test:
  test case
mysql-test/t/subselect.test:
  test fix
sql/sql_yacc.yy:
  The crash happens because select_union object is used as result set
  for queries which have derived tables.
  select_union use temporary table as data storage and if
  fields count exceeds 10(count of values for procedure ANALYSE())
  then we get a crash on fill_record() function.

Updated main.mysqlbinlog_row_trans's result file as 
TRUNCATE statements are wrapped in BEGIN...COMMIT.

binlog

Mixing transactional (T) and non-transactional (N) tables on behalf of a
transaction may lead to inconsistencies among masters and slaves in STATEMENT
mode. The problem stems from the fact that although modifications done to
non-transactional tables on behalf of a transaction become immediately visible
to other connections they do not immediately get to the binary log and therefore
consistency is broken. Although there may be issues in mixing T and M tables in
STATEMENT mode, there are safe combinations that clients find useful.

In this bug, we fix the following issue. Mixing N and T tables in multi-level
(e.g. a statement that fires a trigger) or multi-table table statements (e.g.
update t1, t2...) were not handled correctly. In such cases, it was not possible
to distinguish when a T table was updated if the sequence of changes was N and T.
In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect
that both a N and T tables were changed. To circumvent this issue, we check if an
engine is registered in the handler's list and changed something which means that
a T table was modified.

Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or
ROW modes completely safe.

mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result:
  Truncate statement is wrapped in BEGIN/COMMIT.
mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result:
  Truncate statement is wrapped in BEGIN/COMMIT.

Problem was that the partition containing NULL values
was pruned away, since '2001-01-01' < '2001-02-00' but
TO_DAYS('2001-02-00') is NULL.

Added the NULL partition for RANGE/LIST partitioning on TO_DAYS()
function to be scanned too.

Also fixed a bug that added ALLOW_INVALID_DATES to sql_mode
(SELECT * FROM t WHERE date_col < '1999-99-99' on a RANGE/LIST
partitioned table would add it).

mysql-test/include/partition_date_range.inc:
  Bug#20577: Partitions: use of to_days() function leads to selection failures
  
  Added include file to decrease test code duplication
mysql-test/r/partition_pruning.result:
  Bug#20577: Partitions: use of to_days() function leads to selection failures
  
  Added test results
mysql-test/r/partition_range.result:
  Bug#20577: Partitions: use of to_days() function leads to selection failures
  
  Updated test result.
  This fix adds the partition containing NULL values to
  the list of partitions to be scanned.
mysql-test/t/partition_pruning.test:
  Bug#20577: Partitions: use of to_days() function leads to selection failures
  
  Added test case
sql/item.h:
  Bug#20577: Partitions: use of to_days() function leads to selection failures
  
  Added MONOTONIC_*INCREASE_NOT_NULL values to be used by TO_DAYS.
sql/item_timefunc.cc:
  Bug#20577: Partitions: use of to_days() function leads to selection failures
  
  Calculate the number of days as return value even for invalid dates.
  This is so that pruning can be used even for invalid dates.
sql/opt_range.cc:
  Bug#20577: Partitions: use of to_days() function leads to selection failures
  
  Fixed a bug that added ALLOW_INVALID_DATES to sql_mode
  (SELECT * FROM t WHERE date_col < '1999-99-99' on a RANGE/LIST
  partitioned table would add it).
sql/partition_info.h:
  Bug#20577: Partitions: use of to_days() function leads to selection failures
  
  Resetting ret_null_part when a single partition is to be used, this
  to avoid adding the NULL partition.
sql/sql_partition.cc:
  Bug#20577: Partitions: use of to_days() function leads to selection failures
  
  Always include the NULL partition if RANGE or LIST.
  Use the returned value for the function for pruning, even if
  it is marked as NULL, so that even '2000-00-00' can be
  used for pruning, even if TO_DAYS('2000-00-00') is NULL.
  
  Changed == to >= in get_next_partition_id_list to avoid
  crash if part_iter->part_nums is not correctly setup.

There were a problem since pruning uses the field
for comparison (while evaluate_join_record uses longlong),
resulting in pruning failures when comparing DATE to DATETIME.

Fix was to always comparing DATE vs DATETIME as DATETIME,
by adding ' 00:00:00' to the DATE string.

And adding optimization for comparing with 23:59:59, so that
DATETIME_col > '2001-02-03 23:59:59' ->
TO_DAYS(DATETIME_col) > TO_DAYS('2001-02-03 23:59:59') instead
of '>='.

mysql-test/r/partition_pruning.result:
  Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
  
  Updated result-file
mysql-test/t/partition_pruning.test:
  Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
  
  Added testcases.
sql-common/my_time.c:
  Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
  
  removed duplicate assignment.
sql/item.cc:
  Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
  
  Changed field_is_equal_to_item into field_cmp_to_item, to
  better handling DATE vs DATETIME comparision.
sql/item.h:
  Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
  
  Updated comment
sql/item_timefunc.cc:
  Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
  
  Added optimization (pruning) of DATETIME where time-part is
  23:59:59
sql/opt_range.cc:
  Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
  
  Using the new stored_field_cmp_to_item for better pruning.

The problem was that creating a DECIMAL column from a decimal
value could lead to a failed assertion as decimal values can
have a higher precision than those attached to a table. The
assert could be triggered by creating a table from a decimal
with a large (> 30) scale. Also, there was a problem in
calculating the number of digits in the integral and fractional
parts if both exceeded the maximum number of digits permitted
by the new decimal type.

The solution is to ensure that truncation procedure is executed
when deducing a DECIMAL column from a decimal value of higher
precision. If the integer part is equal to or bigger than the
maximum precision for the DECIMAL type (65), the integer part
is truncated to fit and the fractional becomes zero. Otherwise,
the fractional part is truncated to fit into the space left
after the integer part is copied.

This patch borrows code and ideas from Martin Hansson's patch.

mysql-test/r/type_newdecimal.result:
  Add test case result for Bug#45261. Also, update test case to
  reflect that an additive operation increases the precision of
  the resulting type by 1.
mysql-test/t/type_newdecimal.test:
  Add test case for Bug#45261
sql/field.cc:
  Added DBUG_ASSERT to ensure object's invariant is maintained.
  Implement method to create a field to hold a decimal value
  from an item.
sql/field.h:
  Explain member variable. Add method to create a new decimal field.
sql/item.cc:
  The precision should only be capped when storing the value
  on a table. Also, this makes it impossible to calculate the
  integer part if Item::decimals (the scale) is larger than the
  precision.
sql/item.h:
  Simplify calculation of integer part.
sql/item_cmpfunc.cc:
  Do not limit the precision. It will be capped later.
sql/item_func.cc:
  Use new method for allocating a new decimal field.
  Add a specialized method for retrieving the precision
  of a user variable item.
sql/item_func.h:
  Add method to return the precision of a user variable.
sql/item_sum.cc:
  Use new method for allocating a new decimal field.
sql/my_decimal.h:
  The integer part could be improperly calculated for a decimal
  with 31 digits in the fractional part.
sql/sql_select.cc:
  Use new method which truncates the integer or decimal parts
  as needed.

The code was using a special global buffer for the value of IS NULL ranges.
This was not always long enough to be copied by a regular memcpy. As a 
result read buffer overflows may occur.
Fixed by setting the null byte to 1 and setting the rest of the field disk image
to NULL with a bzero (instead of relying on the buffer and memcpy()).

INSERT ... SELECT ...

Problem was that when bulk insert is used on an empty
table/partition, it disables the indexes for better
performance, but in this specific case it also tries
to read from that partition using an index, which is
not possible since it has been disabled.

Solution was to allow index reads on disabled indexes
if there are no records.

Also reverted the patch for bug#38005, since that was a workaround
in the partitioning engine instead of a fix in myisam.

mysql-test/r/partition.result:
  Bug#46639: 1030 (HY000): Got error 124 from storage engine on
  INSERT ... SELECT ...
  
  updated result file
mysql-test/t/partition.test:
  Bug#46639: 1030 (HY000): Got error 124 from storage engine on
  INSERT ... SELECT ...
  
  Added testcase
sql/ha_partition.cc:
  Bug#46639: 1030 (HY000): Got error 124 from storage engine on
  INSERT ... SELECT ...
  
  reverted the patch for bug#38005, since that was a workaround
  around this problem, not needed after fixing it in myisam.
storage/myisam/mi_search.c:
  Bug#46639: 1030 (HY000): Got error 124 from storage engine on
  INSERT ... SELECT ...
  
  Return HA_ERR_END_OF_FILE instead of HA_ERR_WRONG_INDEX
  when there are no rows.

(temporary) TABLE, crash

Problem: if one has an open "HANDLER t1", further "TRUNCATE t1" 
doesn't close the handler and leaves handler table hash in an 
inconsistent state, that may lead to a server crash.

Fix: TRUNCATE should implicitly close all open handlers.

Doc. request: the fact should be described in the manual accordingly.


mysql-test/r/handler_myisam.result:
  Fix for bug #46456 [Ver->Prg]: HANDLER OPEN + TRUNCATE + DROP
  (temporary) TABLE, crash
    - test result.
mysql-test/t/handler_myisam.test:
  Fix for bug #46456 [Ver->Prg]: HANDLER OPEN + TRUNCATE + DROP
  (temporary) TABLE, crash
    - test case.
sql/sql_delete.cc:
  Fix for bug #46456 [Ver->Prg]: HANDLER OPEN + TRUNCATE + DROP
   (temporary) TABLE, crash
    - remove all truncated tables from the HANDLER's hash.

mysql-test/r/auto_increment.result:
  Bug#46616: Test result.
mysql-test/t/auto_increment.test:
  Bug#46616: Test case.
sql/sql_update.cc:
  Bug#46616: Fix.

view manipulations
      
The bespoke flag was not properly reset after last call to 
fill_record. Fixed by resetting in caller mysql_update.

mysql-test/r/auto_increment.result:
  Bug#46616: Test result.
mysql-test/t/auto_increment.test:
  Bug#46616: Test case.
sql/sql_update.cc:
  Bug#46616: Fix.

If the SQL Thread fails to execute an event due to a temporary error (e.g.
ER_LOCK_DEADLOCK) and the option "--slave_transaction_retries" is set the SQL
Thread should not be aborted and the transaction should be restarted from the
beginning and re-executed.

Unfortunately, a wrong interpretation of the THD::is_fatal_error was preventing
this behavior. In a nutshell, "this variable is set to TRUE if an execution of a
compound statement cannot continue. In particular, it is used to disable access
to the CONTINUE or EXIT handlers of stored routines. So even temporary errors
may have this variable set.

To fix the bug, we have done what follows:

   DBUG_ENTER("has_temporary_error");

-  if (thd->is_fatal_error)
-    DBUG_RETURN(0);
-
   DBUG_EXECUTE_IF("all_errors_are_temporary_errors",
                   if (thd->main_da.is_error())
                   {

The check for stack overflow was independent of the size of the 
structure stored in the heap. 
Fixed by adding sizeof(PARAM) to the requested free heap size.

view that has Group By
      
Table access rights checking function check_grant() assumed
that no view is opened when it's called.
This is not true with nested views where the inner view
needs materialization. In this case the view is already 
materialized when check_grant() is called for it.
This caused check_grant() to not look for table level
grants on the materialized view table.
Fixed by checking if a view is already materialized and if 
it is check table level grants using the original table name
(not the ones of the materialized temp table).