Backporting from 6.0.

# Bug#24690 Stored functions: RETURNing UTF8 strings
# do not return UTF8_UNICODE_CI collation
#
# Bug#17903: cast to char results in binary
# Regression. The character set was not being properly initialized
# for CAST() with a type like CHAR(2) BINARY, which resulted in
# incorrect results or even a server crash.
#

Backporting from mysql-6.0-codebase.

mysql-test/r/sp-ucs2.result:
mysql-test/t/sp-ucs2.test:

  Adding tests

sql/mysql_priv.h:
  Adding prototype

sql/sp.cc
  Remember COLLATE clause for non-default collations

sql/sql_parse.cc
  Adding a new helper function

sql/sql_yacc.yy
  - Allow "CHARACTER SET cs COLLATE cl" in
    SP parameters, RETURNS, DECLARE
  - Minor reorganization for "ASCII" and "UNICODE"
    related rules, to make the code more readable,
    also to allow these aliases:
    * "VARCHAR(10) ASCII BINARY"   -> CHARACTER SET latin1 COLLATE latin1_bin
    * "VARCHAR(10) BINARY ASCII"   -> CHARACTER SET latin1 COLLATE latin1_bin
    * "VARCHAR(10) UNICODE BINARY" -> CHARACTER SET ucs2 COLLATE ucs2_bin
    * "VARCHAR(10) BINARY UNICODE" -> CHARACTER SET ucs2 COLLATE ucs2_bin
    Previously these four aliases returned the error
    "This version of MySQL does not yet support return value collation".

Note:

   This patch allows  "VARCHAR(10) CHARACTER SET cs COLLATE cl"
   and the above four aliases.

   "VARCHAR(10) COLLATE cl" is still not allowed
   i.e. when COLLATE is given without CHARACTER SET.
   If we want to support this, we need an architecture decision
   which character set to use by default.

Patch for bug#47146: Patch after review. Taken from the Makefile.am for archive and changed for example. Copyright line has been changed. The target "dtrace_shared_file" has been removed.

correctly in RPMs.

    For application compatibility reasons  MySQL converts "<autoincrement_column> IS NULL"
    predicates to "<autoincrement_column> = LAST_INSERT_ID()" in the first SELECT following an
    INSERT regardless of whether they're top level predicates or not. This causes wrong and
    obscure results when these predicates are combined with others on the same columns. Fixed
    by only doing the transformation on a single top-level predicate if a special SQL mode is
    turned on (sql_auto_is_null).
    Also made sql_auto_is_null off by default.

per-file comments:
  mysql-test/r/func_isnull.result
Bug#41371      Select returns 1 row with condition "col is not null and col is null"
    test result updated

  mysql-test/t/func_isnull.test
Bug#41371      Select returns 1 row with condition "col is not null and col is null"
    test case added

  sql/mysqld.cc
Bug#41371      Select returns 1 row with condition "col is not null and col is null"
    sql_auto_is_null now is OFF by default.

  sql/sql_select.cc
Bug#41371      Select returns 1 row with condition "col is not null and col is null"
    remove_eq_conds() split in two parts - one only checks the upper condition,
    the req_remove_eq_conds() recursively checks all the condition tree.

  mysql-test/extra/rpl_tests/rpl_insert_id.test
Bug#41371      Select returns 1 row with condition "col is not null and col is null"
        test fixed (set the sql_auto_is_null variable)

  mysql-test/r/mysqlbinlog.result
Bug#41371      Select returns 1 row with condition "col is not null and col is null"
        result updated

  mysql-test/r/mysqlbinlog2.result
Bug#41371      Select returns 1 row with condition "col is not null and col is null"
        result updated

  mysql-test/r/odbc.result
Bug#41371      Select returns 1 row with condition "col is not null and col is null"
        result updated

  mysql-test/r/query_cache.result
Bug#41371      Select returns 1 row with condition "col is not null and col is null"
        result updated

  mysql-test/r/user_var-binlog.result
Bug#41371      Select returns 1 row with condition "col is not null and col is null"
        result updated

  mysql-test/suite/binlog/r/binlog_row_ctype_ucs.result
Bug#41371      Select returns 1 row with condition "col is not null and col is null"
        result updated

  mysql-test/suite/binlog/r/binlog_stm_ctype_ucs.result
Bug#41371      Select returns 1 row with condition "col is not null and col is null"
        result updated

  mysql-test/suite/rpl/r/rpl_insert_id.result
Bug#41371      Select returns 1 row with condition "col is not null and col is null"
        result updated

  mysql-test/suite/rpl/r/rpl_row_mysqlbinlog.result
Bug#41371      Select returns 1 row with condition "col is not null and col is null"
        result updated

  mysql-test/suite/rpl/r/rpl_sp.result
Bug#41371      Select returns 1 row with condition "col is not null and col is null"
        result updated

  mysql-test/t/odbc.test
Bug#41371      Select returns 1 row with condition "col is not null and col is null"
        test fixed (set the sql_auto_is_null variable)

The reason for the bug is that mysqtest as well as other client tools
running in test suite (mysqlbinlog, mysqldump) will first try to connect 
whatever database has created shared memory with default base name 
"MySQL" and use this. (Same effect could be seen on Unix if mtr would
not care to calculate "port" and "socket" parameter).
      
The fix ensures that all client tools and  running in mtr use unique  
per-database shared memory base parameters, so there is no possibility
to clash with already installed one. We use socket name for shared memory 
base (it's known to be unique). This shared-memory-base is written to the
MTR config file to the [client] and [mysqld] sections. Fix made also made 
sure all client tools understand and correctly handle --shared-memory-base.
Prior to this patch  it was not the case for  mysqltest, mysqlbinlog and 
mysql_client_test.
      
All new connections done from mtr scripts via connect() will by default 
set shared-memory-base. And finally, there is a possibility to force 
shared memory or pipe connection and overwrite shared memory/pipe base name
from within mtr scripts via optional PIPE or SHM modifier. This functionality
was manually backported from 6.0
(original patch  http://lists.mysql.com/commits/74749)

Bug#31621: Windows server hanging during shutdown using named pipes 
           and idle connection
            
Problem: when idle pipe connection is forcefully closed with KILL
statement or when the server goes down, thread that is closing connection
would hang infinitely in CloseHandle(). The reason for the hang is that 
named pipe operations are performed synchronously. In this mode all IOs
on pipe are serialized, that is CloseHandle() will not abort ReadFile() 
in another thread, but wait for ReadFile() to complete.
            
The fix implements asynchrnous mode for named pipes, where operation of file
are not synchronized. Read/Write operation would fire an async IO and wait for
either IO completion or timeout.
            
Note, that with this patch timeouts are properly handled for named pipes.
      
Post-review: Win32 timeout code has been fixed for named pipes and shared
memory. We do not store pointer to NET in vio structure, only the read and 
write timeouts.

Backport for 5.5

The root cause of this bug is that the grammar for GROUP BY clauses,
when using WITH CUBE or WITH ROLLUP, cause conflicts with the grammar
for VIEW, when using WITH CHECK OPTION.

The solution is to implement two token look ahead when parsing a WITH token,
to disambiguate the non standard WITH CUBE and WITH ROLLUP syntaxes.

Patch based on code from Marc Alff and Antony Curtis

Backport for 5.5

In non debug builds, the statements:
- SHOW PROCEDURE CODE
- SHOW FUNCTION CODE
used to fail with a "syntax error", which is misleading.

These statements have been changed to return the following error for non
debug builds:
ERROR HY000: The 'SHOW PROCEDURE|FUNCTION CODE' feature is disabled; you
need MySQL built with '--with-debug' to have it working

For debug builds (./configure --with-debug), nothing is changed.

Backport for 5.5

Backport to 5.5

per-file comments:
  mysql-test/r/mysql_upgrade.result
     result updated
  mysql-test/t/mysql_upgrade.test
     --skip-verbose option added to the call

Item_sum::set_aggregator() may be called multiple times during query preparation.
On subsequent calls: verify that the aggregator type is the same,
and re-use the existing Aggregator.

   (backport)
   mysql_upgrade script accepts --upgrade-system-tables option,
   fixing only system tables in this case.

per-file comments:
  client/mysql_upgrade.c
WL#4991 mysql_upgrade --fix-privilege-tables
    --upgrade-system-tables option added.
   if it is set, the tool won't look for the mysqlcheck then
   run_mysqlcheck_fixnames() and run_mysqlcheck_upgrade won't be called.
  mysql-test/r/mysql_upgrade.result
WL#4991 mysql_upgrade --fix-privilege-tables
    test result added
  mysql-test/t/mysql_upgrade.test
WL#4991 mysql_upgrade --fix-privilege-tables
    test case added

Disabled execution of this test for embedded server until fix for
bug 41971 'Thread state on embedded server is always "Writing to net"'
is back-ported to this tree.

Fixing locale name: en_US.UTF-8 -> en_US.utf8

Concurrent execution of statements which require non-table-level
write locks on several instances of the same table (such as
SELECT ... FOR UPDATE which uses same InnoDB table twice or a DML
statement which invokes trigger which tries to update same InnoDB
table directly and through stored function) and statements which
required table-level locks on this table (e.g. LOCK TABLE ... WRITE,
ALTER TABLE, ...) might have resulted in a deadlock.

The problem occured when a thread tried to acquire write lock
(TL_WRITE_ALLOW_WRITE) on the table but had to wait since there was
a pending write lock (TL_WRITE, TL_WRITE_ALLOW_READ) on this table
and we failed to detect that this thread already had another instance
of write lock on it (so in fact we were trying to acquire recursive
lock) because there was also another thread holding write lock on the
table (also TL_WRITE_ALLOW_WRITE). When the latter thread released
its lock neither the first thread nor the thread trying to acquire
TL_WRITE/TL_WRITE_ALLOW_READ were woken up (as table was still write
locked by the first thread) so we ended up with a deadlock.

This patch solves this problem by ensuring that thread which
already has write lock on the table won't wait when it tries
to acquire second write lock on the same table.

The problem here is that the latest innodb push contains
both MYSQL_STORAGE_ENGINE(INNOBASE) and MYSQL_STORAGE_ENGINE(INNOBASE)
in the same CMakeLists.txt, to make the resulting library
ha_innodb.dll, instead of ha_innobase.dll.

Using multiple MYSQL_STORAGE_ENGINE within the same  CMakeLists.txt
conflicts with the fix for the bug Bug #47795 "CMake, storage engine
name different from directory name". Top-level CMakeLists.txt now 
parses storage engine's  CMakeLists.txt to extract engines name from 
MYSQL_STORAGE_ENGINE().

For innodb, it concludes that there is not storage engine named
INNOBASE, hence WITH_INNOBASE_STORAGE_ENGINE has no effect.

The fix is to use SET_TARGET_PROPERTIES(... PROPERTIES OUTPUT_NAME ...),
instead of renaming the engine to have plugins named ha_innodb.dll.