Bug#21422 GRANT/REVOKE possible inside stored function, probably in a trigger
Bug#17244 GRANT gives strange error message when used in a stored function

GRANT/REVOKE statements are non-transactional (no explicit transaction
boundaries) in nature and hence are forbidden inside stored functions and
triggers, but they weren't being effectively forbidden. Furthermore, the
absence of implict commits makes changes made by GRANT/REVOKE statements to
not be rolled back.

The implemented fix is to issue a implicit commit with every GRANT/REVOKE
statement, effectively prohibiting these statements in stored functions
and triggers. The implicit commit also fixes the replication bug, and looks
like being in concert with the behavior of DDL and administrative statements.

Since this is a incompatible change, the following sentence should be
added to the Manual in the very end of the 3rd paragraph, subclause
13.4.3 "Statements That Cause an Implicit Commit": "Beginning with
MySQL 5.0.??, the GRANT and REVOKE statements cause an implicit commit."

Patch contributed by Vladimir Shebordaev


mysql-test/r/sp-error.result:
  Test case result for Bug#17244
mysql-test/t/sp-error.test:
  Test case for Bug#17244
sql/sp_head.cc:
  Set that a procedure with GRANT/REVOKE command has a (implicit or explicit)
  commit.
sql/sql_parse.cc:
  End active transaction in SQLCOM_GRANT and SQLCOM_REVOKE, and thus effectively
  prohibit these statements in stored functions and triggers. An implicit commit
  also fixes a bug in replication, when GRANT or REVOKE would disappear from the
  binary log in case of a subsequent ROLLBACK, since they were considered
  transactional statements.
mysql-test/suite/rpl/r/rpl_binlog_grant.result:
  Add test case result for Bug#21975
mysql-test/suite/rpl/t/rpl_binlog_grant.test:
  Add test case for Bug#21975