15.1.21 CREATE PROCEDURE and CREATE FUNCTION Statements

15.1.21 CREATE PROCEDURE 및 CREATE FUNCTION 구문

1CREATE
2    [DEFINER = user]
3    PROCEDURE [IF NOT EXISTS] sp_name ([proc_parameter[,...]])
4    [characteristic ...]
5    [USING library_reference[, library_reference][, ...]]
6    routine_body
7
8CREATE
9    [DEFINER = user]
10    FUNCTION [IF NOT EXISTS] sp_name ([func_parameter[,...]])
11    RETURNS type
12    [characteristic ...] routine_body
13
14proc_parameter:
15    [ IN | OUT | INOUT ] param_name type
16
17func_parameter:
18    param_name type
19
20type:
21    Any valid MySQL data type
22
23characteristic: {
24    COMMENT 'string'
25  | LANGUAGE {SQL | JAVASCRIPT }
26  | [NOT] DETERMINISTIC
27  | { CONTAINS SQL | NO SQL | READS SQL DATA | MODIFIES SQL DATA }
28  | SQL SECURITY { DEFINER | INVOKER }
29}
30
31library_reference:
32    [database.]library_name [[AS] alias]
33
34routine_body:
35    SQL routine | AS JavaScript statements

이 구문들은 stored routine(저장 루틴, 즉 stored procedure 또는 function)을 생성하는 데 사용된다. 즉, 지정된 routine이 server에 알려지게 된다.

기본적으로 stored routine은 기본 데이터베이스와 연관된다. routine을 특정 데이터베이스와 명시적으로 연관시키려면, 생성 시 이름을 db_name.sp_name 형식으로 지정한다.

CREATE FUNCTION 구문은 MySQL에서 loadable function을 지원하기 위해서도 사용된다. Section 15.7.4.1, “CREATE FUNCTION Statement for Loadable Functions”를 참조하라. loadable function은 외부 stored function으로 간주할 수 있다. Stored function은 loadable function과 네임스페이스를 공유한다. 서로 다른 종류의 function에 대한 참조를 server가 어떻게 해석하는지에 대한 규칙은 Section 11.2.5, “Function Name Parsing and Resolution”을 참조하라.

stored procedure를 호출하려면 CALL 구문을 사용한다( Section 15.2.1, “CALL Statement” 참조). stored function을 호출하려면 식(expression)에서 이를 참조하면 된다. function은 식이 평가되는 동안 값을 반환한다.

CREATE PROCEDURE 및 CREATE FUNCTION은 CREATE ROUTINE 권한이 필요하다. DEFINER 절이 존재하는 경우, 필요한 권한은 user 값에 따라 달라지며, 이는 Section 27.8, “Stored Object Access Control”에서 설명한다. 바이너리 로깅이 활성화된 경우, CREATE FUNCTION은 Section 27.9, “Stored Program Binary Logging”에 설명된 것처럼 SUPER 권한이 필요할 수 있다.

기본적으로, MySQL은 routine 생성자에게 ALTER ROUTINE 및 EXECUTE 권한을 자동으로 부여한다. 이 동작은 automatic_sp_privileges 시스템 변수(system variable)를 비활성화하여 변경할 수 있다. Section 27.2.2, “Stored Routines and MySQL Privileges”를 참조하라.

DEFINER 및 SQL SECURITY 절은 routine 실행 시 접근 권한을 검사할 때 사용할 보안 컨텍스트(security context)를 지정하며, 이에 대해서는 이 절의 뒷부분에서 설명한다.

routine 이름이 내장 SQL function 이름과 동일한 경우, routine을 정의하거나 나중에 호출할 때 이름과 뒤따르는 괄호 사이에 공백을 사용하지 않으면 구문 에러가 발생한다. 이러한 이유로, 자신이 정의하는 stored routine에 기존 SQL function 이름을 사용하는 것은 피하라.

IGNORE_SPACE SQL 모드는 stored routine이 아니라 내장 function에 적용된다. IGNORE_SPACE이 활성화되어 있는지 여부와 관계없이, stored routine 이름 뒤에는 항상 공백을 둘 수 있다.

IF NOT EXISTS는 동일한 이름의 routine이 이미 존재하는 경우 에러가 발생하는 것을 방지한다. 이 옵션은 CREATE FUNCTION과 CREATE PROCEDURE 모두에서 지원된다.

동일한 이름의 내장 function이 이미 존재하는 경우, CREATE FUNCTION ... IF NOT EXISTS를 사용하여 stored function을 생성하려는 시도는, native function과 동일한 이름을 가진다는 경고와 함께 성공한다. 이는 IF NOT EXISTS 없이 동일한 CREATE FUNCTION 구문을 실행했을 때와 다르지 않다.

동일한 이름의 loadable function이 이미 존재하는 경우, IF NOT EXISTS를 사용하여 stored function을 생성하려는 시도 역시 경고와 함께 성공한다. 이는 IF NOT EXISTS를 지정하지 않았을 때와 동일하다.

자세한 내용은 Function Name Resolution을 참조하라.

괄호로 둘러싸인 parameter 목록은 항상 존재해야 한다. parameter가 없는 경우, 빈 parameter 목록인 ()을 사용해야 한다. parameter 이름은 대소문자를 구분하지 않는다.

각 parameter는 기본적으로 IN parameter이다. parameter에 대해 이를 다르게 지정하려면, parameter 이름 앞에 OUT 또는 INOUT 키워드를 사용한다.

참고

parameter를 IN, OUT, INOUT으로 지정하는 것은 PROCEDURE에만 유효하다. FUNCTION의 경우, parameter는 항상 IN parameter로 간주된다.

IN parameter는 procedure로 값을 전달한다. procedure가 값을 수정할 수는 있지만, procedure가 반환될 때 이 수정은 호출자에게 보이지 않는다. OUT parameter는 procedure로부터 호출자에게 값을 전달한다. procedure 내에서의 초기 값은 NULL이며, procedure가 반환될 때 그 값은 호출자에게 보인다. INOUT parameter는 호출자에 의해 초기화되며, procedure에 의해 수정될 수 있고, procedure가 반환될 때 procedure가 가한 변경 사항이 호출자에게 보인다.

각 OUT 또는 INOUT parameter에 대해서는, procedure가 반환될 때 해당 값을 얻을 수 있도록, procedure를 호출하는 CALL 구문에서 사용자 정의 변수(user-defined variable)를 전달한다. 다른 stored procedure나 function 내에서 해당 procedure를 호출하는 경우, routine parameter나 로컬 routine 변수(local routine variable)를 OUT 또는 INOUT parameter로 전달할 수도 있다. trigger 내에서 해당 procedure를 호출하는 경우에는 NEW.col_name을 OUT 또는 INOUT parameter로 전달할 수도 있다.

처리되지 않은 condition이 procedure parameter에 미치는 영향에 대한 정보는 Section 15.6.7.8, “Condition Handling and OUT or INOUT Parameters”을 참조하라.

routine 내에서 준비(프리페어드, prepared)된 statement에서는 routine parameter를 참조할 수 없다. Section 27.10, “Restrictions on Stored Programs”를 참조하라.

다음 예시는, 국가 코드가 주어졌을 때, world 데이터베이스의 city 테이블에 해당 국가에 속한 city가 몇 개인지 세는 간단한 stored procedure를 보여준다. 국가 코드는 IN parameter를 사용하여 전달하고, city 개수는 OUT parameter를 사용하여 반환한다:

1mysql> delimiter //
2
3mysql> CREATE PROCEDURE citycount (IN country CHAR(3), OUT cities INT)
4       BEGIN
5         SELECT COUNT(*) INTO cities FROM world.city
6         WHERE CountryCode = country;
7       END//
8Query OK, 0 rows affected (0.01 sec)
9
10mysql> delimiter ;
11
12mysql> CALL citycount('JPN', @cities); -- cities in Japan
13Query OK, 1 row affected (0.00 sec)
14
15mysql> SELECT @cities;
16+---------+
17| @cities |
18+---------+
19|     248 |
20+---------+
211 row in set (0.00 sec)
22
23mysql> CALL citycount('FRA', @cities); -- cities in France
24Query OK, 1 row affected (0.00 sec)
25
26mysql> SELECT @cities;
27+---------+
28| @cities |
29+---------+
30|      40 |
31+---------+
321 row in set (0.00 sec)

이 예시는 mysql 클라이언트의 delimiter 명령을 사용하여, procedure를 정의하는 동안 statement delimiter를 ;에서 //로 변경한다.

이를 통해 procedure body에서 사용된 ; delimiter가 mysql 자체에 의해 해석되지 않고 server로 그대로 전달될 수 있다. Section 27.1, “Defining Stored Programs”를 참조하라.

RETURNS 절은 FUNCTION에만 지정할 수 있으며, FUNCTION에서는 필수이다. 이는 function의 반환 타입을 나타내며, function body에는 반드시 RETURN value 구문이 포함되어야 한다. RETURN 구문이 다른 타입의 값을 반환하는 경우, 그 값은 적절한 타입으로 강제 변환(coerce)된다. 예를 들어, function이 RETURNS 절에 ENUM 또는 SET 값을 지정하지만, RETURN 구문이 integer를 반환하는 경우, function이 반환하는 값은 해당 integer에 대응하는 ENUM 멤버나 SET 멤버 집합의 문자열이 된다.

다음 예시 function은 parameter를 받아 SQL function을 사용한 연산을 수행하고 그 결과를 반환한다. 이 경우, function 정의에 내부 ; statement delimiter가 포함되어 있지 않으므로 delimiter를 사용할 필요가 없다:

1mysql> CREATE FUNCTION hello (s CHAR(20))
2    ->   RETURNS CHAR(50) DETERMINISTIC
3    ->   RETURN CONCAT('Hello, ',s,'!');
4Query OK, 0 rows affected (0.00 sec)
5
6mysql> SELECT hello('world');
7+----------------+
8| hello('world') |
9+----------------+
10| Hello, world!  |
11+----------------+
121 row in set (0.00 sec)

parameter 타입 및 function 반환 타입은 어떤 유효한 데이터 타입으로든 선언할 수 있다. CHARACTER SET 지정이 앞에 오는 경우 COLLATE 속성을 사용할 수 있다.

_routine_body_는 유효한 SQL routine statement로 구성된다. 이는 SELECT나 INSERT와 같은 단순 statement이거나, BEGIN 및 END를 사용하여 작성된 복합문(compound statement)일 수 있다. compound statement는 선언, 루프, 기타 제어 구조(control structure) statement를 포함할 수 있다.

이러한 구문에 대한 설명은 Section 15.6, “Compound Statement Syntax”에 나와 있다. 실제로 stored function은, body가 단일 RETURN 구문으로만 구성된 경우를 제외하고, 보통 compound statement를 사용한다.

AS 키워드는 뒤따르는 routine body가 SQL 이외의 언어로 작성되었음을 나타내는 데 사용된다. 이는 routine body의 opening 달러 인용 구분자(dollar-quoted delimiter)나 따옴표 바로 앞에 온다. Section 27.3, “JavaScript Stored Programs”를 참조하라.

MySQL은 routine에 CREATE 및 DROP과 같은 DDL statement를 포함하는 것을 허용한다. MySQL은 또한 stored function이 아닌 stored procedure에 한해서는 COMMIT과 같은 SQL 트랜잭션 statement를 포함하는 것을 허용한다.

Stored function은 명시적 또는 암시적 commit 또는 rollback을 수행하는 statement를 포함할 수 없다. 이러한 statement에 대한 지원은 SQL 표준에서 요구되지 않으며, 각 DBMS 벤더가 이를 허용할지 여부를 결정하도록 되어 있다.

result set을 반환하는 statement는 stored procedure 내에서는 사용할 수 있지만 stored function 내에서는 사용할 수 없다. 이 제한은 INTO var_list 절이 없는 SELECT statement 및 SHOW, EXPLAIN, CHECK TABLE과 같은 다른 statement를 포함한다. function 정의 시점에 result set을 반환하는 것이 확실한 statement의 경우, Not allowed to return a result set from a function 에러 (ER_SP_NO_RETSET)가 발생한다. 런타임에만 result set을 반환하는지 여부를 알 수 있는 statement의 경우, PROCEDURE %s can't return a result set in the given context 에러 (ER_SP_BADSELECT)가 발생한다.

stored routine 내에서는 USE 구문을 사용할 수 없다. routine이 호출될 때, 암시적으로 USE db_name이 수행되었다가 (routine이 종료되면) 되돌려진다. 이로 인해 routine은 실행되는 동안 지정된 데이터베이스를 기본 데이터베이스로 사용하게 된다. routine 기본 데이터베이스 이외의 데이터베이스에 있는 객체(object)에 대한 참조는 적절한 데이터베이스 이름을 사용하여 한정(qualified)되어야 한다.

stored routine에서 허용되지 않는 statement에 대한 추가 정보는 Section 27.10, “Restrictions on Stored Programs”을 참조하라.

MySQL 인터페이스를 가지는 언어로 작성된 프로그램 내에서 stored procedure를 호출하는 방법에 대한 정보는 Section 15.2.1, “CALL Statement”를 참조하라.

MySQL은 routine이 생성 또는 변경될 때 유효한 sql_mode 시스템 변수 설정을 저장하며, routine이 실행을 시작할 때의 현재 server SQL 모드와 관계없이 항상 이 설정을 적용하여 routine을 실행한다.

invoker의 SQL 모드에서 routine의 SQL 모드로 전환되는 시점은, 인자(argument) 평가 및 그 결과 값을 routine parameter에 할당한 이후이다. strict SQL 모드에서 routine을 정의했지만 nonstrict 모드에서 routine을 호출하는 경우, 인자의 routine parameter로의 할당은 strict 모드에서 수행되지 않는다. routine에 전달되는 식이 strict SQL 모드에서 할당되기를 요구하는 경우, strict 모드가 유효한 상태에서 routine을 호출해야 한다.

COMMENT characteristic은 MySQL 확장으로, stored routine을 설명하는 데 사용할 수 있다. 이 정보는 SHOW CREATE PROCEDURE 및 SHOW CREATE FUNCTION 구문에 의해 표시된다.

LANGUAGE characteristic은 routine이 작성된 언어를 나타낸다. MLE 컴포넌트(component)가 사용 가능하지 않은 경우( Section 7.5.7, “Multilingual Engine Component (MLE)” 참조), server는 이 characteristic을 무시하며 SQL routine만 지원한다. MLE 컴포넌트가 존재하는 경우, server는 JavaScript로 작성된 stored routine을 지원하며( Section 27.3, “JavaScript Stored Programs” 참조), 이때는 LANGUAGE JAVASCRIPT를 사용하여 이를 지정해야 한다. MLE 컴포넌트가 설치되어 있든 아니든, 이 characteristic이 제공되지 않으면 stored routine에서 사용되는 언어는 SQL로 간주된다.

routine은 동일한 입력 parameter에 대해 항상 동일한 결과를 생성하면 “deterministic”으로 간주되며, 그렇지 않으면 “not deterministic”으로 간주된다. routine 정의에서 DETERMINISTIC 또는 NOT DETERMINISTIC이 모두 주어지지 않으면, 기본값은 NOT DETERMINISTIC이다. function이 deterministic이라고 선언하려면 DETERMINISTIC을 명시적으로 지정해야 한다.

routine의 특성 평가는 생성자의 “정직성(honesty)”에 기반한다. MySQL은 DETERMINISTIC으로 선언된 routine이 비결정적(비-deterministic) 결과를 생성하는 statement로부터 자유로운지 검사하지 않는다. 하지만 routine을 잘못 선언하면 결과나 성능에 영향을 미칠 수 있다. 비결정적 routine을 DETERMINISTIC으로 선언하면, 옵티마이저(optimizer)가 잘못된 실행 계획(execution plan)을 선택해 예기치 않은 결과를 초래할 수 있다. 결정적 routine을 NONDETERMINISTIC으로 선언하면, 사용할 수 있는 최적화가 사용되지 않아 성능이 저하될 수 있다.

바이너리 로깅이 활성화된 경우, DETERMINISTIC characteristic은 MySQL이 어떤 routine 정의를 허용할지에 영향을 미친다. Section 27.9, “Stored Program Binary Logging”을 참조하라.

NOW() function(또는 그 동의어)이나 RAND()를 포함하는 routine은 비결정적이지만, 복제 안전(replication-safe)일 수도 있다. NOW()의 경우, 바이너리 로그에는 타임스탬프가 포함되며 올바르게 복제된다. RAND() 역시 routine 실행 동안 단 한 번만 호출되는 한 올바르게 복제된다. (routine 실행 타임스탬프와 random number seed를 소스(source)와 레플리카(replica)에서 동일한 암시적 입력으로 간주할 수 있다.)

여러 characteristic은 routine의 데이터 사용 특성에 대한 정보를 제공한다. MySQL에서 이 characteristic들은 참고(advisory) 용도에만 사용된다. server는 이를 이용해 routine이 실행할 수 있는 statement의 종류를 제한하지 않는다.

• CONTAINS SQL은 routine에 데이터를 읽거나 쓰는 statement가 포함되지 않음을 나타낸다. 이들 characteristic이 명시적으로 주어지지 않은 경우 이것이 기본값이다. 이러한 statement의 예로는 데이터를 읽거나 쓰지 않고 실행만 하는 SET @x = 1이나 DO RELEASE_LOCK('abc')가 있다.

• NO SQL은 routine에 SQL statement가 전혀 포함되어 있지 않음을 나타낸다.

• READS SQL DATA는 routine에 데이터를 읽는 statement(예: SELECT)는 포함하지만, 데이터를 쓰는 statement는 포함하지 않음을 나타낸다.

• MODIFIES SQL DATA는 routine에 데이터를 쓸 수 있는 statement(예: INSERT 또는 DELETE)가 포함될 수 있음을 나타낸다.

SQL SECURITY characteristic은 보안 컨텍스트, 즉 routine이 routine의 DEFINER 절에 명시된 account의 권한을 사용하여 실행될지(DEFINER), routine을 호출한 user의 권한을 사용하여 실행될지(INVOKER)를 지정할 수 있다. 이 account는 routine이 연관된 데이터베이스에 접근 권한을 가지고 있어야 한다. 기본값은 DEFINER이다. routine을 호출하는 user와, routine이 definer 보안 컨텍스트에서 실행되는 경우 DEFINER account는 모두 해당 routine에 대한 EXECUTE 권한을 가지고 있어야 한다.

DEFINER 절은 SQL SECURITY DEFINER characteristic을 갖는 routine에 대해, routine 실행 시 접근 권한을 검사할 때 사용할 MySQL account를 지정한다.

DEFINER 절이 존재하는 경우, user 값은 'user_name'@'host_name', CURRENT_USER, 또는 CURRENT_USER() 형식의 MySQL account여야 한다. 허용되는 user 값은 자신이 보유한 권한에 따라 달라지며, 이에 대해서는 Section 27.8, “Stored Object Access Control”에 설명되어 있다. stored routine 보안에 대한 추가 정보 역시 해당 절을 참조하라.

DEFINER 절이 생략되면, 기본 definer는 CREATE PROCEDURE 또는 CREATE FUNCTION 구문을 실행한 user이다. 이는 DEFINER = CURRENT_USER를 명시적으로 지정한 것과 동일하다.

SQL SECURITY DEFINER characteristic으로 정의된 stored routine body 내에서, CURRENT_USER function은 routine의 DEFINER 값을 반환한다. stored routine 내에서 사용자 감사(user auditing)를 수행하는 방법에 대한 정보는 Section 8.2.23, “SQL-Based Account Activity Auditing”을 참조하라.

다음 procedure를 살펴보자. 이 procedure는 mysql.user 시스템 테이블에 나열된 MySQL account의 개수를 표시한다:

1CREATE DEFINER = 'admin'@'localhost' PROCEDURE account_count()
2BEGIN
3  SELECT 'Number of accounts:', COUNT(*) FROM mysql.user;
4END;

이 procedure는 누가 정의하든 상관없이 'admin'@'localhost'라는 DEFINER account가 할당된다. 또한, 누가 호출하든 상관없이(기본 보안 characteristic이 DEFINER이기 때문에) 이 account의 권한으로 실행된다. 이 procedure는, 호출자가 해당 procedure에 대한 EXECUTE 권한을 가지고 있고 'admin'@'localhost'가 mysql.user 테이블에 대한 SELECT 권한을 가지고 있는지에 따라 성공 또는 실패한다.

이제 동일한 procedure를 SQL SECURITY INVOKER characteristic과 함께 정의한다고 가정해보자:

1CREATE DEFINER = 'admin'@'localhost' PROCEDURE account_count()
2SQL SECURITY INVOKER
3BEGIN
4  SELECT 'Number of accounts:', COUNT(*) FROM mysql.user;
5END;

procedure는 여전히 DEFINER로 'admin'@'localhost'를 갖지만, 이번에는 호출한 user의 권한으로 실행된다. 따라서 이 procedure는, 호출자가 해당 procedure에 대한 EXECUTE 권한과 mysql.user 테이블에 대한 SELECT 권한을 가지고 있는지에 따라 성공 또는 실패한다.

기본적으로, SQL SECURITY DEFINER characteristic을 가진 routine이 실행될 때, MySQL Server는 DEFINER 절에 명시된 MySQL account에 대해 활성 역할(active role)을 설정하지 않고, 오직 기본 역할(default role)만 설정한다. 예외는 activate_all_roles_on_login 시스템 변수가 활성화된 경우로, 이때 MySQL Server는 필수 역할(mandatory role)을 포함하여 DEFINER user에게 부여된 모든 역할을 설정한다. 따라서, 역할을 통해 부여된 권한은 기본적으로 CREATE PROCEDURE 또는 CREATE FUNCTION 구문이 실행될 때 검사되지 않는다. stored program의 경우, 실행이 기본과 다른 역할로 이루어져야 한다면, program body에서 SET ROLE을 실행하여 필요한 역할을 활성화할 수 있다. 역할에 부여된 권한은 변경될 수 있으므로, 이는 신중하게 수행해야 한다.

server는 routine parameter, DECLARE로 생성된 로컬 routine 변수, function 반환 값의 데이터 타입을 다음과 같이 처리한다:

• 대입은 데이터 타입 불일치 및 overflow에 대해 검사된다. 변환 및 overflow 문제는 경고를 발생시키며, strict SQL 모드에서는 에러를 발생시킨다.

• 스칼라(scalar) 값만 대입할 수 있다. 예를 들어 SET x = (SELECT 1, 2)와 같은 구문은 유효하지 않다.

• 문자형 데이터 타입의 경우, 선언에 CHARACTER SET이 포함되어 있다면 지정된 문자 집합(character set)과 그 기본 콜레이션(default collation)이 사용된다. COLLATE 속성도 존재한다면, 기본 콜레이션 대신 해당 콜레이션이 사용된다.

CHARACTER SET 및 COLLATE가 존재하지 않는 경우, routine 생성 시점에 유효했던 데이터베이스 문자 집합과 콜레이션이 사용된다. server가 데이터베이스 문자 집합과 콜레이션을 사용하지 않도록 하려면, 문자형 데이터 parameter에 대해 명시적으로 CHARACTER SET과 COLLATE 속성을 제공하라.

데이터베이스 기본 문자 집합 또는 콜레이션을 변경하는 경우, 새 데이터베이스 기본값을 사용해야 하는 stored routine은 삭제 후 다시 생성해야 한다.

데이터베이스 문자 집합과 콜레이션은 character_set_database 및 collation_database 시스템 변수 값으로 주어진다. 자세한 내용은 Section 12.3.3, “Database Character Set and Collation”을 참조하라.

CREATE PROCEDURE 및 CREATE FUNCTION은, 하나 이상의 JavaScript 라이브러리를 import 하기 위한 USING 옵션을 지원하며, 이 참조들은 USING 키워드 뒤에 오는 괄호 안에 나열된다. 각 참조는 다음과 같은 형식의 [database.]library_name [[AS] alias]로, 아래 나열된 부분으로 구성된다:

• 라이브러리가 위치한 데이터베이스 또는 스키마 이름으로, 뒤에 마침표가 온다. 이는 선택적이며, 지정하지 않으면 stored routine이 생성된 데이터베이스가 사용된다.

• 라이브러리 이름.

• 선택적인 라이브러리 별칭(alias)으로, 그 앞에는 선택적인 AS 키워드가 올 수 있다. 이는 stored function 또는 stored procedure 내에서 라이브러리 객체에 대한 네임스페이스를 나타내는 데 사용할 수 있다.

예:

1mysql> CREATE LIBRARY IF NOT EXISTS jslib.lib1 LANGUAGE JAVASCRIPT
2    ->     AS $$
3    $>       export function f(n) {
4    $>         return n
5    $>       }
6    $>     $$;
7Query OK, 0 rows affected (0.02 sec)
8
9mysql> CREATE LIBRARY IF NOT EXISTS jslib.lib2 LANGUAGE JAVASCRIPT
10    ->     AS $$
11    $>       export function g(n) {
12    $>         return n * 2
13    $>       }
14    $>     $$;
15Query OK, 0 rows affected (0.00 sec)
16
17mysql> CREATE FUNCTION foo(n INTEGER) RETURNS INTEGER LANGUAGE JAVASCRIPT
18    ->     USING (jslib.lib1 AS mylib, jslib.lib2 AS yourlib)
19    ->     AS $$
20    $>       return mylib.f(n) + yourlib.g(n)
21    $>     $$;
22Query OK, 0 rows affected (0.01 sec)
23
24mysql> SELECT foo(8);
25+--------+
26| foo(8) |
27+--------+
28|     24 |
29+--------+
301 row in set (0.00 sec)
31
32mysql> SELECT * FROM information_schema.routines WHERE ROUTINE_NAME='foo'\G
33*************************** 1. row ***************************
34           SPECIFIC_NAME: foo
35         ROUTINE_CATALOG: def
36          ROUTINE_SCHEMA: jslib
37            ROUTINE_NAME: foo
38            ROUTINE_TYPE: FUNCTION
39               DATA_TYPE: int
40CHARACTER_MAXIMUM_LENGTH: NULL
41  CHARACTER_OCTET_LENGTH: NULL
42       NUMERIC_PRECISION: 10
43           NUMERIC_SCALE: 0
44      DATETIME_PRECISION: NULL
45      CHARACTER_SET_NAME: NULL
46          COLLATION_NAME: NULL
47          DTD_IDENTIFIER: int
48            ROUTINE_BODY: EXTERNAL
49      ROUTINE_DEFINITION:
50      return mylib.f(n) + otherlib.g(n)
51
52           EXTERNAL_NAME: NULL
53       EXTERNAL_LANGUAGE: JAVASCRIPT
54         PARAMETER_STYLE: SQL
55        IS_DETERMINISTIC: NO
56         SQL_DATA_ACCESS: CONTAINS SQL
57                SQL_PATH: NULL
58           SECURITY_TYPE: DEFINER
59                 CREATED: 2024-12-16 11:27:28
60            LAST_ALTERED: 2024-12-16 11:27:28
61                SQL_MODE: ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,
62NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
63         ROUTINE_COMMENT:
64                 DEFINER: me@localhost
65    CHARACTER_SET_CLIENT: utf8mb4
66    COLLATION_CONNECTION: utf8mb4_0900_ai_ci
67      DATABASE_COLLATION: utf8mb4_0900_ai_ci
681 row in set (0.00 sec)

USING은 CREATE PROCEDURE 또는 CREATE FUNCTION 구문에, 해당 구문에 LANGUAGE=JAVASCRIPT 절이 명시적으로 포함된 경우에만 사용할 수 있다.

JavaScript procedure 코드에서 특정 라이브러리를 사용하려면, 해당 라이브러리에 대한 EXECUTE 권한을 보유하고 있어야 한다. 이는 CREATE FUNCTION 또는 CREATE PROCEDURE 구문을 실행할 때, 구문의 USING 절에 나열된 각 라이브러리에 대해 검사된다.

SQL SECURITY DEFINER와 SQL SECURITY INVOKER는 라이브러리가 직접 import 되었는지 간접적으로 import 되었는지와 관계없이 적용된다. 또한 automatic_sp_privileges 시스템 변수는 stored function 및 stored procedure에 적용되는 것과 동일한 방식으로 라이브러리에도 적용된다.

USING으로 import할 수 있는 JavaScript 라이브러리를 생성하는 방법에 대한 정보는 Section 15.1.19, “CREATE LIBRARY Statement”를 참조하라. 추가 정보 및 예시는 Section 27.3.8, “Using JavaScript Libraries”도 참조하라.