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"

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

into  dsl-hkigw8-feb1fb00-100.dhcp.inet.fi:/usr_rh9/home/elkin.rh9/MySQL/TEAM/FIXES/5.0/20919_temp_nlog

into  trift2.:/M50/mysql-5.0

into  trift2.:/M50/back23-5.0

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

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

closing temp tables through end_thread
had a flaw in binlog-off branch of close_temporary_tables where
next table to close was reset via table->next
 for (table= thd->temporary_tables; table; table= table->next)
which was wrong since the current table instance got destoyed at
	close_temporary(table, 1);

The fix adapts binlog-on branch method to engage the loop's internal 'next' variable which holds table->next prior table's destoying.

between pointer to function and pointer to object.

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

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

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