Rechercher dans le manuel MySQL
9.2.4 Function Name Parsing and Resolution
MySQL supports built-in (native) functions, user-defined functions (UDFs), and stored functions. This section describes how the server recognizes whether the name of a built-in function is used as a function call or as an identifier, and how the server determines which function to use in cases when functions of different types exist with a given name.
Built-In Function Name Parsing
The parser uses default rules for parsing names of built-in
functions. These rules can be changed by enabling the
IGNORE_SPACE
SQL mode.
When the parser encounters a word that is the name of a
built-in function, it must determine whether the name
signifies a function call or is instead a nonexpression
reference to an identifier such as a table or column name. For
example, in the following statements, the first reference to
count
is a function call, whereas the
second reference is a table name:
The parser should recognize the name of a built-in function as indicating a function call only when parsing what is expected to be an expression. That is, in nonexpression context, function names are permitted as identifiers.
However, some built-in functions have special parsing or implementation considerations, so the parser uses the following rules by default to distinguish whether their names are being used as function calls or as identifiers in nonexpression context:
To use the name as a function call in an expression, there must be no whitespace between the name and the following
(
parenthesis character.Conversely, to use the function name as an identifier, it must not be followed immediately by a parenthesis.
The requirement that function calls be written with no
whitespace between the name and the parenthesis applies only
to the built-in functions that have special considerations.
COUNT
is one such name. The
sql/lex.h
source file lists the names of
these special functions for which following whitespace
determines their interpretation: names defined by the
SYM_FN()
macro in the
symbols[]
array.
The following list names the functions in MySQL
8.0 that are affected by the
IGNORE_SPACE
setting and
listed as special in the sql/lex.h
source
file. You may find it easiest to treat the no-whitespace
requirement as applying to all function calls.
ADDDATE
BIT_AND
BIT_OR
BIT_XOR
CAST
COUNT
CURDATE
CURTIME
DATE_ADD
DATE_SUB
EXTRACT
GROUP_CONCAT
MAX
MID
MIN
NOW
POSITION
SESSION_USER
STD
STDDEV
STDDEV_POP
STDDEV_SAMP
SUBDATE
SUBSTR
SUBSTRING
SUM
SYSDATE
SYSTEM_USER
TRIM
VARIANCE
VAR_POP
VAR_SAMP
For functions not listed as special in
sql/lex.h
, whitespace does not matter.
They are interpreted as function calls only when used in
expression context and may be used freely as identifiers
otherwise. ASCII
is one such name. However,
for these nonaffected function names, interpretation may vary
in expression context:
is
interpreted as a built-in function if there is one with the
given name; if not,
func_name
()
is
interpreted as a user-defined function or stored function if
one exists with that name.
func_name
()
The IGNORE_SPACE
SQL mode
can be used to modify how the parser treats function names
that are whitespace-sensitive:
With
IGNORE_SPACE
disabled, the parser interprets the name as a function call when there is no whitespace between the name and the following parenthesis. This occurs even when the function name is used in nonexpression context:- near 'count(i INT)'
To eliminate the error and cause the name to be treated as an identifier, either use whitespace following the name or write it as a quoted identifier (or both):
With
IGNORE_SPACE
enabled, the parser loosens the requirement that there be no whitespace between the function name and the following parenthesis. This provides more flexibility in writing function calls. For example, either of the following function calls are legal:However, enabling
IGNORE_SPACE
also has the side effect that the parser treats the affected function names as reserved words (see Section 9.3, “Keywords and Reserved Words”). This means that a space following the name no longer signifies its use as an identifier. The name can be used in function calls with or without following whitespace, but causes a syntax error in nonexpression context unless it is quoted. For example, withIGNORE_SPACE
enabled, both of the following statements fail with a syntax error because the parser interpretscount
as a reserved word:To use the function name in nonexpression context, write it as a quoted identifier:
To enable the IGNORE_SPACE
SQL mode, use this statement:
IGNORE_SPACE
is also enabled
by certain other composite modes such as
ANSI
that include it in
their value:
Check Section 5.1.11, “Server SQL Modes”, to see which composite modes
enable IGNORE_SPACE
.
To minimize the dependency of SQL code on the
IGNORE_SPACE
setting, use
these guidelines:
Avoid creating UDFs or stored functions that have the same name as a built-in function.
Avoid using function names in nonexpression context. For example, these statements use
count
(one of the affected function names affected byIGNORE_SPACE
), so they fail with or without whitespace following the name ifIGNORE_SPACE
is enabled:If you must use a function name in nonexpression context, write it as a quoted identifier:
The following rules describe how the server resolves references to function names for function creation and invocation:
Built-in functions and user-defined functions
An error occurs if you try to create a UDF with the same name as a built-in function.
Built-in functions and stored functions
It is possible to create a stored function with the same name as a built-in function, but to invoke the stored function it is necessary to qualify it with a schema name. For example, if you create a stored function named
PI
in thetest
schema, invoke it astest.PI()
because the server resolvesPI()
without a qualifier as a reference to the built-in function. The server generates a warning if the stored function name collides with a built-in function name. The warning can be displayed withSHOW WARNINGS
.User-defined functions and stored functions
User-defined functions and stored functions share the same namespace, so you cannot create a UDF and a stored function with the same name.
The preceding function name resolution rules have implications for upgrading to versions of MySQL that implement new built-in functions:
If you have already created a user-defined function with a given name and upgrade MySQL to a version that implements a new built-in function with the same name, the UDF becomes inaccessible. To correct this, use
DROP FUNCTION
to drop the UDF andCREATE FUNCTION
to re-create the UDF with a different nonconflicting name. Then modify any affected code to use the new name.If a new version of MySQL implements a built-in function with the same name as an existing stored function, you have two choices: Rename the stored function to use a nonconflicting name, or change calls to the function so that they use a schema qualifier (that is, use
syntax). In either case, modify any affected code accordingly.schema_name
.func_name
()
Document created the 26/06/2006, last modified the 26/10/2018
Source of the printed document:https://www.gaudry.be/en/mysql-rf-function-resolution.html
The infobrol is a personal site whose content is my sole responsibility. The text is available under CreativeCommons license (BY-NC-SA). More info on the terms of use and the author.
References
These references and links indicate documents consulted during the writing of this page, or which may provide additional information, but the authors of these sources can not be held responsible for the content of this page.
The author This site is solely responsible for the way in which the various concepts, and the freedoms that are taken with the reference works, are presented here. Remember that you must cross multiple source information to reduce the risk of errors.