手順の作成

適用対象:はい Databricks SQL Databricks Runtime 17.0 以上の チェックマークが付いたチェックははい Unity カタログのみ

引数を受け取るか変更し、SQL ステートメントのセットを実行し、必要に応じて結果セットを返すプロシージャを Unity Catalog に作成します。

構文

CREATE [OR REPLACE] PROCEDURE [IF NOT EXISTS]
    procedure_name ( [ procedure_parameter [, ...] ] )
    [ characteristic [...] ]
    AS compound_statement

procedure_parameter
    [ IN | OUT | INOUT ] parameter_name data_type
    [ DEFAULT default_expression ] [ COMMENT parameter_comment ]

characteristic
  { LANGUAGE SQL |
    SQL SECURITY { INVOKER | DEFINER } |
    NOT DETERMINISTIC |
    COMMENT procedure_comment |
    DEFAULT COLLATION default_collation_name |
    MODIFIES SQL DATA }

パラメーター

  • または置換する

    指定した場合、同じ名前のプロシージャが置き換えられます。 既存の関数をプロシージャに置き換えることはできません。これにより 、ROUTINE_ALREADY_EXISTSが発生します。 IF NOT EXISTSでこのパラメーターを指定することはできません。両方を指定すると、INVALID_SQL_SYNTAXが発生します。CREATE_ROUTINE_WITH_IF_NOT_EXISTS_AND_REPLACE

  • 存在しない場合

    指定した場合は、その名前のプロシージャがまだ存在しない場合にのみ、プロシージャを作成します。 同じ名前のプロシージャが存在する場合、ステートメントは無視されます。 OR REPLACEでこのパラメーターを指定することはできません。両方を指定すると、INVALID_SQL_SYNTAXが発生します。CREATE_ROUTINE_WITH_IF_NOT_EXISTS_AND_REPLACE

  • procedure_name

    プロシージャの名前。 必要に応じて、プロシージャ名をスキーマ名で修飾できます。 名前が修飾されていない場合は、永続的なプロシージャが現在のスキーマに作成されます。

    プロシージャ名は、スキーマ内のすべてのルーチン (プロシージャと関数) で一意である必要があります。 同じ名前のルーチンが存在し、OR REPLACEIF NOT EXISTSも指定されていない場合、Azure DatabricksはROUTINE_ALREADY_EXISTSを発生させます。

  • procedure_parameter

    プロシージャのパラメーターを指定します。

    • parameter_name

      パラメーター名はプロシージャ内で一意である必要があります。それ以外の場合Azure Databricks DUPLICATE_ROUTINE_PARAMETER_NAMESが発生します。

    • ININOUT、または OUT

      必要に応じて、パラメーターのモードを記述します。

      • 入力のみのパラメーターを定義します。 これが既定値です。

      • INOUT

        入力/出力引数を受け取るパラメーターを定義します。 プロシージャが未処理のエラーなしで完了すると、最終的なパラメーター値が出力として返されます。

      • アウト

        出力パラメーターを定義します。 パラメーターは NULL に初期化され、プロシージャが未処理のエラーなしで完了すると、最終的なパラメーター値が出力として返されます。

    • データ型

      サポートされるすべてのデータ型。

    • DEFAULT default_expression

      関数呼び出しでパラメーターに引数が割り当てられない場合に使用される省略可能な既定値。 default_expressiondata_typeでなければなりません。 この式は、別のパラメーターを参照したり、サブクエリを含めたりすることはできません。

      あるパラメーターに既定値を指定すると、以降のすべてのパラメーターにも既定値が必要になります。

      DEFAULT は、 OUT または INOUT パラメーターではサポートされていません。1 つを指定すると 、PROCEDURE_CREATION_PARAMETER_OUT_INOUT_WITH_DEFAULTが発生します。

    • COMMENT コメント

      パラメーターの説明 (省略可能)。 comment は、STRING リテラルにする必要があります。

  • 複合文

    SQL プロシージャの定義を含む SQL 複合ステートメント (BEGIN ... END)。

    プロシージャが作成されると、構文の正確性が検証されます。 プロシージャ本体は、プロシージャが呼び出されるまでセマンティックの正確性を検証しません。

  • 特性

    SQL SECURITY INVOKERまたはSQL SECURITY DEFINERのいずれか、およびLANGUAGE SQLが必要です。 その他はすべて省略可能です。 任意の順序で任意の数の特性を指定できますが、各句は 1 回だけ指定できます。

    • LANGUAGE SQL

      関数実装の言語。

    • SQL SECURITY INVOKER

      プロシージャーの本体内のすべての SQL ステートメントを、プロシージャーを呼び出すユーザーの権限の下で実行することを指定します。

      プロシージャの本体内でリレーションとルーチンを解決する場合、Azure Databricksは、呼び出し時に現在のカタログと現在のスキーマを使用します。

      承認されたユーザーとセッション・ユーザーがプロシージャー本体内および入れ子になった呼び出し全体でどのように動作するかについては、許可されたユーザーとセッション・ユーザーを参照してください。

    • SQL SECURITY DEFINER

      適用対象: チェック マークあり Databricks SQL

      プロシージャを呼び出すユーザーに関係なく、プロシージャの本体内のすべての SQL ステートメントが、プロシージャの所有者 (定義者) の権限の下で常に実行されるように指定します。 つまり、所有者は本文の 承認されたユーザー です。 呼び出し側は、プロシージャに対する EXECUTE 特権のみを必要とします。本文から参照されるリレーション、ルーチン、およびその他のオブジェクトに対するすべてのアクセス チェックは、承認されたユーザーに対して評価されます。

      プロシージャの本体内でリレーションとルーチンを解決する場合、Azure Databricksは、プロシージャの作成時に最新のカタログとスキーマを使用します。 呼び出し側のセッション スコープ オブジェクト (一時ビュー、一時テーブル、セッション変数、セッション スコープ関数など) は、本文内の解決検索パスから除外されるため、修飾されていない名前で参照することはできません。 session.object_namesystem.session.object_nameなど、session スキーマ修飾子を使用して参照されている場合は、アクセス可能なままです。

      本文のステートメントのセマンティクスに影響を与える SQL 構成 ( ANSI_MODE や既定のタイム ゾーンなど) も作成時にキャプチャされ、呼び出し側のセッション設定に関係なく、プロシージャの呼び出しごとに使用されます。

      SQL SECURITY DEFINER本文内で、current_catalogはプロシージャの作成時に現在のカタログを返し、current_schemaして、プロシージャの作成時に現在のスキーマを返current_database。

      SQL SECURITY DEFINER では 、session_userの値は変更されません。 CALLを発行したユーザーは引き続き返されます。 承認されたユーザーとセッション ユーザーSQL SECURITY DEFINER本文内でどのように異なるかについては、「承認されたユーザーとセッション ユーザー」を参照してください。

    • 非決定性

      プロシージャは非決定的であると見なされます。つまり、同じ引数で呼び出された場合でも、呼び出しごとに異なる結果を返すことができます。

    • コメント procedure_comment

      手順に対するコメント。 procedure_commentSTRING リテラルである必要があります。 既定値は NULLです。

    • デフォルトの照合順序 default_collation_name

      適用対象:はい Databricks SQL チェックが Databricks Runtime 17.1 以降" とマークされているチェック

      プロシージャの既定の照合順序を設定します。 プロシージャの既定の照合順序は、プロシージャ パラメーターの既定の照合順序、パラメーターの式 DEFAULT 、プロシージャ本体で宣言 STRING 型指定されたローカル変数、およびプロシージャ本体で使用されるリテラル STRING 使用されます。

      Databricks Runtime 17.1 から Databricks Runtime 18.2 では、 default_collation_nameUTF8_BINARYする必要があります。 プロシージャが作成されるスキーマに UTF8_BINARY以外の既定の照合順序がある場合、この句は必須です。

      適用対象:はい Databricks SQL チェックが Databricks Runtime 18 以降" とマークされているチェック

      default_collation_name には、サポートされている 任意の照合順序名を指定できます。

      指定しない場合、既定の照合順序は、プロシージャが作成されるスキーマから派生します。

    • SQL データを変更します

      プロシージャは SQL データを変更することを前提としています。

一般的なエラー状態

例示

-- Demonstrate INOUT and OUT parameter usage.
> CREATE OR REPLACE PROCEDURE add(x INT, y INT, OUT sum INT, INOUT total INT)
    LANGUAGE SQL
    SQL SECURITY INVOKER
    COMMENT 'Add two numbers'
    AS BEGIN
        SET sum = x + y;
        SET total = total + sum;
    END;
> DECLARE sum INT;
> DECLARE total INT DEFAULT 0;
> CALL add(1, 2, sum, total);
> SELECT sum, total;
 3 3
> CALL add(3, 4, sum, total);
 7 10

-- The last executed query is the result set of a procedure
> CREATE PROCEDURE greeting(IN mode STRING COMMENT 'informal or formal')
    LANGUAGE SQL
    SQL SECURITY INVOKER
    AS BEGIN
        SELECT 'Hello!';
        CASE mode WHEN 'informal' THEN SELECT 'Hi!';
                  WHEN 'formal' THEN SELECT 'Pleased to meet you.';
        END CASE;
    END;
> CALL greeting('informal');
  Hi!

> CALL greeting('formal');
  Pleased to meet you.

> CALL greeting('casual');
  Hello!

-- Use SQL SECURITY DEFINER so the procedure runs with the owner's privileges
-- and references its creation-time catalog and schema. The invoker only needs
-- EXECUTE on `audit_app.ops.log_event`; they do not need any privileges on the
-- underlying `audit_app.private.audit_log` table.
> USE CATALOG audit_app;
> USE SCHEMA ops;
> CREATE OR REPLACE PROCEDURE log_event(IN event STRING)
    LANGUAGE SQL
    SQL SECURITY DEFINER
    MODIFIES SQL DATA
    AS BEGIN
        INSERT INTO audit_app.private.audit_log
          VALUES (current_user(), current_catalog(), current_schema(), event);
    END;

-- Even when invoked from a different catalog/schema and by a different user,
-- the body still inserts into `audit_app.private.audit_log`, with
-- `current_catalog()` and `current_schema()` returning the values frozen at
-- creation time. `session_user()` is unaffected by `SQL SECURITY DEFINER`
-- and records the actual invoker -- which is what audit logs typically want.
> USE CATALOG sales;
> USE SCHEMA reports;
> CALL audit_app.ops.log_event('checkout_completed');