呼び出し元権限と所有者権限のストアドプロシージャについて¶

呼び出し元権限のプロシージャのセッション変数¶

MyProcedure という名前のストアドプロシージャが、セッションレベルの変数を読み取って設定する SQL ステートメントを実行するとします。この例では、読み取りコマンドと設定コマンドの詳細は重要ではないため、ステートメントは擬似コードとして表されます。

• READ SESSION_VAR1

• SET SESSION_VAR2

ストアドプロシージャは、次の擬似コードに似ています。

CREATE PROCEDURE MyProcedure()
...
$$
   READ SESSION_VAR1;
   SET SESSION_VAR2;
$$
;

同じセッションで次の一連のステートメントを実行するとします。

SET SESSION_VAR1 = 'some interesting value';
CALL MyProcedure();
SELECT *
  FROM table1
  WHERE column1 = $SESSION_VAR2;

これは、次のシーケンスを実行するのと同じです。

SET SESSION_VAR1 = 'some interesting value';
READ SESSION_VAR1;
SET SESSION_VAR2;
SELECT *
  FROM table1
  WHERE column1 = $SESSION_VAR2;

つまり、

• ストアドプロシージャは、プロシージャが呼び出される前にステートメントによって設定された変数を見ることができます。

• ストアドプロシージャの後のステートメントは、プロシージャ内で設定された変数を見ることができます。

疑似コードに依存しない完全な例については、 呼び出し元権限と所有者権限のストアドプロシージャでのセッション変数の使用 （このトピック内）をご参照ください。

多くのストアドプロシージャでは、現在のデータベースや現在のセッションレベル変数などのコンテキスト情報を継承する必要があります。

ただし、状況に応じて、ストアドプロシージャをさらに分離する場合があります。例えば、ストアドプロシージャがセッションレベルの変数を設定する場合、セッションレベルの変数がストアドプロシージャ外の将来のステートメントに影響を与えないようにする場合があります。

ストアドプロシージャを残りのセッションからより適切に分離するには：

• セッションレベルの変数を直接使用しないでください。代わりに、それらを明示的なパラメーターとして渡します。これにより、呼び出し元は、ストアドプロシージャが使用するセッションレベルの変数を正しく考えるようになります。

• ストアドプロシージャ内で設定したセッションレベルの変数をクリーンアップします（他の場所で使用される可能性が低い名前を使用。そうすると、ストアドプロシージャの呼び出し前に存在するセッション変数を誤ってクリーンアップする恐れがない）。

次のストアドプロシージャは、セッション変数を直接使用するのではなく、パラメータとしてセッション変数の値を使用します。

SET Variable_1 = 49;

CREATE PROCEDURE sv_proc2(PARAMETER_1 FLOAT)
  RETURNS VARCHAR
  LANGUAGE JAVASCRIPT
  AS
  $$
    var rs = snowflake.execute( {sqlText: "SELECT 2 * " + PARAMETER_1} );
    rs.next();
    var MyString = rs.getColumnValue(1);
    return MyString;
  $$
  ;

CALL sv_proc2($Variable_1);

次のストアドプロシージャは、通常とは異なる名前で一時的なセッション変数を作成し、ストアドプロシージャが終了する前にその変数をクリーンアップします。プロシージャ呼び出しの後のステートメントが、クリーンアップされたセッション変数を使用しようとすると、そのステートメントは失敗します。

CREATE PROCEDURE sv_proc1()
  RETURNS VARCHAR
  LANGUAGE JAVASCRIPT
  EXECUTE AS CALLER
  AS
  $$
    var rs = snowflake.execute( {sqlText: "SET SESSION_VAR_ZYXW = 51"} );

    var rs = snowflake.execute( {sqlText: "SELECT 2 * $SESSION_VAR_ZYXW"} );
    rs.next();
    var MyString = rs.getColumnValue(1);

    rs = snowflake.execute( {sqlText: "UNSET SESSION_VAR_ZYXW"} );

    return MyString;
  $$
  ;

CALL sv_proc1();

-- This fails because SESSION_VAR_ZYXW is no longer defined.
SELECT $SESSION_VAR_ZYXW;

所有権権限のプロシージャのセッション変数¶

ストアドプロシージャは、ストアドプロシージャの外部で作成された SQL 変数 にアクセスできません。この制限により、あるユーザーが作成または所有するストアドプロシージャが、別のユーザー（ストアドプロシージャ呼び出し元）によって作成された SQL 変数を読み取れないようにします。

ストアドプロシージャが、現在のセッションの SQL 変数に保存されている値を必要とする場合、それらの変数の値は、ストアドプロシージャに明示的な引数として渡す必要があります。例:

SET PROVINCE = 'Manitoba';
CALL MyProcedure($PROVINCE);

所有者権限のプロシージャに対する呼び出し元のセッションパラメーターの影響について¶

セッション パラメーター の値は、コマンドと関数の動作に影響を与える可能性があります。たとえば、日付値を出力するコマンドは、 DATE_OUTPUT_FORMAT セッションパラメーターで指定された形式を使用します。

呼び出し元のセッションでは、呼び出し元がセッションパラメーターを設定または上書きできます。呼び出し元権限のストアドプロシージャでは、セッションパラメーターは、プロシージャ内で実行されるすべてのクエリおよび式の実行に影響を与える可能性があります。たとえば、 TIMESTAMP_OUTPUT_FORMAT パラメーター、 select current_timestamp::string などの子クエリの出力形式に影響します。

ただし、所有者権限のストアドプロシージャの場合、呼び出し元のセッションからの値は、次のパラメーターに対して のみ 使用されます。

• AUTOCOMMIT

• BINARY_INPUT_FORMAT

• BINARY_OUTPUT_FORMAT

• DATE_INPUT_FORMAT

• DATE_OUTPUT_FORMAT

• ENABLE_UNLOAD_PHYSICAL_TYPE_OPTIMIZATION

• ERROR_ON_NONDETERMINISTIC_MERGE

• ERROR_ON_NONDETERMINISTIC_UPDATE

• JDBC_TREAT_DECIMAL_AS_INT

• JSON_INDENT

• LOCK_TIMEOUT

• MAX_CONCURRENCY_LEVEL

• ODBC_USE_CUSTOM_SQL_DATA_TYPES

• PERIODIC_DATA_REKEYING

• QUERY_TAG

• QUERY_WAREHOUSE_NAME

• ROWS_PER_RESULTSET

• STATEMENT_QUEUED_TIMEOUT_IN_SECONDS

• STATEMENT_TIMEOUT_IN_SECONDS

• STRICT_JSON_OUTPUT

• TIMESTAMP_DAY_IS_ALWAYS_24H

• TIMESTAMP_INPUT_FORMAT

• TIMESTAMP_LTZ_OUTPUT_FORMAT

• TIMESTAMP_NTZ_OUTPUT_FORMAT

• TIMESTAMP_OUTPUT_FORMAT

• TIMESTAMP_TYPE_MAPPING

• TIMESTAMP_TZ_OUTPUT_FORMAT

• TIMEZONE

• TIME_INPUT_FORMAT

• TIME_OUTPUT_FORMAT

• TRANSACTION_ABORT_ON_ERROR

• TRANSACTION_DEFAULT_ISOLATION_LEVEL

• TWO_DIGIT_CENTURY_START

• UNSUPPORTED_DDL_ACTION

• USE_CACHED_RESULT

• WEEK_OF_YEAR_POLICY

• WEEK_START

その他 のパラメーター（上記以外）の場合、

• 所有者のアカウントレベルのパラメーター値が使用されます。

• アカウントレベルのパラメーターが所有者のアカウントに設定されていない場合、ストアドプロシージャはアカウントパラメーターの既定値を使用します。

この制限は、所有者権限のストアドプロシージャが呼び出し元のセッションパラメーター使用した場合に発生する可能性がある、潜在的な問題を回避するために設けられています。例:

• ストアドプロシージャの作成者（所有者）が特定のセッションパラメーターを設定しているが、ストアドプロシージャの呼び出し元がそのパラメーターを設定していない場合に、ストアドプロシージャが作成者以外のユーザーから呼び出されると、失敗するか異なる動作をする可能性があります。

• ストアドプロシージャが、呼び出し元により設定された任意のセッションパラメーターの使用を許可されている場合、ストアドプロシージャの所有者は、呼び出し元に気付かれることなくこれらの設定された値を識別できる可能性があります。

組み込み関数の制限¶

ストアドプロシージャが所有者権限のストアドプロシージャとして作成されている場合、呼び出し元（所有者を除く）は、次の組み込み関数を呼び出すことはできません。

• GET_DDL()

  これにより、ストアドプロシージャの所有者以外のユーザーは、ストアドプロシージャのソースコードを表示できなくなります。

• SYSTEM$ENABLE_BEHAVIOR_CHANGE_BUNDLE()

• SYSTEM$DISABLE_BEHAVIOR_CHANGE_BUNDLE()

ALTER USER¶

次の制限は、所有者権限ストアドプロシージャの ALTER USER ステートメントに適用されます。

• 所有者権限ストアドプロシージャは、セッションで現在のユーザーを 暗黙的 に使用する ALTER USER ステートメントを実行できません。（しかし、所有者権限ストアドプロシージャは、ユーザーが現在のユーザーでない限り、ユーザーを 明示的 に識別する ALTER USER ステートメントを実行できます。）

実行時のストアドプロシージャの監視¶

所有者権限ストアドプロシージャの所有者にも呼び出し元にも、ストアドプロシージャの実行をモニターする権限があるとは限りません。

WAREHOUSE MONITOR 権限を持つユーザーは、そのストアドプロシージャ内の個々のウェアハウス関連の SQL ステートメントの実行を監視できます。ほとんどのクエリと DML ステートメントは、ウェアハウス関連のステートメントです。 CREATE、 ALTER などの DDL ステートメントはウェアハウスを使用しないため、ストアドプロシージャのモニターの一部としてはモニターできません。

SHOW および DESCRIBE コマンド¶

所有者権限ストアドプロシージャには、呼び出し元以外のユーザーに関する情報を読み取るための十分な権限がありません。たとえば、 SHOW USERS LIKE <現在のユーザー> を実行すると現在のユーザーに関する情報が表示されますが、現在のユーザーが唯一のユーザーでない限り、より一般的な SHOW USERS は機能しません。

次の SHOW コマンドが 許可されています 。

• SHOW DATABASES。

• SHOW SCHEMAS。

• SHOW WAREHOUSES。

SQL ステートメントの制限¶

呼び出し元権限のストアドプロシージャは、ストアドプロシージャの外部で実行するために十分な権限を持っている SQL ステートメントを実行できますが、所有者権限のストアドプロシージャは SQL ステートメントのサブセットのみを呼び出すことができます。

次の SQL ステートメントは、所有者の権限のストアドプロシージャ内から呼び出すことが できます。

• SELECT。

• DML

• DDL（ALTER USER ステートメントの制限については上記を参照。）

• GRANT/REVOKE

• 変数の割り当て。

• DESCRIBE および SHOW。（上記の制限を参照。）

他の SQL ステートメントは、所有者の権限のストアドプロシージャ内から呼び出すことはできません。