To add a new native MySQL function, use the procedure described here, which requires that you use a source distribution. You cannot add native functions to a binary distribution because it is necessary to modify MySQL source code and compile MySQL from the modified source. If you migrate to another version of MySQL (for example, when a new version is released), you must repeat the procedure with the new version.
If the new native function will be referred to in statements that will be replicated to slave servers, you must ensure that every slave server also has the function available. Otherwise, replication will fail on the slaves when they attempt to invoke the function.
To add a new native function, follow these steps to modify
source files in the
Add one line to
lex.h that defines the
function name in the
If the function prototype is simple (just takes zero, one,
two, or three arguments), add a line to the
sql_functions array in
lex.h that specifies
as the second argument (where
is the number of arguments the function takes). Also, add a
item_create.cc that creates
a function object. Look at
create_funcs_abs() for an example of
If the function prototype is not simple (for example, if it
takes a variable number of arguments), you should make two
sql_yacc.yy. One is a line
that indicates the preprocessor symbol that
yacc should define; this should be added
at the beginning of the file. The other is an
“item” to be added to the
simple_expr parsing rule that defines the
function parameters. You will need an item for each syntax
with which the function can be called. For an example that
shows how this is done, check all occurrences of
item_func.h, declare a class
Item_str_func, depending on whether your
function returns a number or a string.
item_func.cc, add one of the
following declarations, depending on whether you are
defining a numeric or string function:
double Item_func_newname::val() longlong Item_func_newname::val_int() String *Item_func_newname::Str(String *str)
If you inherit your object from any of the standard items
Item_num_func), you probably only
have to define one of these functions and let the parent
object take care of the other functions. For example, the
Item_str_func class defines a
val() function that executes
atof() on the value returned by
If the function is nondeterministic, include the following statement in the item constructor to indicate that function results should not be cached:
A function is nondeterministic if, given fixed values for its arguments, it can return different results for different invocations.
You should probably also define the following object function:
This function should at least calculate
max_length based on the given arguments.
max_length is the maximum number of
characters the function may return. This function should
maybe_null = 0 if the main
function can't return a
NULL value. The
function can check whether any of the function arguments can
NULL by checking the arguments'
maybe_null variable. Look at
Item_func_mod::fix_length_and_dec for a
typical example of how to do this.
All functions must be thread-safe. In other words, do not use any global or static variables in the functions without protecting them with mutexes.
If you want to return
::str(), you should set
null_value to 1 and return 0.
::str() object functions, there are
additional considerations to be aware of:
String *str argument provides a
string buffer that may be used to hold the result. (For more
information about the
String type, take a
look at the
::str() function should return the
string that holds the result, or
0 if the result is
All current string functions try to avoid allocating any memory unless absolutely necessary!