There is great reason why you should never call stored procedures from within triggers.
Triggers are, by nature, stored procedures. Their actions are virtually hard to roll back. Even if all underlying tables are InnoDB, you will experience a proportional volume of shared row locks and annoying intermittency from exclusive row locks. Such would be the case if triggers were manipulating tables with INSERTs and UPDATEs being stagnated to perform heavy duty MVCC inside each call to a trigger.
Don't forget that Triggers require overhead. In fact, According to MySQL Stored Procedure Programming, page 256 under the head "Trigger Overhead" says the following:
It is important to remember that, by necessity, triggers add overhead
to the DML statement to which they apply. the actual amount of overhead
will depend upon the nature of the trigger, but --- as all MySQL
triggers execute FOR EACH ROW --- the overhead can rapidly accumulate
for statements that process large numbers of rows. You should
therefore avoid placing any expensive SQL statements or procedural
code in triggers.
An expanded explanation of trigger overhead is given on pages 529-531. The concluding point from that section states the following:
The lesson here is this: since the trigger code will execute once
for every row affected by a DML statement, the trigger can easily
become the most significant factor in DML performance. Code inside the
trigger body needs to be as lightweight as possible and -- in
particular -- any SQL statements in the trigger should be supported by
indexes whenever possible.
I explained other nasty aspects of Triggers in an earlier post.
SUMMARY
I would strongly recommend not calling any stored procedures from a Trigger, even if MySQL allows it. You should wlays check out the current restrictions for MySQL 5.5.
This happens because the stored procedure is actually dropped and recreated. When the procedure is dropped it loses all its permissions. Therefore, when the 'altered' version is created there are no permissions attached.
Your process to update the procedure needs to include a re-grant of the needed permissions.
I don't know your full environment, but here was a 2013 forum discussion for one MySQL tool set:
http://code.google.com/p/heidisql/issues/detail?id=3300
Best Answer
The easiest way is to check information_schema.routines metadata table.
You can get the basic list of all procedures and functions with:
You can include some other fields as needed - the exhaustive list is in the MySQL 5.7 reference - 24.21 The INFORMATION_SCHEMA ROUTINES Table
Information schema contains tables that contain the "database metadata" and describe the database's entities: tables, indexes, procedures and many others. Every relational database has some kind "database catalog" as per Rule 4 of Codd's 12 rules for RDBMSs.
So whenever you are needing some info about database objects on any RDBMS product you can always check the manual for the specifications of the "database dictionary", "database catalog" or similar.
Check here for other of the INFORMATION SCHEMA tables on Mysql 5.7.