correctly in some cases".
In short, calls to a stored function located in another database
than the default database, may fail to replicate if the call was made
by SET, SELECT, or DO.
Longer: when a stored function is called from a statement which does not go
to binlog ("SET @A=somedb.myfunc()", "SELECT somedb.myfunc()",
"DO somedb.myfunc()"), this crafted statement is binlogged:
"SELECT myfunc();" (accompanied with a mention of the default database
if there is one). So, if "somedb" is not the default database,
the slave would fail to find myfunc(). The fix is to specify the
function's database name in the crafted binlogged statement, like this:
"SELECT somedb.myfunc();". Test added in rpl_sp.test.


mysql-test/r/rpl_sp.result:
  Because I moved the SHOW BINLOG EVENTS down a bit, big portions of its
  output move. Also, the function's database name appears in
  SELECT statements.
mysql-test/t/rpl_sp.test:
  Adding test for BUG#19725.
  Moving the SHOW BINLOG EVENTS down, it is run at the very end to
  test everything.
sql/sp_head.cc:
  When binlogging a "SELECT myfunc()" (when a stored function is executed
  inside a statement which does not go to the binlog (like a SET,
  SELECT, DO), we need to write "SELECT db_of_myfunc().myfunc()",
  because the function may be in a database which is not the default
  database.