The problem is that when a stored procedure is being parsed for
the first execution, the body is copied to a temporary buffer
which is disregarded sometime after the statement is parsed.
And during this parsing phase, the rule for CREATE VIEW was
holding a reference to the string being parsed for use during
the execution of the CREATE VIEW statement, leading to invalid
memory access later.

The solution is to allocate and copy the SELECT of a CREATE
VIEW statement using the thread memory root, which is set to
the permanent arena of the stored procedure. 

two timestamp fields.
  
The actual problem here was that CREATE TABLE allowed zero
date as a default value for a TIMESTAMP column in NO_ZERO_DATE mode.
  
The thing is that for TIMESTAMP date type specific rule is applied:
  column_name TIMESTAMP == column_name TIMESTAMP DEFAULT 0
whever for any other date data type
  column_name TYPE == column_name TYPE DEFAULT NULL
  
The fix is to raise an error when we're in NO_ZERO_DATE mode and
there is TIMESTAMP column w/o default value.

behave randomly with mysql_change_user.

The test case had to be moved into not_embedded_server.test file,
because SHOW GLOBAL STATUS does not work properly in embedded
server (see bug 34517).

but not collation.

The problem here was that text literals in a view were always
dumped with character set introducer. That lead to loosing
collation information.

The fix is to dump character set introducer only if it was
in the original query. That is now possible because there 
is no problem any more of loss of character set of string
literals in views -- after WL#4052 the view is dumped 
in the original character set.

behave randomly with mysql_change_user.
  
The problem was that global status variables were not updated
in THD::check_user(), so thread statistics were lost after
COM_CHANGE_USER.
  
The fix is to update global status variables with the thread ones
before preparing the thread for new user.

(originally from Mats)

(originally from Mats)

into  dipika.(none):/opt/local/work/mysql-5.1-runtime

Disable the test case.

into  dipika.(none):/opt/local/work/mysql-5.1-runtime

into  dipika.(none):/opt/local/work/mysql-5.1-runtime

into  dipika.(none):/opt/local/work/mysql-5.0-runtime

simply killed.

into  dipika.(none):/opt/local/work/mysql-5.1-runtime

into  mysql.com:/Users/davi/mysql/mysql-5.1-runtime

into  mysql.com:/Users/davi/mysql/mysql-5.1-runtime

The unsignedness of large integer user variables was not being
properly preserved when feeded to prepared statements. This was
happening because the unsigned flags wasn't being updated when
converting the user variable is converted to a parameter.

The solution is to copy the unsigned flag when converting the
user variable to a parameter and take the unsigned flag into
account when converting the integer to a string.

into  dipika.(none):/opt/local/work/mysql-5.1-runtime

table.

On crashes generate a user-friendly resolved and demangled stack
trace when libc provides the necessary functions (newer libc on i386,
x86_64, powerpc, ia64, alpha and s390). Otherwise print a numeric
stack trace as before, relying on resolve_stack_dump utility.

into  dipika.(none):/opt/local/work/mysql-5.1-runtime

into  mysql.com:/Users/davi/mysql/mysql-5.1-runtime

into  pilot.mysql.com:/data/msvensson/mysql/mysql-5.1-runtime

into  pilot.mysql.com:/data/msvensson/mysql/mysql-5.1-runtime

into  pilot.mysql.com:/data/msvensson/mysql/mysql-5.1-runtime

into  pilot.mysql.com:/data/msvensson/mysql/mysql-5.0-runtime

The problem is that one can not create a stored routine if sql_mode
contains NO_ENGINE_SUBSTITUTION or PAD_CHAR_TO_FULL_LENGTH. Also when
a event is created, the mode is silently lost if sql_mode contains one
of the aforementioned.  This was happening because the table definitions
which stored sql_mode values weren't being updated to accept new values
of sql_mode.

The solution is to update, in a backwards compatible manner, the various
table definitions (columns) that store the sql_mode value to take into
account the new possible values. One incompatible change is that if a event
that is being created can't be stored to the mysql.event table, an error
will be raised.

The tests case also ensure that new SQL modes will be added to the mysql.proc
and mysql.event tables, otherwise the tests will fail.

into  mysql.com:/Users/davi/mysql/mysql-5.1-runtime

into  mysql.com:/Users/davi/mysql/mysql-5.1-runtime