Bug 18914 (Calling certain SPs from triggers fail)
Bug 20713 (Functions will not not continue for SQLSTATE VALUE '42S02')
Bug 21825 (Incorrect message error deleting records in a table with a
  trigger for inserting)
Bug 22580 (DROP TABLE in nested stored procedure causes strange dependency
  error)
Bug 25345 (Cursors from Functions)


This fix resolves a long standing issue originally reported with bug 8407,
which affect the behavior of Stored Procedures, Stored Functions and Trigger
in many different ways, causing symptoms reported by all the bugs listed.
In all cases, the root cause of the problem traces back to 8407 and how the
server locks tables involved with sub statements.

Prior to this fix, the implementation of stored routines would:
- compute the transitive closure of all the tables referenced by a top level
statement
- open and lock all the tables involved
- execute the top level statement
"transitive closure of tables" means collecting:
- all the tables,
- all the stored functions,
- all the views,
- all the table triggers
- all the stored procedures
involved, and recursively inspect these objects definition to find more
references to more objects, until the list of every object referenced does
not grow any more.
This mechanism is known as "pre-locking" tables before execution.
The motivation for locking all the tables (possibly) used at once is to
prevent dead locks.

One problem with this approach is that, if the execution path the code
really takes during runtime does not use a given table, and if the table is
missing, the server would not execute the statement.
This in particular has a major impact on triggers, since a missing table
referenced by an update/delete trigger would prevent an insert trigger to run.

Another problem is that stored routines might define SQL exception handlers
to deal with missing tables, but the server implementation would never give
user code a chance to execute this logic, since the routine is never
executed when a missing table cause the pre-locking code to fail.

With this fix, the internal implementation of the pre-locking code has been
relaxed of some constraints, so that failure to open a table does not
necessarily prevent execution of a stored routine.

In particular, the pre-locking mechanism is now behaving as follows:

1) the first step, to compute the transitive closure of all the tables
possibly referenced by a statement, is unchanged.

2) the next step, which is to open all the tables involved, only attempts
to open the tables added by the pre-locking code, but silently fails without
reporting any error or invoking any exception handler is the table is not
present. This is achieved by trapping internal errors with
Prelock_error_handler

3) the locking step only locks tables that were successfully opened.

4) when executing sub statements, the list of tables used by each statements
is evaluated as before. The tables needed by the sub statement are expected
to be already opened and locked. Statement referencing tables that were not
opened in step 2) will fail to find the table in the open list, and only at
this point will execution of the user code fail.

5) when a runtime exception is raised at 4), the instruction continuation
destination (the next instruction to execute in case of SQL continue
handlers) is evaluated.
This is achieved with sp_instr::exec_open_and_lock_tables()

6) if a user exception handler is present in the stored routine, that
handler is invoked as usual, so that ER_NO_SUCH_TABLE exceptions can be
trapped by stored routines. If no handler exists, then the runtime execution
will fail as expected.

With all these changes, a side effect is that view security is impacted, in
two different ways.

First, a view defined as "select stored_function()", where the stored
function references a table that may not exist, is considered valid.
The rationale is that, because the stored function might trap exceptions
during execution and still return a valid result, there is no way to decide
when the view is created if a missing table really cause the view to be invalid.

Secondly, testing for existence of tables is now done later during
execution. View security, which consist of trapping errors and return a
generic ER_VIEW_INVALID (to prevent disclosing information) was only
implemented at very specific phases covering *opening* tables, but not
covering the runtime execution. Because of this existing limitation,
errors that were previously trapped and converted into ER_VIEW_INVALID are
not trapped, causing table names to be reported to the user.
This change is exposing an existing problem, which is independent and will
be resolved separately.


mysql-test/r/information_schema_db.result:
  Revised the pre-locking code implementation, aligned the tests.
mysql-test/r/sp-error.result:
  Revised the pre-locking code implementation, aligned the tests.
mysql-test/r/sp.result:
  Revised the pre-locking code implementation, aligned the tests.
mysql-test/r/trigger.result:
  Revised the pre-locking code implementation, aligned the tests.
mysql-test/r/view.result:
  Revised the pre-locking code implementation, aligned the tests.
mysql-test/t/sp-error.test:
  Revised the pre-locking code implementation, aligned the tests.
mysql-test/t/sp.test:
  Revised the pre-locking code implementation, aligned the tests.
mysql-test/t/trigger.test:
  Revised the pre-locking code implementation, aligned the tests.
sql/lock.cc:
  table->placeholder now checks for schema_table
sql/mysqld.cc:
  my_message_sql(): invoke internal exception handlers
sql/sp_head.cc:
  exec_open_and_lock_tables(): open and lock tables, or return the
  continuation destination of this instruction
sql/sp_head.h:
  exec_open_and_lock_tables(): open and lock tables, or return the
  continuation destination of this instruction
sql/sql_base.cc:
  Prelock_error_handler: delay open table errors until execution
sql/sql_class.cc:
  THD: add internal error handler, as an exception mechanism.
sql/sql_class.h:
  THD: add internal error handler, as an exception mechanism.
sql/sql_update.cc:
  table->placeholder now checks for schema_table
sql/table.cc:
  st_table_list::hide_view_error(): masked more errors for view security
sql/table.h:
  table->placeholder now checks for schema_table, and unopened tables

Fix for bug #24117 "server crash on a FETCH with a cursor on a table which is not in the table cache"

Problem:
When creating a temporary field for a temporary table in create_tmp_field_from_field(), a resulting field is created as an exact copy of an original one (in Field::new_field()). However, Field_enum and Field_set contain a pointer (typelib) to memory allocated in the parent table's MEM_ROOT, which under some circumstances may be deallocated later by the time a temporary table is used.

Solution:
Override the new_field() method for Field_enum and Field_set and create a separate copy of the typelib structure in there.


include/typelib.h:
  Added copy_typelib() declaration
mysql-test/r/sp.result:
  Added a testcase for bug #24117 "server crash on a FETCH with a cursor on a table which is not in the table cache"
mysql-test/t/sp.test:
  Added a testcase for bug #24117 "server crash on a FETCH with a cursor on a table which is not in the table cache"
mysys/typelib.c:
  Added copy_typelib() definition
sql/field.cc:
  Create a copy of the internal 'typelib' structure when copying Field_enum of Field_set objects.
sql/field.h:
  Override new_field method in Field_enum (and Field_set) to copy the typelib structure.

on altered table" and Bug#19733 "Repeated alter, or repeated 
create/drop, fails"


mysql-test/r/ps.result:
  Post-merge fixes: update results with new tests.
mysql-test/r/sp.result:
  Post-merge fixes: update results.
mysql-test/t/ps.test:
  Add more test cases for Bug#4968 and related.
mysql-test/t/sp.test:
  A post-merge fix: add more testcases for Bug#4968 and related.
sql/sql_insert.cc:
  Post-merge fixes: update comments, fix errors of the manual merge.
sql/sql_lex.cc:
  Fix a manual merge error.
sql/sql_parse.cc:
  Fix a few errors of the manual merge, style.
sql/sql_table.cc:
  Post-merge fixes, fix a few errors of the manual merge, fix style.
sql/sql_yacc.yy:
  A post-merge fix.

The problem was that THD::row_count_func was zeroed too. It was zeroed
as a fix for bug 4905 "Stored procedure doesn't clear for "Rows affected"
However, the proper solution is not to zero, because THD::row_count_func has
been set to -1 already in mysql_execute_command(), a later fix, which obsoletes
the incorrect fix of #4095


mysql-test/r/sp.result:
  update result
mysql-test/t/sp.test:
  test for bug#23760 ROW_COUNT() and store procedure not owrking together
sql/sql_parse.cc:
  Remove zeroing for thd->row_count_func
  The fix for #4905 wasn't right. Now, it's ok without this zeroing
  because if there was an error THD::

This patch reverts a change introduced by Bug 6951, which incorrectly
set thd->abort_on_warning for stored procedures.

As per internal discussions about the SQL_MODE=TRADITIONAL,
the correct behavior is to *not* abort on warnings even inside an INSERT/UPDATE
trigger.

Tests for Stored Procedures, Stored Functions, Triggers involving SQL_MODE
have been included or revised, to reflect the intended behavior.

(reposting approved patch, to work around source control issues, no review needed)


mysql-test/include/sp-vars.inc:
  Tests for SQL_MODE='TRADITIONAL'
mysql-test/r/sp-vars.result:
  Tests for SQL_MODE='TRADITIONAL'
mysql-test/r/sp.result:
  Tests for SQL_MODE='TRADITIONAL'
mysql-test/r/trigger.result:
  Tests for SQL_MODE='TRADITIONAL'
mysql-test/t/sp-vars.test:
  Tests for SQL_MODE='TRADITIONAL'
mysql-test/t/sp.test:
  Tests for SQL_MODE='TRADITIONAL'
mysql-test/t/trigger.test:
  Tests for SQL_MODE='TRADITIONAL'
sql/sp_head.cc:
  For SQL_MODE='TRADITIONAL',
  thd->abort_on_warning should be set only when assigning a *column*

The syntax of the CALL statement, to invoke a stored procedure, has been
changed to make the use of parenthesis optional in the argument list.
With this change, "CALL p;" is equivalent to "CALL p();".

While the SQL spec does not explicitely mandate this syntax, supporting it
is needed for practical reasons, for integration with JDBC / ODBC connectors.

Also, warnings in the sql/sql_yacc.yy file, which were not reported by Bison 2.1
but are now reported by Bison 2.2, have been fixed.

The warning found were:
bison -y -p MYSQL  -d --debug --verbose sql_yacc.yy
sql_yacc.yy:653.9-18: warning: symbol UNLOCK_SYM redeclared
sql_yacc.yy:656.9-17: warning: symbol UNTIL_SYM redeclared
sql_yacc.yy:658.9-18: warning: symbol UPDATE_SYM redeclared
sql_yacc.yy:5169.11-5174.11: warning: unused value: $2
sql_yacc.yy:5208.11-5220.11: warning: unused value: $5
sql_yacc.yy:5221.11-5234.11: warning: unused value: $5
conflicts: 249 shift/reduce

"unused value: $2" correspond to the $$=$1 assignment in the 1st {} block
in table_ref -> join_table {} {},
which does not procude a result ($$) for the rule but an intermediate $2
value for the action instead.
"unused value: $5" are similar, with $$ assignments in {} actions blocks
which are not for the final reduce.


mysql-test/r/sp.result:
  New test case for Bug#21462
mysql-test/t/sp.test:
  New test case for Bug#21462
sql/sql_yacc.yy:
  "CALL p;" syntax for calling a stored procedure
  Fixed bison 2.2 warnings.

  
There was possible stack overrun in an edge case which handles invalid body of
a SP in mysql.proc . That should be case when mysql.proc has been changed
manually. Though, due to bug 21513, it can be exploited without having access
to mysql.proc only being able to create a stored routine.


mysql-test/r/sp.result:
  update result
mysql-test/t/sp.test:
  add a test case for the bug
sql/sp.cc:
  Fix stack overrun. This happen mostly when mysql.proc is damaged, though
  it's possible due to another bug which creates invalid SP body in mysql.proc
  (leading quote from a label being cut) to create stack overrun even without
  having direct access to mysql.proc

containing a select statement that uses an aggregating IN subquery.
Added a parameter to the function fix_prepare_information 
to restore correctly the having clause for the second execution.
Saved andor structure of the having conditions at the proper moment
before any calls of split_sum_func2 that could modify the having structure
adding new Item_ref objects. (These additions, are produced not with 
the statement mem_root, but rather with the execution mem_root.)


mysql-test/r/sp.result:
  Added a test case for bug #21493.
mysql-test/t/sp.test:
  Added a test case for bug #21493.
sql/sql_delete.cc:
  Fixed bug #21493: crash for the second execution of a function
  containing a select statement that uses an aggregating IN subquery.
  Added a parameter to the function fix_prepare_information 
  to restore correctly the having clause for the second execution.
sql/sql_insert.cc:
  Fixed bug #21493: crash for the second execution of a function
  containing a select statement that uses an aggregating IN subquery.
  Added a parameter to the function fix_prepare_information 
  to restore correctly the having clause for the second execution.
sql/sql_lex.cc:
  Fixed bug #21493: crash for the second execution of a function
  containing a select statement that uses an aggregating IN subquery.
  Added a parameter to the function fix_prepare_information 
  to restore correctly the having clause for the second execution.
sql/sql_lex.h:
  Fixed bug #21493: crash for the second execution of a function
  containing a select statement that uses an aggregating IN subquery.
  Added a parameter to the function fix_prepare_information 
  to restore correctly the having clause for the second execution.
sql/sql_update.cc:
  Fixed bug #21493: crash for the second execution of a function
  containing a select statement that uses an aggregating IN subquery.
  Added a parameter to the function fix_prepare_information 
  to restore correctly the having clause for the second execution.

The problem was that if after FLUSH TABLES WITH READ LOCK the user
issued DROP/ALTER PROCEDURE/FUNCTION the operation would fail (as
expected), but after UNLOCK TABLE any attempt to execute the same
operation would lead to the error 1305 "PROCEDURE/FUNCTION does not
exist", and an attempt to execute any stored function will also fail.

This happened because under FLUSH TABLES WITH READ LOCK we couldn't open
and lock mysql.proc table for update, and this fact was erroneously
remembered by setting mysql_proc_table_exists to false, so subsequent
statements believed that mysql.proc doesn't exist, and thus that there
are no functions and procedures in the database.

As a solution, we remove mysql_proc_table_exists flag completely.  The
reason is that this optimization didn't work most of the time anyway.
Even if open of mysql.proc failed for some reason when we were trying to
call a function or a procedure, we were setting mysql_proc_table_exists
back to true to force table reopen for the sake of producing the same
error message (the open can fail for number of reasons).  The solution
could have been to remember the reason why open failed, but that's a lot
of code for optimization of a rare case.  Hence we simply remove this
optimization.


mysql-test/r/sp.result:
  Add result for bug#21414: SP: Procedure undroppable, to some extent.
mysql-test/t/sp.test:
  Remove no longer relevant comment.
  Add test case for bug#21414: SP: Procedure undroppable, to some extent.
sql/mysql_priv.h:
  Remove declaration of mysql_proc_table_exists.
sql/sp.cc:
  Remove references to mysql_proc_table_exists.
sql/sql_acl.cc:
  Remove reference to mysql_proc_table_exists.

           if join is used

For procedures with selects that use complicated joins with ON expression
re-execution could erroneously ignore this ON expression, giving
incorrect result.

The problem was that optimized ON expression wasn't saved for
re-execution.  The solution is to properly save it.


mysql-test/r/sp.result:
  Add result for bug#20492: Subsequent calls to stored procedure yield
  incorrect result if join is used.
mysql-test/t/sp.test:
  Add test case for bug#20492: Subsequent calls to stored procedure yield
  incorrect result if join is used.
sql/sql_select.cc:
  Save modified ON expression for re-execution.

The following procedure was not possible if max_sp_recursion_depth is 0
create procedure show_proc() show create procedure show_proc;
  
Actually there is no recursive call but the limit is checked.
  
Solved by temporarily increasing the thread's limit just before the fetch from cache
and decreasing after that.


mysql-test/r/sp.result:
  update result
mysql-test/t/sp.test:
  Test for bug #21416 SP: Recursion level higher than zero needed for non-recursive call
sql/sp.cc:
  Increase the max_sp_recursion_depth temporarily for SHOW CREATE PROCEDURE call.
  This call is in fact not recursive but is counted as such. Outcome, it will work
  always but if max_sp_recursion_depth is reached we are going to cache one more
  sp_head instance.

    
User name (host name) has limit on length. The server code relies on these
limits when storing the names. The problem was that sometimes these limits
were not checked properly, so that could lead to buffer overflow.
  
The fix is to check length of user/host name in parser and if string is too
long, throw an error.


mysql-test/r/grant.result:
  Updated result file.
mysql-test/r/sp.result:
  Updated result file.
mysql-test/r/trigger.result:
  Updated result file.
mysql-test/r/view.result:
  Updated result file.
mysql-test/t/grant.test:
  Added test for BUG#16899.
mysql-test/t/sp.test:
  Added test for BUG#16899.
mysql-test/t/trigger.test:
  Added test for BUG#16899.
mysql-test/t/view.test:
  Added test for BUG#16899.
sql/mysql_priv.h:
  Added prototype for new function.
sql/sql_acl.cc:
  Remove outdated checks.
sql/sql_parse.cc:
  Add a new function for checking string length.
sql/share/errmsg.txt:
  Added new resources.
sql/sql_yacc.yy:
  Check length of user/host name.

  
User name (host name) has limit on length. The server code relies on these
limits when storing the names. The problem was that sometimes these limits
were not checked properly, so that could lead to buffer overflow.

The fix is to check length of user/host name in parser and if string is too
long, throw an error.


mysql-test/r/grant.result:
  Updated result file.
mysql-test/r/sp.result:
  Updated result file.
mysql-test/r/trigger.result:
  Updated result file.
mysql-test/r/view.result:
  Updated result file.
mysql-test/t/grant.test:
  Added test for BUG#16899.
mysql-test/t/sp.test:
  Added test for BUG#16899.
mysql-test/t/trigger.test:
  Added test for BUG#16899.
mysql-test/t/view.test:
  Added test for BUG#16899.
sql/mysql_priv.h:
  Added prototype for new function.
sql/share/errmsg.txt:
  Added new resources.
sql/sql_acl.cc:
  Remove outdated checks.
sql/sql_parse.cc:
  Add a new function for checking string length.
sql/sql_yacc.yy:
  Check length of user/host name.

Implemented code review comments
Test cleanup


sql/protocol.cc:
  Bug#8153 (Stored procedure with subquery and continue handler, wrong result)
  
  Implemented code review comments

Before this fix,
- a runtime error in a statement in a stored procedure with no error handlers
was properly detected (as expected)
- a runtime error in a statement with an error handler inherited from a non
local runtime context (i.e., proc a with a handler, calling proc b) was
properly detected (as expected)
- a runtime error in a statement with a *local* error handler was executed
as follows :
a) the statement would succeed, regardless of the error condition, (bug)
b) the error handler would be called (as expected).

The root cause is that functions like my_messqge_sql would "forget" to set
the thread flag thd->net.report_error to 1, because of the check involving
sp_rcontext::found_handler_here().
Failure to set this flag would cause, later in the call stack,
in Item_func::fix_fields() at line 190, the code to return FALSE and consider
that executing the statement was successful.

With this fix :
- error handling code, that was duplicated in different places in the code,
is now implemented in sp_rcontext::handle_error(),
- handle_error() correctly sets thd->net.report_error when a handler is
present, regardless of the handler location (local, or in the call stack).

A test case, bug8153_subselect, has been written to demonstrate the change
of behavior before and after the fix.

Another test case, bug8153_function_a, as also been writen.
This test has the same behavior before and after the fix.
This test has been written to demonstrate that the previous expected
result of procedure bug18787, was incorrect, since select no_such_function()
should fail and therefore not produce a result.

The incorrect result for bug18787 has the same root cause as Bug#8153,
and the expected result has been adjusted.


sql/mysqld.cc:
  Bug#8153, use sp_rcontext::handle_error() to handle errors.
sql/sql_error.cc:
  Bug#8153, use sp_rcontext::handle_error() to handle errors.
sql/protocol.cc:
  Bug#8153, use sp_rcontext::handle_error() to handle errors.
sql/sp_rcontext.h:
  Bug#8153, created helper sp_rcontext::handle_error() to handle errors.
sql/sp_rcontext.cc:
  Bug#8153, created helper sp_rcontext::handle_error() to handle errors.
mysql-test/t/sp.test:
  Bug#8153, added test cases.
mysql-test/r/sp.result:
  Bug#8153, added test cases, fixed expected result of bug18787.

Fix for BUG#16676: Database CHARSET not used for stored procedures

The problem in BUG#16211 is that CHARSET-clause of the return type for
stored functions is just ignored.

The problem in BUG#16676 is that if character set is not explicitly
specified for sp-variable, the server character set is used instead
of the database one.

The fix has two parts:

  - always store CHARSET-clause of the return type along with the
    type definition in mysql.proc.returns column. "Always" means that
    CHARSET-clause is appended even if it has not been explicitly
    specified in CREATE FUNCTION statement (this affects BUG#16211 only).

    Storing CHARSET-clause if it is not specified is essential to avoid
    changing character set if the database character set is altered in
    the future.

    NOTE: this change is not backward compatible with the previous releases.

  - use database default character set if CHARSET-clause is not explicitly
    specified (this affects both BUG#16211 and BUG#16676).

    NOTE: this also breaks backward compatibility.


mysql-test/r/mysqldump.result:
  Updated result file.
mysql-test/r/sp.result:
  Updated result file.
mysql-test/t/sp.test:
  Provided test cases for BUG#16211, BUG#16676.
sql/mysql_priv.h:
  Added two convenient functions for work with databases.
sql/sp.cc:
  1. Add CHARSET-clause to CREATE-statement if it has been explicitly specified.
  2. Polishing -- provided some comments.
sql/sp_head.cc:
  Use database charset as default charset of sp-variable.
sql/sp_head.h:
  Move init_sp_name() out of init_strings().
sql/sql_db.cc:
  Two new functions created:
    - load_db_opt_by_name();
    - check_db_dir_existence();
sql/sql_show.cc:
  Eliminate duplicated code by using
  check_db_dir_existence() and load_db_opt_by_name()
sql/sql_table.cc:
  Eliminate duplicated code by using
  check_db_dir_existence() and load_db_opt_by_name()
sql/sql_yacc.yy:
  Call sp_head::init_sp_name() to initialize stored routine name.

When there is no index defined filesort is used to sort the result of a
query. If there is a function in the select list and the result set should be
ordered by it's value then this function will be evaluated twice. First time to
get the value of the sort key and second time to send its value to a user.
This happens because filesort when sorts a table remembers only values of its
fields but not values of functions.
All functions are affected. But taking into account that SP and UDF functions
can be both expensive and non-deterministic a temporary table should be used 
to store their results and then sort it to avoid twice SP evaluation and to 
get a correct result.

If an expression referenced in an ORDER clause contains a SP or UDF 
function, force the use of a temporary table.

A new Item_processor function called func_type_checker_processor is added
to check whether the expression contains a function of a particular type.


mysql-test/t/udf.test:
  Added test case for bug#19862: Sort with filesort by function evaluates function twice
mysql-test/t/sp.test:
  Added test case for bug#19862: Sort with filesort by function evaluates function twice
mysql-test/r/sp.result:
  Added test case for bug#19862: Sort with filesort by function evaluates function twice
mysql-test/r/udf.result:
  Added test case for bug#19862: Sort with filesort by function evaluates function twice
sql/sql_select.cc:
  Fixed bug#19862: Sort with filesort by function evaluates function twice
  If an expression referenced in an ORDER clause contains a SP or UDF
  function, force the use of a temporary table.
sql/item_func.h:
  Fixed bug#19862: Sort with filesort by function evaluates function twice
  A new Item_processor function called func_type_checker_processor is added
  to check whether the expression contains a function of a particular type.
sql/item.h:
  Fixed bug#19862: Sort with filesort by function evaluates function twice
  A new Item_processor function called func_type_checker_processor is added
  to check whether the expression contains a function of a particular type.
sql/item_func.cc:
  Fixed bug#19862: Sort with filesort by function evaluates function twice
  A new Item_processor function called func_type_checker_processor is added
  to check whether the expression contains a function of a particular type.

"real" table fails in JOINs".

This is a regression caused by the fix for Bug 18444. 
This fix removed the assignment of empty_c_string to table->db performed 
in add_table_to_list, as neither me nor anyone else knew what it was 
there for. Now we know it and it's covered with tests: the only case 
when a table database name can be empty is when the table is a derived 
table. The fix puts the assignment back but makes it a bit more explicit.

Additionally, finally drop sp.result.orig which was checked in by mistake. 


BitKeeper/deleted/.del-sp.result.orig:
  Delete: mysql-test/r/sp.result.orig
mysql-test/r/derived.result:
  Updated result file.
mysql-test/r/sp.result:
  Test results fixed (Bug#21002)
mysql-test/t/derived.test:
  New error return for the case when MULTI-DELETE tries to delete from
  a derived table: now derived tables belong to their own db (""), and
  MUTLI-DELETE can't find the correspondent table for it in the 
  DELETE list, as it can't resolve tables in different dbs by alias
  (See Bug#21148 for details)
mysql-test/t/sp.test:
  Add a test case for Bug#21002 "Derived table not selecting from a "real"
   table fails in JOINs"
sql/sp.cc:
  Make empty_c_string globally accessible.
sql/sql_class.cc:
  Add empty_c_string definition.
sql/sql_class.h:
  Add a comment for the constructor of Table_ident which is
  used for derived tables. Make sure this constructor also initializes
  the database name, not only the table name.
sql/sql_parse.cc:
  Don't call check_db_name for empty database. 
  Currently the only case when a table database name can be empty
  is when the table is a derived table.
  Report the right error if the database name is wrong (ER_WRONG_DB_NAME,
  not ER_WRONG_TABLE_NAME).

           and Stored Procedure

The essence of the bug was that for every re-execution of stored
routine or prepared statement new items for character set conversions
were created, thus increasing the number of items and the time of their
processing, and creating memory leak.

No test case is provided since current test suite can't cover such type
of bugs.


mysql-test/r/sp.result:
  Add result for bug#21013: Performance Degrades when importing data
  that uses Trigger and Stored Procedure.
mysql-test/t/sp.test:
  Add test case for bug#21013: Performance Degrades when importing data
  that uses Trigger and Stored Procedure.
sql/item.cc:
  Switch arena only when in statement prepare mode.  Subsequent executions
  will use cached item tree.

DESCRIBE returned the type BIGINT for a column of a view if the column
was specified by an expression over values of the type INT.
    
E.g. for the view defined as follows:
  CREATE VIEW v1 SELECT COALESCE(f1,f2) FROM t1
DESCRIBE returned type BIGINT for the only column of the view if f1,f2 are
columns of the INT type.
At the same time DESCRIBE returned type INT for the only column of the table
defined by the statement:
  CREATE TABLE t2 SELECT COALESCE(f1,f2) FROM t1.
    
This inconsistency was removed by the patch.

Now the code chooses between INT/BIGINT depending on the
precision of the aggregated column type.
 
Thus both DESCRIBE commands above returns type INT for v1 and t2.
 


mysql-test/r/analyse.result:
  Adjusted the results after having fixed bug #19714.
mysql-test/r/bigint.result:
  Adjusted the results after having fixed bug #19714.
mysql-test/r/create.result:
  Adjusted the results after having fixed bug #19714.
mysql-test/r/olap.result:
  Adjusted the results after having fixed bug #19714.
mysql-test/r/ps_2myisam.result:
  Adjusted the results after having fixed bug #19714.
mysql-test/r/ps_3innodb.result:
  Adjusted the results after having fixed bug #19714.
mysql-test/r/ps_4heap.result:
  Adjusted the results after having fixed bug #19714.
mysql-test/r/ps_5merge.result:
  Adjusted the results after having fixed bug #19714.
mysql-test/r/ps_6bdb.result:
  Adjusted the results after having fixed bug #19714.
mysql-test/r/ps_7ndb.result:
  Adjusted the results after having fixed bug #19714.
mysql-test/r/sp.result:
  Adjusted the results after having fixed bug #19714.
mysql-test/r/subselect.result:
  Adjusted the results after having fixed bug #19714.
mysql-test/r/type_ranges.result:
  Adjusted the results after having fixed bug #19714.
mysql-test/r/view.result:
  Added a test case for bug #19714.
mysql-test/t/view.test:
  Added a test case for bug #19714.

 Bug#19022 "Memory bug when switching db during trigger execution"
 Bug#17199 "Problem when view calls function from another database."
 Bug#18444 "Fully qualified stored function names don't work correctly in
            SELECT statements"

 Documentation note: this patch introduces a change in behaviour of prepared
 statements.

 This patch adds a few new invariants with regard to how THD::db should
 be used. These invariants should be preserved in future:

  - one should never refer to THD::db by pointer and always make a deep copy
    (strmake, strdup)
  - one should never compare two databases by pointer, but use strncmp or
    my_strncasecmp
  - TABLE_LIST object table->db should be always initialized in the parser or
    by creator of the object.

    For prepared statements it means that if the current database is changed
    after a statement is prepared, the database that was current at prepare
    remains active. This also means that you can not prepare a statement that
    implicitly refers to the current database if the latter is not set.
    This is not documented, and therefore needs documentation. This is NOT a
    change in behavior for almost all SQL statements except:
     - ALTER TABLE t1 RENAME t2 
     - OPTIMIZE TABLE t1
     - ANALYZE TABLE t1
     - TRUNCATE TABLE t1 --
     until this patch t1 or t2 could be evaluated at the first execution of
     prepared statement. 

     CURRENT_DATABASE() still works OK and is evaluated at every execution
     of prepared statement.

     Note, that in stored routines this is not an issue as the default
     database is the database of the stored procedure and "use" statement
     is prohibited in stored routines.

  This patch makes obsolete the use of check_db_used (it was never used in the
  old code too) and all other places that check for table->db and assign it
  from THD::db if it's NULL, except the parser.

 How this patch was created: THD::{db,db_length} were replaced with a
 LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were
 manually checked and:
  - if the place uses thd->db by pointer, it was fixed to make a deep copy
  - if a place compared two db pointers, it was fixed to compare them by value
    (via strcmp/my_strcasecmp, whatever was approproate)
 Then this intermediate patch was used to write a smaller patch that does the
 same thing but without a rename.

 TODO in 5.1:
   - remove check_db_used
   - deploy THD::set_db in mysql_change_db

 See also comments to individual files.


mysql-test/r/create.result:
  Modify the result file: a database can never be NULL.
mysql-test/r/ps.result:
  Update test results (Bug#17199 et al)
mysql-test/r/sp.result:
  Update test results (Bug#17199 et al)
mysql-test/t/create.test:
  Update the id of the returned error.
mysql-test/t/ps.test:
  Add test coverage for prepared statements and current database. In scope of
  work on Bug#17199 "Problem when view calls function from another database."
mysql-test/t/sp.test:
  Add a test case for Bug#17199 "Problem when view calls function from another
  database." and Bug#18444 "Fully qualified stored function names don't work
  correctly in SELECT statements". Test a complementary problem.
sql/item_strfunc.cc:
  Touch the code that reads thd->db (cleanup).
sql/log_event.cc:
  While we are at it, replace direct access to thd->db with a method.
  Should simplify future conversion of THD::db to LEX_STRING.
sql/slave.cc:
  While we are at it, replace direct access to thd->db with a method.
  Should simplify future conversion of THD::db to LEX_STRING.
sql/slave.h:
  Remove a declaration for a method that is used only in one module.
sql/sp.cc:
  Rewrite sp_use_new_db: this is a cleanup that I needed in order to understand
  this function and ensure that it has no bugs.
sql/sp.h:
  Add a new declaration for sp_use_new_db (uses LEX_STRINGs) and a comment.
sql/sp_head.cc:
  - drop sp_name_current_db_new - a creator of sp_name class that was used
  when sp_name was created for an identifier without an explicitly initialized
  database. Now we pass thd->db to constructor of sp_name right in the 
  parser.
  - rewrite sp_head::init_strings: name->m_db is always set now
  - use the new variant of sp_use_new_db
  - we don't need to update thd->db with SP MEM_ROOT pointer anymore when
  parsing a stored procedure, as noone will refer to it (yes!)
sql/sp_head.h:
  - remove unneded methods and members
sql/sql_class.h:
  - introduce 3 THD  methods to work with THD::db:
    .set_db to assign the current database
    .reset_db to reset the current database (temporarily) or set it to NULL
    .opt_copy_db_to - to deep-copy thd->db to a pointer if it's not NULL
sql/sql_db.cc:
  While we are at it, replace direct access to thd->db with a method.
  Should simplify future conversion of THD::db to LEX_STRING.
sql/sql_insert.cc:
  - replace checks with asserts: table_list->db must be always set in the parser.
sql/sql_lex.h:
  - add a comment
sql/sql_parse.cc:
  - implement the invariant described in the changeset comment.
  - remove juggling with lex->sphead in SQLCOM_CREATE_PROCEDURE:
    now db_load_routine uses its own LEX object and doesn't damage the main
    LEX.
  - add DBUG_ASSERT(0) to unused "check_db_used"
sql/sql_table.cc:
  - replace a check with an assert (table_ident->db)
sql/sql_trigger.cc:
  While we are at it, replace direct access to thd->db with a method.
  Should simplify future conversion of THD::db to LEX_STRING.
sql/sql_udf.cc:
  - use thd->set_db instead of direct modification of to thd->db
sql/sql_view.cc:
  - replace a check with an assert (view->db)
sql/sql_yacc.yy:
  - make sure that we always copy table->db or name->db or ident->db or
    select_lex->db from thd->db if the former is not set. If thd->db
    is not set but is accessed, return an error.
sql/tztime.cc:
  - be nice, never copy thd->db by pointer.

 with PREPARE fails with weird error".
More generally, re-executing a stored procedure with a complex SP cursor query
could lead to a crash.

The cause of the problem was that SP cursor queries were not optimized 
properly at first execution: their parse tree belongs to sp_instr_cpush,
not sp_instr_copen, and thus the tree was tagged "EXECUTED" when the
cursor was declared, not when it was opened. This led to loss of optimization
transformations performed at first execution, as sp_instr_copen saw that the
query is already "EXECUTED" and therefore either not ran first-execution 
related blocks or wrongly rolled back the transformations caused by 
first-execution code.
The fix is to update the state of the parsed tree only when the tree is
executed, as opposed to when the instruction containing the tree is executed.
Assignment if i->state is moved to reset_lex_and_exec_core.


mysql-test/r/sp.result:
  Test results fixed (Bug#15217)
mysql-test/t/sp.test:
  Add a test case for Bug#15217
sql/sp_head.cc:
  Move assignment of stmt_arena->state to reset_lex_and_exec_core

variable in stored procedures.

garbles data if longer than 766 chars.

The problem is that a stored routine returns BLOBs to the previous
caller, BLOBs are shallow-copied (i.e. only pointers to the data are
copied). The fix is to also copy data of BLOBs.


mysql-test/r/sp.result:
  Updated result file.
mysql-test/t/sp.test:
  Added a test case for BUG#18587.
sql/field_conv.cc:
  Do not jump to optimization if the field type is BLOB and
  the destination table requires copying of BLOBs.
sql/item_func.cc:
  Request copying BLOBs for the result table.

or implicitly uses stored function gives "Table not locked" error'

CREATE TABLE ... SELECT ... statement which was explicitly or implicitly
(through view) using stored function gave "Table not locked" error.

The actual bug resides in the current locking scheme of CREATE TABLE SELECT
code, which first opens and locks tables of the SELECT statement itself,
and then, having SELECT tables locked, creates the .FRM, opens the .FRM and
acquires lock on it. This scheme opens a possibility for a deadlock, which
was present and ignored since version 3.23 or earlier. This scheme also
conflicts with the invariant of the prelocking algorithm -- no table can
be open and locked while there are tables locked in prelocked mode.

The patch makes an exception for this invariant when doing CREATE TABLE ...
SELECT, thus extending the possibility of a deadlock to the prelocked mode.
We can't supply a better fix in 5.0.


mysql-test/r/sp.result:
  Added tests for bugs#12472/#15137 'CREATE TABLE ... SELECT ... which
  explicitly or implicitly uses stored function gives "Table not locked" error'
mysql-test/t/sp.test:
  Added tests for bugs#12472/#15137 'CREATE TABLE ... SELECT ... which
  explicitly or implicitly uses stored function gives "Table not locked" error'
sql/mysql_priv.h:
  Added flag which can be passed to open_table() routine in order to ignore
  set of locked tables and prelocked mode.
  We don't need declaration of create_table_from_items() any longer as it was
  moved into sql_insert.cc and made static.
sql/sql_base.cc:
  open_table():
    Added flag which allows open table ignoring set of locked tables and
    prelocked mode.
sql/sql_insert.cc:
  Moved create_table_from_items() from sql_table.cc to sql_insert.cc as it was
  not used outside of sql_insert.cc and contains code which is specific for
  CREATE TABLE ... SELECT.
  Also now when we are executing CREATE TABLE ... SELECT ... statement which
  SELECT part requires execution in prelocked mode we ignore set of locked
  tables in order to get access to the table we just have created.
  We probably don't want to do this if we are under real LOCK TABLES since
  it will widen window for deadlock too much.
sql/sql_table.cc:
  Moved create_table_from_items() routine into sql_insert.cc, since it was not
  used anywhere outside of this file and contains logic which is specific for
  CREATE TABLE ... SELECT statement.

Do not reset value of LAST_INSERT_ID() in sub-statement.


mysql-test/r/rpl_insert_id.result:
  Add result for bug#15728.
mysql-test/r/sp.result:
  Add result for bug#15728.
mysql-test/t/rpl_insert_id.test:
  Add test case for bug#15728.
mysql-test/t/sp.test:
  Add test case for bug#15728.
sql/sql_class.cc:
  Do not reset value of LAST_INSERT_ID() in sub-statement.

  We must use the db key length in sp_drop_db_routines (and not the
  number of characters), or long db names will be truncated in the key.


mysql-test/r/sp.result:
  Updated results for new test case (BUG#18344)
mysql-test/t/sp.test:
  Added new test case for BUG#18344.
sql/sp.cc:
  In sp_drop_db_routines(), give the key field's ("db") key length
  instead of the number of characters to index_read(), or the key
  packing will truncate long db names.

                 a misnamed function
  ... in the presence of a continue handler. The problem was that with a
  handler, it continued to execute as if function existed and had set a
  useful return value (which it hadn't).
  The fix is to set a null return value and do an error return when a function
  wasn't found.


mysql-test/r/sp.result:
  Updated results for a new test case (BUG#18787).
mysql-test/t/sp.test:
  New testcase for BUG#18787.
sql/item_func.cc:
  Don't set "out of resources" error in Item_func_sp::execute() if no
  result field is returned, it's simply wrong, it can be sometthing else,
  like a function not found. Instead set null_value and return error.
  Also, set "out of resources" when field creation fails in
  Item_func_sp::sp_result_field() and Item_func_sp::tmp_table_field().

counter".

When TRUNCATE TABLE was called within an stored procedure the
auto_increment counter was not reset to 0 even if straight
TRUNCATE for this table did this.

This fix makes TRUNCATE in stored procedures to be handled exactly
in the same way as straight TRUNCATE. We achieve this by rolling
back the fix for bug 8850, which is no longer needed since stored
procedures don't require prelocked mode anymore (and TRUNCATE is
not allowed in stored functions or triggers).


mysql-test/r/sp.result:
  Test case for BUG#14945.
mysql-test/t/sp.test:
  Test case for BUG#14945.
sql/sql_delete.cc:
  Handle TRUNCATE in stored procedures exactly in the same way as straight
  TRUNCATE (i.e. without falling back to DELETE if possible). We achieve
  this by rolling back the fix for bug 8850, which is no longer relevant
  since stored procedures don't require prelocked mode anymore
  (and TRUNCATE is not allowed in stored functions or triggers).
sql/sql_parse.cc:
  Handle TRUNCATE in stored procedures exactly in the same way as straight
  TRUNCATE (i.e. without falling back to DELETE if possible). We achieve
  this by rolling back the fix for bug 8850, which is no longer relevant
  since stored procedures don't require prelocked mode anymore
  (and TRUNCATE is not allowed in stored functions or triggers).

mysql-test/r/ps.result:
  Added test coverage for "order by" in prepared statements (related to BUG#16474).
mysql-test/r/sp.result:
  Added reference to test case for BUG#16474.
mysql-test/t/ps.test:
  Added test coverage for "order by" in prepared statements (related to BUG#16474).
mysql-test/t/sp.test:
  Added reference to test case for BUG#16474.
sql/sql_select.cc:
  Fixed comment and test for basic_const_item() instead of is_splocal().

  fix_fields() was not called for "order by" variables if the type was a
  "constant integer", and thus interpreted as a column index.
  However, a local variable is an expression and should not be interpreted
  as a column index. Instead it behaves just like when using a user variable
  for instance (i.e. it will not affect the ordering).



mysql-test/r/sp.result:
  Updated results for new test case (BUG#16474).
mysql-test/t/sp.test:
  New test case for BUG#16474.
sql/sql_select.cc:
  When processing order list,

produce wrong data

By default Item_sp_func::val_str() returns string from it's result_field 
internal buffer. When grouping is present Item_copy_string is used to 
store SP function result, but it doesn't additionally buffer the result.
When the next record is read, internal buffer is overwritten, due to
this Item_copy_string::val_str() will have wrong data. Thus producing
weird query result.

The Item_func_sp::val_str() now makes a copy of returned value to prevent
occasional corruption.


mysql-test/t/sp.test:
  Added test case for bug#13575: SP funcs in select with distinct/group and order by can
  produce wrong data
mysql-test/r/sp.result:
  Added test case for bug#13575: SP funcs in select with distinct/group and
      order by can produce wrong data
sql/item_func.h:
  Fixed bug#13575: SP funcs in select with distinct/group and order by can
      produce wrong data
      The Item_func_sp::val_str() now makes a copy of returned value to prevent
      occasinal corruption.

 -Add test case
Move testcase that needs innodb from sp.test => sp_trans.test 


mysql-test/r/sp.result:
  Move test cases tyhat requires innodb to sp_trans.test
mysql-test/r/sp_trans.result:
  Move test cases tyhat requires innodb to sp_trans.test
  Add test case for bug#10656
mysql-test/t/sp.test:
  Move test cases tyhat requires innodb to sp_trans.test
mysql-test/t/sp_trans.test:
  Add test case for bug#10656
  Move test cases that require innodb to sp_trans.test

                 time per connection
  Removed const_string() method from Item_string (it was only used in one
  place, in a bad way). Defer possible SP variable, and access data directly
  instead, in date_format item.


mysql-test/r/sp.result:
  Updated results for new test (BUG#17476).
mysql-test/t/sp.test:
  New test case (BUG#17476)
sql/item.h:
  Removed const_string() from Item_string.
  It was only used in one place, and we can just use str_value in Item directly.
sql/item_timefunc.cc:
  Must defer a (possible) local SP variable to use max_length and str_value
  in Item_func_date_format::fix_length_and_dec(), and refer to str_value
  directly without the const_string() method (now removed); the cast didn't
  work in all cases anyway.

The idea is to add DEFINER-clause in CREATE PROCEDURE and CREATE FUNCTION
statements. Almost all support of definer in stored routines had been already
done before this patch.

NOTE: this patch changes behaviour of dumping stored routines in mysqldump.
Before this patch, mysqldump did not dump DEFINER-clause for stored routines
and this was documented behaviour. In order to get full information about stored
routines, one should have dumped mysql.proc table. This patch changes this
behaviour, so that DEFINER-clause is dumped.

Since DEFINER-clause is not supported in CREATE PROCEDURE | FUNCTION statements
before this patch, the clause is covered by additional version-specific comments.


client/mysqldump.c:
  Updated the code for dumping stored routines: cover DEFINER-clause
  into version-specific comment.
mysql-test/r/gis.result:
  Updated result file after adding DEFINER-clause.
mysql-test/r/information_schema.result:
  Updated result file after adding DEFINER-clause.
mysql-test/r/mysqldump.result:
  Updated result file after adding DEFINER-clause.
mysql-test/r/rpl_ddl.result:
  Updated result file after adding DEFINER-clause.
mysql-test/r/rpl_sp.result:
  Updated result file after adding DEFINER-clause.
mysql-test/r/rpl_trigger.result:
  Updated result file after adding DEFINER-clause.
mysql-test/r/sp-security.result:
  Updated result file after adding DEFINER-clause.
mysql-test/r/sp.result:
  Updated result file after adding DEFINER-clause.
mysql-test/r/sql_mode.result:
  Updated result file after adding DEFINER-clause.
mysql-test/t/sp-security.test:
  Updated result file after adding DEFINER-clause.
sql/sp.cc:
  Added DEFINER-clause.
sql/sp_head.cc:
  Added a new convenient variant of set_definer() operation.
sql/sp_head.h:
  Updated result file after adding DEFINER-clause.
sql/sql_lex.h:
  Renamed trigger_definition_begin into stmt_definition_begin to be used for
  triggers and stored routines.
sql/sql_parse.cc:
  Check DEFINER-clause.
sql/sql_trigger.cc:
  Renamed trigger_definition_begin into stmt_definition_begin to be used for
  triggers and stored routines.
sql/sql_yacc.yy:
  Added DEFINER-clause.

sql/item_func.cc:
  Fix for bug #17615: invalid handling of function results in UPDATE...SET statement.
  - set proper collation

(Needed for "list of pushes" web page and autopush)


include/mysql.h:
  Fix to embedded server to be able to run tests on it
libmysql/libmysql.c:
  Fix to embedded server to be able to run tests on it
libmysqld/emb_qcache.cc:
  Fix to embedded server to be able to run tests on it
libmysqld/embedded_priv.h:
  Fix to embedded server to be able to run tests on it
libmysqld/lib_sql.cc:
  Fix to embedded server to be able to run tests on it
libmysqld/libmysqld.c:
  Fix to embedded server to be able to run tests on it
mysql-test/mysql-test-run.sh:
  Fix to embedded server to be able to run tests on it
mysql-test/r/binlog.result:
  Updated test for embedded server
mysql-test/r/ctype_cp932.result:
  Updated test for embedded server
mysql-test/r/innodb.result:
  Updated test for embedded server
mysql-test/r/mysqltest.result:
  Updated test for embedded server
mysql-test/r/query_cache.result:
  Updated test for embedded server
mysql-test/r/query_cache_notembedded.result:
  Updated test for embedded server
mysql-test/r/sp-error.result:
  Updated test for embedded server
mysql-test/r/sp.result:
  Updated test for embedded server
mysql-test/r/subselect.result:
  Updated test for embedded server
mysql-test/r/view.result:
  Updated test for embedded server
mysql-test/r/view_grant.result:
  Updated test for embedded server
mysql-test/t/backup.test:
  Updated test for embedded server
mysql-test/t/binlog.test:
  Updated test for embedded server
mysql-test/t/blackhole.test:
  Updated test for embedded server
mysql-test/t/compress.test:
  Updated test for embedded server
mysql-test/t/ctype_cp932.test:
  Updated test for embedded server
mysql-test/t/delayed.test:
  Updated test for embedded server
mysql-test/t/handler.test:
  Updated test for embedded server
mysql-test/t/innodb.test:
  Updated test for embedded server
mysql-test/t/mysql.test:
  Updated test for embedded server
mysql-test/t/mysql_client_test.test:
  Updated test for embedded server
mysql-test/t/mysqltest.test:
  Updated test for embedded server
mysql-test/t/query_cache.test:
  Updated test for embedded server
mysql-test/t/query_cache_notembedded.test:
  Updated test for embedded server
mysql-test/t/read_only.test:
  Updated test for embedded server
mysql-test/t/skip_grants.test:
  Updated test for embedded server
mysql-test/t/sp-destruct.test:
  Updated test for embedded server
mysql-test/t/sp-error.test:
  Updated test for embedded server
mysql-test/t/sp-threads.test:
  Updated test for embedded server
mysql-test/t/sp.test:
  Updated test for embedded server
mysql-test/t/subselect.test:
  Updated test for embedded server
mysql-test/t/temp_table.test:
  Updated test for embedded server
mysql-test/t/view.test:
  Updated test for embedded server
mysql-test/t/view_grant.test:
  Updated test for embedded server
mysql-test/t/wait_timeout.test:
  Updated test for embedded server
mysys/mf_dirname.c:
  Review fix: Don't access data outside of array
mysys/my_bitmap.c:
  Remove compiler warnings
scripts/mysql_fix_privilege_tables.sql:
  Add flush privileges to .sql script so that one doesn't have to reboot mysqld when one runs the mysql_fix_privilege_script
sql-common/client.c:
  Updated test for embedded server
sql/item.cc:
  Remove DBUG_PRINT statement that can cause crashes when running with --debug
sql/mysqld.cc:
  Fix to embedded server to be able to run tests on it
sql/protocol.cc:
  Fix to embedded server to be able to run tests on it
  (Trivial reconstruction of code)
sql/protocol.h:
  Fix to embedded server to be able to run tests on it
sql/sql_base.cc:
  Better comment
sql/sql_class.cc:
  Fix to embedded server to be able to run tests on it
sql/sql_class.h:
  Fix to embedded server to be able to run tests on it
sql/sql_cursor.cc:
  Fix to embedded server to be able to run tests on it
sql/sql_parse.cc:
  Fix to embedded server to be able to run tests on it
  Don't crash for disabled commands when using embedded server
sql/sql_prepare.cc:
  Fix to embedded server to be able to run tests on it
mysql-test/r/ctype_cp932_notembedded.result:
  New BitKeeper file ``mysql-test/r/ctype_cp932_notembedded.result''
mysql-test/r/innodb_notembedded.result:
  New BitKeeper file ``mysql-test/r/innodb_notembedded.result''
mysql-test/r/sp.result.orig:
  New BitKeeper file ``mysql-test/r/sp.result.orig''
mysql-test/r/sp_notembedded.result:
  New BitKeeper file ``mysql-test/r/sp_notembedded.result''
mysql-test/r/subselect_notembedded.result:
  New BitKeeper file ``mysql-test/r/subselect_notembedded.result''
mysql-test/t/ctype_cp932_notembedded.test:
  New BitKeeper file ``mysql-test/t/ctype_cp932_notembedded.test''
mysql-test/t/innodb_notembedded.test:
  New BitKeeper file ``mysql-test/t/innodb_notembedded.test''
mysql-test/t/sp.test.orig:
  New BitKeeper file ``mysql-test/t/sp.test.orig''
mysql-test/t/sp_notembedded.test:
  New BitKeeper file ``mysql-test/t/sp_notembedded.test''
mysql-test/t/subselect_notembedded.test:
  New BitKeeper file ``mysql-test/t/subselect_notembedded.test''

A follow-up to BUG#15011 (already fixed).


mysql-test/r/sp.result:
  Updated results for new handler tests.
mysql-test/t/sp.test:
  Additional tests for nested handlers.

  The problem was a code generation bug: cpop instructions were not generated
  when using ITERATE back to an outer block from a context with a declared
  cursor; this would make it push a new cursor without popping in-between,
  eventually overrunning the cursor stack with a crash as the result.
  Fixed the calculation of how many cursors to pop (in sp_pcontext.cc:
  diff_cursors()), and also corrected diff_cursors() and diff_handlers()
  to when doing a "leave"; don't include the last context we're leaving
  (we are then jumping to the appropriate pop instructions).


mysql-test/r/sp.result:
  Updated result for new test case (BUG#16887)
mysql-test/t/sp.test:
  New test case for BUG#16887
sql/sp_pcontext.cc:
  Added new parameter to sp_pcontext::diff_handlers() and diff_cursors():
  They can either include (for iterate jumps) or exclude (for leave jumps)
  the outer context.
  Fixed bug in diff_cursors(); it was just plain wrong and would return
  zero in some situations when it shouldn't.
sql/sp_pcontext.h:
  Added new parameter to sp_pcontext::diff_handlers() and diff_cursors():
  They can either include (for iterate jumps) or exclude (for leave jumps)
  the outer context.
sql/sql_yacc.yy:
  Added parameter to diff_handlers/diff_cursors depending on if it's an
  iterate or leave jump.
  For "leave", we don't have to include the last context we're leaving since
  we will jump to the appropriate pop instructions.