CREATE FUNCTION

CREATE FUNCTION ステートメントは、現行サーバーでユーザー定義関数を定義します。

定義できる関数のタイプは以下のとおりです。

  • 外部スカラー

    このタイプの関数は、C または Java™ などのプログラミング言語で書かれ、スカラー値を戻します。 この外部プログラムは、現行サーバーで定義されている関数により、その関数の各種属性に基づいて参照されます。CREATE FUNCTION (外部スカラー)を参照してください。

  • 外部表

    このタイプの関数は、C または Java などのプログラミング言語で書かれ、一組の行を戻します。 この外部プログラムは、現行サーバーで定義されている関数により、その関数の各種属性に基づいて参照されます。CREATE FUNCTION (外部表)を参照してください。

  • ソース化

    このタイプの関数は、既に現行サーバーに存在している他の関数 (組み込み、外部、ソース化、または SQL) を呼び出すことにより インプリメントされます。 ソース化関数は、スカラーの結果、または集約関数の結果を戻します。 CREATE FUNCTION (ソース派生)を参照してください。この関数は、基礎となって いるソース関数の属性を継承します。

  • SQL スカラー

    このタイプの関数は SQL のみで書かれるもので、スカラー値を戻します。 関数本体は、関数の各種属性と一緒に現行サーバーで定義されます。 CREATE FUNCTION (SQL スカラー)を参照してください。

  • SQL 表

    このタイプの関数は SQL のみで書かれるもので、一組の行を戻します。 関数本体は、関数の各種属性と一緒に現行サーバーで定義されます。 CREATE FUNCTION (SQL 表)を参照してください。

スキーマおよび関数名の選択: 修飾付き関数名を指定する場合は、スキーマ名 はシステム・スキーマ (スキーマを参照) のいずれかであってはなりません。関数名が修飾されていない場合、それはデフォルトのスキーマ名で暗黙的に修飾されます。

非修飾名は、区切り文字付き ID として指定される場合でも、 システム使用のために予約されている以下の名前のいずれかであってはなりません。

パラメーターの定義: 関数の入力パラメーターは括弧内のリストとして指定されます。

CREATE FUNCTION で許容されているパラメーターの最大数は 変更の始まり2000変更の終わり です。

関数には入力パラメーターがなくても構いません。 この場合は、次のように、中が空の 1 組の括弧をコーディングする必要があります。

    CREATE FUNCTION WOOFER()

関数の結果のデータ・タイプは、その関数の RETURNS 文節で指定されます。

  • パラメーターのデータ・タイプの選択: 関数の入力および結果パラメーターのデータ・タイプを選択する場合は、 それらのパラメーターの値に影響を与える可能性のあるプロモーションの規則を考慮する必要があります。データ・タイプのプロモーションを参照してください。例えば、関数の入力引数の 1 つである定数には、 その関数で予期していたデータ・タイプとは別の組み込みデータ・タイプが指定される場合があり、 さらに重要なことに、その定数は、予期されていたデータ・タイプにプロモートできない可能性があります。プロモーションの規則に従って、次のデータ・タイプを使用することをお勧めします。
    • SMALLINT に代わって INTEGER
    • REAL に代わって DOUBLE
    • CHAR に代わって VARCHAR
    • GRAPHIC に代わって VARGRAPHIC

    DB2® for i 以外のプラットフォーム間で関数を移植可能にするために、以下のデータ・タイプ名は使用しないでください。これらは、異なるプラットフォームでは表記が異なる場合があります。

    • FLOAT。この代わりに、DOUBLE や REAL を使用すること。
    • NUMERIC。この代わりに、DECIMAL を使用すること。
  • パラメーターに AS LOCATOR を指定する: 値の代わりにロケーターを渡すことにより、関数との間で受け渡しするバイト数を削減できることがあります。 これは、パラメーターの値が非常に大きい場合に便利です。 AS LOCATOR 文節は、実際の値の代わりにパラメーターの値へのロケーターを渡すことを指定します。 AS LOCATOR を指定するのは、LOB データ・タイプまたは XML データ・タイプ、あるいは LOB データ・タイプまたは XML データ・タイプに基づく特殊タイプのパラメーターに対してのみであり、しかも、LANGUAGE JAVA が有効になっていない場合に限られます。

    AS LOCATOR 文節によって、データ・タイプがプロモート可能かどうかの 決定が影響を受けることも、関数解決に使用される関数シグニチャーが影響 を受けることもありません。

    SQL 関数には、AS LOCATOR は指定できません。

スキーマ内で関数の固有性を判別する: それぞれの関数の関数シグニチャーが固有であれば、 スキーマ内で複数の関数に同じ名前を指定することができます。 関数シグニチャーは、入力パラメーターの数およびデータ・タイプと結合された修飾関数名です。 名前、スキーマ名、パラメーターの数、およびそれぞれのパラメーターのデータ・タイプ (データ・タイプの長さ、 精度、位取り、または CCSID といった他の属性に関係なく) の組み合わせで、 現行サーバー上に存在しているユーザー定義の関数を識別してはなりません。 戻りタイプは、関数の固有性の判別に影響しません。 異なる 2 つのスキーマのそれぞれに、それらに対応しているすべてのデータ・タイプに 同じデータ・タイプが指定されている同じ名前の 1 つの関数を入れることができるということです。 ただし、それらに対応しているすべてのデータ・タイプに、同じ データ・タイプが指定されている同じ名前の関数を 2 つ入れることはできません。

対応しているデータ・タイプが一致しているか否かの判別時に、データベース・マネージャーは、 比較において、長さ、精度、または位取りの属性はどれも考慮に入れません。 データベース・マネージャーは、データ・タイプの同義語を一致と見なします。 例えば、REAL と FLOAT、ならびに DOUBLE と FLOAT を一致と見なします。 したがって、CHAR(8) と CHAR(35) は同じであると見なされ、同様に、 DECIMAL(11,2) と DECIMAL(4,3) は同じであると見なされます。 さらに、文字タイプとグラフィック・タイプは同じであると見なされます。 例えば、以下は同じタイプであると見なされます。 CHAR と GRAPHIC、VARCHAR と VARGRAPHIC、および CLOB と DBCLOB。 CHAR(13) と GRAPHIC(8) は同じタイプであると見なされます。 作成中の関数のシグニチャーが、 同じ名前とスキーマを持つ既存のユーザー定義関数のシグニチャーと重複している場合、エラーが戻されます。

次のステートメントを実行して、同じスキーマ内に 4 つの関数を作成すると想定します。 2 番目と 4 番目のステートメントは、1 番目と 3 番目のステートメントが作成した関数と重複している関数を作成するので失敗します。

CREATE FUNCTION PART (INT, CHAR(15) ...
CREATE FUNCTION PART (INTEGER, CHAR(40) ...

CREATE FUNCTION ANGLE (DECIMAL(12,2)) ...
CREATE FUNCTION ANGLE (DEC(10,7)) ...

関数に特定の名前を指定する: 名前もスキーマも同じである (ただしパラメーター・リストは異なる) 複数の関数を定義するときは、 特定名も指定することをお勧めします。 関数のソース化、除去、または関数へのコメントの付加を行うときに、 特定名を使用して、その関数を一意的に識別することができます。 ただし、この関数をその特定名で呼び出すことはできません。

この特定名は、暗黙的または明示的にスキーマ名で修飾されます。 CREATE FUNCTION でスキーマ名が指定されていない場合、 特定名は関数名 (関数名 ) の明示的または暗黙的なスキーマ名と同じ名前になります。 スキーマ名が指定されている場合、 特定名は関数名の明示的または暗黙的なスキーマ名と同じにしなければなりません。 スキーマ名も含め、この名前は、別のプロシージャーや現行サーバーに存在しているプロシージャーの特定名を示すものであってはなりません。

特定名を指定しなかった場合、その特定名は、関数名に設定されます。 この特定名の関数やプロシージャーが既に存在している場合は、固有表名 の生成に使用される規則にほぼ準拠した固有名が生成されます。

組み込み関数の拡張またはオーバーライド:

組み込み関数の拡張またはオーバーライドが必要な場合を除き、ユーザー定義の関数に組み込み関数と同じ名前を付けることはお勧めできません。

  • 既存の組み込み関数の機能の拡張:

    組み込み関数と同じ名前の新しいユーザー定義の関数と、固有の 関数シグニチャーを作成します。 例えば、組み込み数値タイプの代わりに特殊タイプ MONEY を入力として 受け入れる、組み込み関数 ROUND に似たユーザー定義の関数が必要になった とします。 この場合、ROUND という名前の新しいユーザー定義関数のシグニチャー は、組み込み関数 ROUND がサポートするどの関数シグニチャーとも異なるも のになります。

  • 組み込み関数をオーバーライドする:

    既存の組み込み関数のいずれかと名前もシグニチャーも同じである新しい ユーザー定義の関数を作成します。 この新しい関数は、その組み込み関数の対応するパラメーターと同じ名前 およびデータ・タイプを持ちますが、インプリメントされるロジックが異なります。 例えば、組み込み関数 ROUND に類似しているが、丸めの規則が異なる ユーザー定義の関数が必要になったとします。 この場合、ROUND という名前の新しいユーザー定義関数の シグニチャーは、組み込み関数 ROUND がサポートするシグニチャーの どれかと同じになります。

    組み込み関数をオーバーライドした後に、SQL パスの中で新しい関数のスキーマがシステム・スキーマの前に表示されると、データベース・マネージャーは、組み込み関数ではなくユーザー定義関数を選択する可能性があります。非修飾関数名を使用しているアプリケーションが、前回はその名前の組み込み関数を使用して正常に実行されたのに、今回は失敗するという状況が生じることがあります。さらに事態が悪化すると、一見して正常に実行されたように見えるのに、実際には、データベース・マネージャーがその組み込み関数ではなくユーザー定義の関数の方を選択したため、意図しない結果が生じるという状況が発生することもあります。

    組み込み集約関数をソースにしたユーザー定義関数の呼び出し時に DISTINCT キーワードを渡すこともできます。例えば、組み込みの AVG 関数をソースにした MY_AVG というユーザー定義関数があるとします。そのユーザー定義関数を MY_AVG (DISTINCT expression) で呼び出すことも可能です。 その場合は、基礎になっている組み込みの AVG 関数が DISTINCT キーワードで呼び出されることになります。

関数内の特殊レジスター: 呼び出し側の特殊レジスターの設定値は呼び出し時に関数によって継承され、 呼び出し側への戻りにおいてリストアされます。 SQL ステートメントを実行できる関数内で特殊レジスターが変更されることもありますが、それらの変更は呼び出し元には影響しません。

セキュア関数の作成: DB2 は SECURED 属性を、ユーザー定義関数に対するすべての変更の監査手順をユーザーが確立したことを宣言するアサーションとして扱います。DB2 は、そのような監査制御手順が後続の すべての ALTER FUNCTION ステートメントに対して確立していると想定します。

セキュアな関数内での他のユーザー定義関数の 呼び出し: 行アクセス制御または列アクセス制御を使用している 表を参照する SQL ステートメント内で、セキュアなユーザー定義関数が参照されていて、 そのセキュアなユーザー定義関数が他のユーザー定義関数を呼び出す場合、ネストされたユーザー定義関数はセキュアであるとは判定 されません。それらのネストされた関数 が機密データにアクセスする可能性がある場合、セキュリティー管理者権限を 持つ認可されたユーザーは、それらの関数がそのデータにアクセスすることを許可されていること、および、それらの関数に加えられるすべての変更に関して変更管理監査手順 が確立されていることを確認する必要があります。

MODIFIES SQL DATA および EXTERNAL ACTION 関数: MODIFIES SQL DATA または EXTERNAL ACTION 関数が最外部の選択リスト以外で呼び出されると、使用されるアクセス・プランによって関数を呼び出す回数が変わるため、結果は予測できません。

関数および借用権限: 隔離される関数は、分離スレッドで実行 します。NOT FENCED 関数 (隔離されない関数) に対して ALLOW PARALLEL が指定される場合、ALLOW PARALLEL 関数も分離スレッド で実行する可能性があります。分離スレッドで実行する関数は、呼び出し側アプリケーションによって 指定されることのある借用権限の下では実行しません。

リストアの考慮事項: 関数に関連するプログラム またはサービス・プログラムが保管された後でリストアされ、 オブジェクトが関数作成時に関数属性で更新されていた場合、 保管されていた属性がリストア中に処理され、変更される可能性が あります。

プログラムまたは サービス・プログラムの「保管されたライブラリー」(SAVLIB) が 「復元先ライブラリー」(RSTLIB) と異なる場合、関数のスキーマ名、固有スキーマ名、 および外部名は、リストアの結果として変更される可能性があります。
  • 保管された関数スキーマ名と保管されたオブジェクトのライブラリー名が一致する場合、 関数スキーマは「復元先ライブラリー」(RSTLIB) に変更されます。それ以外の場合、関数スキーマ名 は、保管された関数スキーマ名です。
  • 固有スキーマ名は、常に関数スキーマ名と同じです。
  • 保管された EXTERNAL NAME ライブラリーと保管されたオブジェクトのライブラリー名 が一致する場合、EXTERNAL NAME ライブラリーは 「復元先ライブラリー」(RSTLIB) に変更されます。それ以外の場合、EXTERNAL NAME ライブラリー は、保管されたライブラリー名です。保管された EXTERNAL NAME ライブラリーが *LIBL の 場合は、変更されません。
同じ関数シグニチャーがカタログ内に既に存在する場合:
  • 外部プログラム名またはサービス・プログラム名が、カタログ内に既に存在する名前と 同じである場合、そのプロシージャーについてのカタログ内の情報は、保管 された属性 (固有名を含む) で置換されます。
  • それ以外の場合、保管された属性はリストアされず、 警告 (SQL9015) が発行されます。

同じ固有名が 既にカタログ内に存在する場合、警告が発行され、新しい固有名が生成されます。 それ以外の場合、関数の固有名が保持されます。