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.

into  weblab.(none):/home/marcsql/TREE/mysql-5.0-21269

The problem was that the grammar allows to create a function with an optional
definer clause, and define it as a UDF with the SONAME keyword.
Such combination should be reported as an error.

The solution is to not change the grammar itself, and to introduce a
specific check in the yacc actions in 'create_function_tail' for UDF,
that now reports ER_WRONG_USAGE when using both DEFINER and SONAME.

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug16581

           'conc_sys' test

Concurrent execution of SELECT involing at least two INFORMATION_SCHEMA
tables, DROP DATABASE statement and DROP TABLE statement could have
resulted in stalled connection for this SELECT statement.

The problem was that for the first query of a join there was a race
between select from I_S.TABLES and DROP DATABASE, and the error (no
such database) was prepared to be send to the client, but the join
processing was continued.  On second query to I_S.COLUMNS there was a
race with DROP TABLE, but this error (no such table) was downgraded to
warning, and thd->net.report_error was reset.  And so neither result
nor error was sent to the client.

The solution is to stop join processing once it is clear we are going
to report a error, and also to downgrade to warnings file system errors
like 'no such database' (unless we are in the 'SHOW' command), because
I_S is designed not to use locks and the query to I_S should not abort
if something is dropped in the middle.

No test case is provided since this bug is a result of a race, and is
timing dependant.  But we test that plain SHOW TABLES and SHOW COLUMNS
give a error if there is no such database or a table respectively.

can be not replicable.

Now CREATE statements for writing in the binlog are created as follows:
  - the beginning of the statement is re-created;
  - the rest of the statement is copied from the original query.

The problem appears when there is a version-specific comment (produced by
mysqldump), started in the re-created part of the statement and closed in the
copied part -- there is closing comment-parenthesis, but there is no opening
one.

The proper fix could be to re-create original statement, but we can not
implement it in 5.0. So, for 5.0 the fix is just to cut closing
comment-parenthesis. This technique is also used for SHOW CREATE PROCEDURE
statement (so we are able to reuse existing code).

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.

BUG#20761 is fixed.

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug14702

           CREATE PROCEDURE

The bug was fixed already.  This changeset adds a test case.

when calling a SP from C API"

The bug was caused by lack of checks for misuse in mysql_real_query. 
A stored procedure always returns at least one result, which is the 
status of execution of the procedure itself.
This result, or so-called OK packet, is similar to a result
returned by INSERT/UPDATE/CREATE operations: it contains the overall
status of execution, the number of affected rows and the number of
warnings. The client test program attached to the bug did not read this 
result and ivnoked the next query. In turn, libmysql had no check for 
such scenario and mysql_real_query was simply trying to send that query 
without reading the pending response, thus messing up the communication
protocol.

The fix is to return an error from mysql_real_query when it's called
prior to retrieval of all pending results.

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug19207

  
Fix for the bug in mysql-test-run.pl which prevents other tests succeed
after IM-test failure.
  
The idea of the fix of BUG#20716 is to:
  1. Check each SHOW INSTANCES statement, add necessary "sleep" instruction before;
  2. Move all environment checkings into the one file and include it everywhere.

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21013

           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.

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug18630

           context.

Routine arguments were evaluated in the security context of the routine
itself, not in the caller's context.

The bug is fixed the following way:

  - Item_func_sp::find_and_check_access() has been split into two
    functions: Item_func_sp::find_and_check_access() itself only
    finds the function and check that the caller have EXECUTE privilege
    on it.  New function set_routine_security_ctx() changes security
    context for SUID routines and checks that definer have EXECUTE
    privilege too.

  - new function sp_head::execute_trigger() is called from
    Table_triggers_list::process_triggers() instead of
    sp_head::execute_function(), and is effectively just as the
    sp_head::execute_function() is, with all non-trigger related code
    removed, and added trigger-specific security context switch.

  - call to Item_func_sp::find_and_check_access() stays outside
    of sp_head::execute_function(), and there is a code in
    sql_parse.cc before the call to sp_head::execute_procedure() that
    checks that the caller have EXECUTE privilege, but both
    sp_head::execute_function() and sp_head::execute_procedure() call
    set_routine_security_ctx() after evaluating their parameters,
    and restore the context after the body is executed.

into  bodhi.local:/opt/local/work/mysql-5.0-runtime

into  dl145k.mysql.com:/data0/mkindahl/bk/mysql-5.0-rpl

when dropping/creating tables"

into  bodhi.local:/opt/local/work/mysql-5.0-runtime-merge-41

into  bodhi.local:/opt/local/work/mysql-5.0-runtime-merge-41

into  chilla.local:/home/mydev/mysql-5.0-amerge

into  trift2.:/M50/mysql-5.0

into  dl145k.mysql.com:/data0/mkindahl/bk/MERGE/mysql-5.0-merge

into  bodhi.local:/opt/local/work/mysql-5.0-runtime-merge-41

into  trift2.:/M50/mysql-5.0

into  gbichot3.local:/home/mysql_src/mysql-5.0

into  orca.ndb.mysql.com:/space_old/pekka/ndb/version/my50-1.2167.1.2

fails"