database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-07-29 05:21:33 +03:00
Code Activity

WL#2971 "change log-bin-trust-routine-creators=0 to apply only to functions".

Browse Source 
Indeed now that stored procedures CALL is not binlogged, but instead the invoked substatements are,
the restrictions applied by log-bin-trust-routine-creators=0 are superfluous for procedures.
They still need to apply to functions where function calls are written to the binlog (for example as "DO myfunc(3)").
We rename the variable to log-bin-trust-function-creators but allow the old name until some future version (and issue a warning if old name is used).


mysql-test/mysql-test-run.pl:
  update to new option name
mysql-test/mysql-test-run.sh:
  update to new option name
mysql-test/mysql_test_run_new.c:
  update to new option name
mysql-test/r/rpl_sp.result:
  result update
mysql-test/t/rpl_sp-slave.opt:
  we need to skip this error to not hit BUG#14769
mysql-test/t/rpl_sp.test:
  Test update:
  1) as log-bin-trust-routine-creators now affects only functions, the testing of this option, which was
  mainly done on procedures, is moved to functions
  2) cleanup is simplified; and instead of many SHOW BINLOG EVENTS we do a big one in the end, which is more
  maintainable.
  3) we test a few more function and procedures cases to see how they replicate.
  4) removing out-of-date comments
sql/item_func.cc:
  This warning is wrong since binlogging of functions was changed in August. If a function fails
  in the middle, it will be binlogged with its error code (i.e. properly).
sql/mysql_priv.h:
  variable name changed
sql/mysqld.cc:
  option name changes. A precision about --read-only.
sql/set_var.cc:
  a new class sys_var_trust_routine_creators to be able to issue a "this is a deprecated variable" warning if used.
sql/set_var.h:
  new class to be able to issue a "this is a deprecated variable" warning if used.
sql/share/errmsg.txt:
  routine -> function
sql/sp.cc:
  log-bin-trust-routine-creators now applies only to functions.
sql/sql_parse.cc:
  1) sending ER_FAILED_ROUTINE_BREAK_BINLOG is wrong since August as we don't binlog CALL anymore but instead binlog the substatements;
  the clear_error() goes away too as it was necessary only when we created a binlog event from the "CALL" statement.
  2) log-bin-trust-routine-creators now applies only to functions.
sql/sql_trigger.cc:
  comments.
This commit is contained in:
unknown
2005-11-10 17:50:51 +01:00
parent 93607e351a
commit 5d9c8e9543
15 changed files with 433 additions and 214 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
sql/sql_trigger.cc
View File

@ -131,9 +131,12 @@ bool mysql_create_or_drop_trigger(THD *thd, TABLE_LIST *tables, bool create)
But a trigger can in theory be used to do nasty things (if it supported
DROP for example) so we do the check for privileges. For now there is
already a stronger test right above; but when this stronger test will
be removed, the test below will hold.
be removed, the test below will hold. Because triggers have the same
nature as functions regarding binlogging: their body is implicitely
binlogged, so they share the same danger, so trust_function_creators
applies to them too.
*/
if (!trust_routine_creators && mysql_bin_log.is_open() &&
if (!trust_function_creators && mysql_bin_log.is_open() &&
!(thd->security_ctx->master_access & SUPER_ACL))
{
my_error(ER_BINLOG_CREATE_ROUTINE_NEED_SUPER, MYF(0));