The parser rule for expressions in a udf parameter list contains 
two hacks: 
First, the parser input stream is read verbatim, bypassing 
the lexer.
Second, the Item::name field is overwritten. If the argument to a
udf was a field, the field's name as seen by name resolution was
overwritten this way.
If the field name was quoted or escaped, it would appear as e.g. "`field`".
Fixed by not overwriting field names.

mysql-test/r/udf.result:
  Bug#46259: Test result.
mysql-test/t/udf.test:
  Bug#46259: Test case.
sql/sql_yacc.yy:
  Bug#46259: Fix.

This test case uses mysqlbinlog to dump the content of master-bin.000001,
but the content of master-bin.000001 is not that this test needs.

MTR runs a lot of test cases on one server, so when this test starts, the current binlog file
might not be master-bin.000001, or there are other events are written by tests before.
'RESET MASTER' command must be called at the begin, it ensures that binlog of this test
is wrote to master-bin.000001 correctly.  

Three other tests have the same problem, They were fixed together.
mysqlbinlog-cp932
binlog_incident
binlog_tmp_table

Postfix.
extra/rpl_tests/rpl_row_sp006.test had changed to fix this bug.
extra/rpl_tests/rpl_row_sp006.test is also referenced by rpl_ndb_sp006,
So rpl_row_sp006.result must be changed too.

 
The external 'for' loop in remove_dup_with_compare() handled 
HA_ERR_RECORD_DELETED by just starting over without advancing 
to the next record which caused an infinite loop. 
 
This condition could be triggered on certain data by a SELECT 
query containing DISTINCT, GROUP BY and HAVING clauses. 

Fixed remove_dup_with_compare() so that we always advance to 
the next record when receiving HA_ERR_RECORD_DELETED from 
rnd_next(). 

mysql-test/r/distinct.result:
  Added a test case for bug #46159.
mysql-test/t/distinct.test:
  Added a test case for bug #46159.
sql/sql_select.cc:
  Fixed remove_dup_with_compare() so that we always advance to 
  the next record when receiving HA_ERR_RECORD_DELETED from 
  rnd_next().

           The plugin feature is disabled, you need HAVE_DLOPEN

Selectively skip tests that require dynamic loading (ie: static builds).

mysql-test/include/have_dynamic_loading.inc:
  Add require file.
mysql-test/t/ps_not_windows.test:
  Test requires dynamic loading support.

on subquery inside a SP 

Problem: repeated call of a SP containing an incorrect query with a 
subselect may lead to failed ASSERT().

Fix: set proper sublelect's state in case of error occured during 
subquery transformation.


mysql-test/r/sp.result:
  Fix for bug#46629: Item_in_subselect::val_int(): Assertion `0' 
  on subquery inside a SP 
    - test result.
mysql-test/t/sp.test:
  Fix for bug#46629: Item_in_subselect::val_int(): Assertion `0' 
  on subquery inside a SP 
    - test case.
sql/item_subselect.cc:
  Fix for bug#46629: Item_in_subselect::val_int(): Assertion `0' 
  on subquery inside a SP 
    - don't set Item_subselect::changed in the Item_subselect::fix_fields()
  if an error occured during subquery transformation.
  That prevents us of further processing incorrect subqueries after 
  Item_in_subselect::select_in_like_transformer().

Memory allocated in TMP_TABLE_PARAM::copy_field is not cleaned up.
The fix is to clean up TMP_TABLE_PARAM::copy_field array in JOIN::destroy.


mysql-test/r/explain.result:
  test result
mysql-test/t/explain.test:
  test case
sql/sql_select.cc:
  Memory allocated in TMP_TABLE_PARAM::copy_field is not cleaned up.
  The fix is to clean up TMP_TABLE_PARAM::copy_field array in JOIN::destroy.

                    name as existing view

When trying to create a table with the same name as existing view with
join, mysql server crashes.

The problem is when create table is issued with the same name as view, while
verifying with the existing tables, we assume that base table object is 
created always.

In this case, since it is a view over multiple tables, we don't have the 
mysql derived table object.

Fixed the logic which checks if there is an existing table to not to assume
that table object is created when the base table is view over multiple 
tables.

mysql-test/r/create.result:
  BUG#46384 - mysqld segfault when trying to create table with same 
              name as existing view
  
  Testcase for the bug
mysql-test/t/create.test:
  BUG#46384 - mysqld segfault when trying to create table with same 
              name as existing view
  
  Testcase for the bug
sql/sql_insert.cc:
  BUG#46384 - mysqld segfault when trying to create table with same 
                  name as existing view
      
  Fixed create_table_from_items() method to properly check, if the base table 
  is a view over multiple tables.

                                for CREATE TABLE...LIKE...

Add my_sync.c to mysqltest sources list in CMakeLists.txt

client/CMakeLists.txt:
  BUG#46591 - .frm file isn't sync'd with sync_frm enabled
              for CREATE TABLE...LIKE...
  
  Add my_sync.c to mysqltest sources list

Inserting a negative value in the autoincrement column of a
partitioned innodb table was causing the value of the auto
increment counter to wrap around into a very large positive
value. The consequences are the same as if a very large positive
value was inserted into a column, e.g. reduced autoincrement
range, failure to read autoincrement counter.

The current patch ensures that before calculating the next
auto increment value, the current value is within the positive
maximum allowed limit.

mysql-test/suite/parts/inc/partition_auto_increment.inc:
  Bug#45823 Assertion failure in file row/row0mysql.c line 1386
  
  Adds tests for performing insert,update and delete on a partition
  table with negative auto_increment values.
mysql-test/suite/parts/r/partition_auto_increment_innodb.result:
  Bug#45823 Assertion failure in file row/row0mysql.c line 1386
  
  Result file for the innodb engine.
mysql-test/suite/parts/r/partition_auto_increment_memory.result:
  Bug#45823 Assertion failure in file row/row0mysql.c line 1386
  
  Result file for the memory engine.
mysql-test/suite/parts/r/partition_auto_increment_myisam.result:
  Bug#45823 Assertion failure in file row/row0mysql.c line 1386
  
  Result file for the myisam engine.
mysql-test/suite/parts/r/partition_auto_increment_ndb.result:
  Bug#45823 Assertion failure in file row/row0mysql.c line 1386
  
  Result file for the ndb engine.
mysql-test/suite/parts/t/partition_auto_increment_archive.test:
  Bug#45823 Assertion failure in file row/row0mysql.c line 1386
  
  Adds a variable that allows the Archive engine to skip tests
  that involve insertion of negative auto increment values.
mysql-test/suite/parts/t/partition_auto_increment_blackhole.test:
  Bug#45823 Assertion failure in file row/row0mysql.c line 1386
  
  Adds a variable that allows the Blackhole engine to skip tests
  that involve insertion of negative auto increment values.
sql/ha_partition.cc:
  Bug#45823 Assertion failure in file row/row0mysql.c line 1386
  
  Ensures that the current value is lesser than the upper limit
  for the type of the field before setting the next auto increment
  value to be calculated.
sql/ha_partition.h:
  Bug#45823 Assertion failure in file row/row0mysql.c line 1386
  
  Modifies the set_auto_increment_if_higher function, to take
  into account negative auto increment values when doing a
  comparison.

      
Essentially, Bug#45574 results in this bug. The 'CREATE DATABASE IF NOT EXISTS' statement was not 
binlogged, when the database has existed.
Sometimes, the master and slaves become inconsistent. The "CREATE DATABASE
IF NOT EXISTS mysqltest1" statement is not binlogged
if the db 'mysqltest1' existed before the test case is executed. 
So the db 'mysqltest1' can't be created on slave.
     
Patch of Bug#45574 has resolved this problem. 
But I think it is better to replace 'mysqltest1' by default db 'test'.

myisamchk tool generates warnings when run on an myisam files (.MYI or .MYD)
This is because of the conversion of max_value for certain options in myisamchk 
from singed long to unsigned long

The max value for the options key_buffer_size, read_buffer_size, write_buffer
_size and sort_buffer_size is given as (long) ~0L which becomes -1  when casted
from signed long to longlong and then casted to ulonglong. When (ulonglong) -1 
is compared with maximal value for GET_ULONG data type, we adjust it to 
(ulonglong) ULONG_MAX and throw the warning.

Fixed by using the right max size.

Max values for the variables (from mysqld.cc)
----------------------------
1. key_buffer_size
   5.0: ULONG_MAX
   5.1: SIZE_T_MAX
   6.0: SIZE_T_MAX

2. read_buffer_size and write_buffer_size
   5.0: INT_MAX32
   5.1: INT_MAX32
   6.0: INT_MAX32

3. sort_buffer_size (aka myisam_sort_buffer_size)
   5.0: UINT_MAX32
   5.1: ULONG_MAX
   6.0: ULONG_MAX

Note: testcase not attached

myisam/myisamchk.c:
  Bug#33785 - myisamchk show warning message
      
  Fixed the Max value for key_buffer_size, read_buffer_size, write_buffer_size and
  sort_buffer_size options

                    CREATE TABLE...LIKE...
      
The mysql server option 'sync_frm' is ignored when table is created with 
syntax CREATE TABLE .. LIKE.. 
      
Fixed by adding the MY_SYNC flag and calling my_sync() from my_copy() when
the flag is set.

In mysql_create_table(), when the 'sync_frm' is set, MY_SYNC flag is passed 
to my_copy(). 
      
Note: TestCase is not attached and can be tested manually using debugger.

client/Makefile.am:
  BUG#46591 - .frm file isn't sync'd with sync_frm enabled for 
              CREATE TABLE...LIKE...
      
  add my_sync to sources as it is used in my_copy() method
include/my_sys.h:
  BUG#46591 - .frm file isn't sync'd with sync_frm enabled for 
              CREATE TABLE...LIKE...
      
  MY_SYNC flag is added to call my_sync() method
mysys/my_copy.c:
  BUG#46591 - .frm file isn't sync'd with sync_frm enabled for 
              CREATE TABLE...LIKE...
      
  my_sync() is method is called when MY_SYNC is set in my_copy()
sql/sql_table.cc:
  BUG#46591 - .frm file isn't sync'd with sync_frm enabled for 
              CREATE TABLE...LIKE...
      
  Fixed mysql_create_like_table() to call my_sync() when opt_sync_frm variable
  is set

with the newer pb2 testing environments

This fixes the regression introduced in 5.1 that prevents 64 bit builds on Intel while still keeping the core2 hack operational so the cluster can build.