To deal with these problems, MySQL enforces the following requirement: On a source server, creation and alteration of a function is refused unless you declare the function to be deterministic or to not modify data. Two sets of function characteristics apply here: 

•The DETERMINISTIC  and NOT DETERMINISTIC  characteristics indicate whether a function always produces the same result for given inputs. The default is NOT DETERMINISTIC  if neither characteristic is given. To declare that a function is deterministic, you must specify DETERMINISTIC explicitly. 

•The CONTAINS SQL , NO SQL , READS SQL DATA , and MODIFIES SQL DATA  characteristics provide information about whether the function reads or writes data. Either NO SQL  or READS SQL DATA indicates that a function does not change data, but you must specify one of these explicitly because the default is CONTAINS SQL  if no characteristic is given. 

By default, for a CREATE FUNCTION  statement to be accepted, at least one of DETERMINISTIC , NO SQL , or READS SQL DATA  must be specified explicitly. Otherwise an error occurs: 

ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable) 

If you set log_bin_trust_function_creators  to 1, the requirement that functions be deterministic or not modify data is dropped. 

•Stored procedure calls are logged at the statement level rather than at the CALL  level. That is, the server does not log the CALL  statement, it logs those statements within the procedure that actually execute. As a result, the same changes that occur on the source server also occur on replicas. This prevents problems that could result from a procedure having different execution paths on different machines. 

In general, statements executed within a stored procedure are written to the binary log using the same rules that would apply were the statements to be executed in standalone fashion. Some special care is taken when logging procedure statements because statement execution within procedures is not quite the same as in nonprocedure context: 

• A statement to be logged might contain references to local procedure variables. These variables do not exist outside of stored procedure context, so a statement that refers to such a variable cannot be logged literally. Instead, each reference to a local variable is replaced by this construct for logging purposes: 

NAME_CONST( var_name , var_value ) 

var_name  is the local variable name, and var_value  is a constant indicating the value that the variable has at the time the statement is logged. NAME_CONST()  has a value of var_value , and a “name”  of var_name . Thus, if you invoke this function directly, you get a result like this: 

mysql> SELECT NAME_CONST(’myname’, 14); +--------+ | myname | +--------+ | 14 | 

