The problem was that new lock types were being added without a
corresponding description. Since the lock types (enum values)
are used as indices to the description array, the descriptions
could be shifted depending on the lock type. The solution is to
ensure that every lock type has a correspondent description.

include/thr_lock.h:
  Add warning.
sql/sql_test.cc:
  Update lock descriptions.

            Engine doesn't allow me to.

In case of incompatible changes between old and new table
versions, the mysqlcheck program prints error messages like
this:
  error: Table upgrade required. Please do
         "REPAIR TABLE `table_name`" to fix it!

However, InnoDB doesn't support REPAIR TABLE query, so the
message is confusing.


Error message text has been changed to:

  Table upgrade required. Please do "REPAIR TABLE `table_name`"
  or dump/reload to fix it!"


mysql-test/r/repair.result:
  Updated test case for bug #42563.
mysql-test/r/varbinary.result:
  Updated test case for bug #42563.
sql/share/errmsg.txt:
  Bug #42563: Message tells me to repair table though Storage
              Engine doesn't allow me to.
  
  The ER_TABLE_NEEDS_UPGRADE error message has been changed to:
  
    Table upgrade required. Please do "REPAIR TABLE ``%-.32s`"
    or dump/reload to fix it!"

fixed message for 'help' command


client/mysql.cc:
  fixed message for 'help' command

The current patch

-- Adds the ibmdb2i suite
-- related include(.inc) files
-- tests for Bug#44020 and Bug#44025

mysql_rename_view can not rename view if database is not the same.
The fix is to add new argument 'new_db' to mysql_rename_view() and
allow rename with different databases
(only for ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME).


mysql-test/t/upgrade.test:
  test fix
sql/parse_file.cc:
  mysql_rename_view can not rename view if database is not the same.
  The fix is to add new argument 'new_db' to mysql_rename_view() and
  allow rename with different databases
  (only for ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME).
sql/parse_file.h:
  mysql_rename_view can not rename view if database is not the same.
  The fix is to add new argument 'new_db' to mysql_rename_view() and
  allow rename with different databases
  (only for ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME).
sql/sql_rename.cc:
  mysql_rename_view can not rename view if database is not the same.
  The fix is to add new argument 'new_db' to mysql_rename_view() and
  allow rename with different databases
  (only for ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME).
sql/sql_view.cc:
  mysql_rename_view can not rename view if database is not the same.
  The fix is to add new argument 'new_db' to mysql_rename_view() and
  allow rename with different databases
  (only for ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME).
sql/sql_view.h:
  mysql_rename_view can not rename view if database is not the same.
  The fix is to add new argument 'new_db' to mysql_rename_view() and
  allow rename with different databases
  (only for ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME).

allow 'rename view' for ALTER ...UPGRADE DATA DIRECTORY NAME command.
it's safe because a view has valid internal db&table names in this case.


mysql-test/r/upgrade.result:
  test result
mysql-test/t/upgrade.test:
  test case
sql/sql_rename.cc:
  allow 'rename view' for ALTER ...UPGRADE DATA DIRECTORY NAME command.
  it's safe because a view has valid internal db&table names in this case.

On IBM i 5.4, schemas with names that are longer 
than 8 characters and contain digits or an underscore
cannot contain IBMDB2I tables, even though this should
theoritically be possible if all alpha characters
are uppercase.

THe current patch fixes the IBMDB2I engine to
allow digits and the underscore(_) to be used in
schema names longer than 8 characters on IBM i 5.4.

storage/ibmdb2i/db2i_misc.h:
  The function which detected whether the
  operating system would treat a schema as an "ordinary identifier" (allowing 10 characters in the name instead of 8) did not cover all possible cases.Function was
  renamed and enhanced to detect all
  possible cases of "ordinary identifiers".
storage/ibmdb2i/ha_ibmdb2i.cc:
  use the renamed function to cover all
  possible cases of ordinary identifiers.

In some circumstances, when a table is created with
the IBMDB2I engine, the CREATE TABLE statement will
return successfully but the table will not exist.

The current patch addresses the above issue and causes
CREATE to fail and report and error to the user.

storage/ibmdb2i/ha_ibmdb2i.cc:
  Locally declared return code hid function-
  scoped declaration and went out of scope
  before being returned. Removed inner
  declaration.

The utf8_swedish_ci and ucs2_swedish_ci
collations do not work with indexes on 
IBMDB2I tables.

The current patch adds the mapping for
ucs2_swedish collation and removes the 
ucs2_spanish2 mapping which is not
supported by any version of the operating
system.

storage/ibmdb2i/db2i_collationSupport.cc:
  Removed mapping for ucs2_spanish2 collation
  since it is not supported by any version of the operating system. Added mapping for ucs2_swedish
  collation which had been overlooked but is
  supported by the IBM i 6.1.

	comment can't be read back

A change to the lexer in 5.1 caused slash-asterisk-bang-version
sections to be terminated early if there exists a slash-asterisk-
style comment inside it.  Nesting comments is usually illegal,
but we rely on versioned comment blocks in mysqldump, and the
contents of those sections must be allowed to have comments.

The problem was that when encountering open-comment tokens and
consuming -or- passing through the contents, the "in_comment"
state at the end was clobbered with the not-in-a-comment value,
regardless of whether we were in a comment before this or not.  

So, """/*!VER one /* two */ three */""" would lose its in-comment
state between "two" and "three".  Save the echo and in-comment
state, and restore it at the end of the comment if we consume a 
comment.

Bug#44091: libmysqld gets stuck waiting on mutex on initialization

The problem was that libmysqld wasn't enforcing a certain
initialization and deinitialization order for the mysys
library. Another problem was that the global object used
for management of log event handlers (aka LOGGER) wasn't
being prepared for a possible reutilization.

What leads to the hang/crash reported is that a failure
to load the language file triggers a double call of the
cleanup functions, causing an already destroyed mutex to
be used.

The solution is enforce a order on the initialization and
deinitialization of the mysys library within the libmysqld
library and to ensure that the global LOGGER object reset
it's internal state during cleanup.

mysys/my_init.c:
  Deinitialize only if initialized already.
sql/log.cc:
  Reset state.

Note: empty changeset.

routine does not exist 
      
There is an inconsistency with DROP DATABASE IF EXISTS, DROP TABLE IF
EXISTS and DROP VIEW IF EXISTS: those are binlogged even if the DB or
TABLE does not exist, whereas DROP PROCEDURE IF EXISTS does not. It
would be nice or at least consistent if DROP PROCEDURE/STATEMENT
worked the same too.
      
Fixed DROP PROCEDURE|FUNCTION IF EXISTS by adding a call to
mysql_bin_log.write in mysql_execute_command. Checked also if all 
documented "DROP (...) IF EXISTS" get binlogged.
      
NOTE: This is a 5.0 backport patch as requested by support.

mysql-test/r/rpl_drop_if_exists.result:
  Result file for test case added.
mysql-test/r/rpl_sp.result:
  Updated result file for existing test case that has now extra events in
  binary log (the ones from drop if exists procedure/function).
mysql-test/t/rpl_drop_if_exists.test:
  Added test case for asserting validity of proposed patch.
sql/sql_parse.cc:
  Added call mysql_bin_log.write when lex has drop_if_exists enabled for 
  stored procedures.

The crash happens due to wrong 'digits' variable value(0),
'digits' can not be 0, so the fix is use 1 as min allowed value.


mysql-test/r/insert.result:
  test result
mysql-test/t/insert.test:
  test case
sql/field.cc:
  The crash happens due to wrong 'digits' variable value(0),
  'digits' can not be 0, so the fix is use 1 as min allowed value.

            
Currently the memory map is being created
with a size that is greater than the size 
of the underlying datafile. This can cause
varying behaviour,

e.g. 

In windows the size of the datafile
is increased, while on linux it remains
the same.

This fix removes the increment margin to
the size that is used while creating the
memory map.

storage/myisam/mi_dynrec.c:
  remove MEMMAP_EXTRA_MARGIN that is used as
  the increment margin to the underlying 
  datafile size while creating the mmap.
storage/myisam/mi_packrec.c:
  The size of the underlying datafile is
  increased by MEMMAP_EXTRA_MARGIN when
  using a packed record format. Hence in 
  this case the size of the memory map should 
  be incremented by the same factor.

Binlog the CREATE EVENT unless the created event been successfully dropped

Modified Query_log_event constructor to make sure that error_code
is not set to ER_SERVER_SHUTDOWN or ER_QUERY_INTERRUPTED errors
when NOT_KILLED

sql/events.cc:
  binlog the create event unless it's been successfully dropped
sql/log_event.cc:
  Modified Query_log_event constructor to make sure that error_code
  is not set to ER_SERVER_SHUTDOWN or ER_QUERY_INTERRUPTED errors
  when NOT_KILLED

The result set for multi-row statements is not the same between STMT and
RBR and among different versions. Thus to avoid test failures, we are not
printing out such result sets. Note, however, that this does not have
impact on coverage and accuracy since the execution is able to continue
without further issues when an error is found on the master and such error
is set to be skipped.