関数

関数 とは、特定の操作に名前、つまり関数名を付けたもので、関数名の後には括弧に囲まれた 1 つ以上のオペランドが続きます。

関数は入力値のセットと結果値のセットの関係を表します。 関数の入力値を引数 といいます。 例えば、TIMESTAMP 関数には DATE および TIME タイプの引数を渡すことができ、その結果が TIMESTAMP になります。

関数の分類にはいくつかの方法があります。

1 つの方法として、組み込み関数かユーザー定義関数のどちらかに分類できます。
  • 組み込み関数 とは、 データベース・マネージャーに用意されている関数です。 組み込み関数には、集約関数 (例えば AVG)、演算子関数 (例えば +)、キャスト関数 (例えば DECIMAL)、スカラー関数 (例えば CEILING)、 表関数 (例えば BASE_TABLE) などがあります。 組み込み関数は、一般的には「SYS」で始まるスキーマで定義されています (例えば、SYSIBM、SYSFUN、および SYSIBMADM) が、「DB2」で始まるスキーマで定義されているものもあります (例えば DB2MQ)。
  • ユーザー定義関数 は、SQL データ定義ステートメントを使用して作成され、カタログ内のデータベース・マネージャーに登録される関数です。 ユーザー定義スキーマ関数 は、CREATE FUNCTION ステートメントを使用して作成されます。ユーザー定義モジュール関数 は、ALTER MODULE ADD FUNCTION または ALTER MODULE PUBLISH FUNCTION ステートメントを使用して作成されます。 ユーザー定義モジュール関数 のセットは、SYSIBMADM というスキーマ内のモジュールのセットでデータベース・マネージャーに提供されます。 ユーザー定義関数 は、それが作成されたスキーマ内、またはそれが追加または公開されたモジュール内にあります。

    ユーザー定義関数は、 データベース・エンジンそのものにおいて適用できる関数定義 (ユーザーまたは第三者ベンダー作成の) を追加することで、 データベース・システムの機能を拡張することができます。 データベース関数が拡張されれば、 アプリケーションが使用するのと同じ関数をデータベースがエンジン内で活用することができ、 それによってアプリケーションとデータベースとの間の相互作用が強化されます。

ユーザー定義関数を分類するもう 1 つの方法は、外部関数、SQL 関数、ソース派生関数、またはインターフェース関数として分類することです。
  • 外部関数 は、オブジェクト・コード・ライブラリーへの参照と、関数呼び出し時に実行されるそのライブラリー内の関数によってデータベースに対して定義されます。 集約関数を外部関数にすることはできません。
  • SQL 関数は、SQL ステートメントだけ (最低 1 つの RETURN ステートメントを含む) を使用して、データベースに対して定義されます。 スカラー値、行、または表を戻すことができます。 SQL 関数を集約関数にすることはできません。
  • ソース派生関数 は、データベースが既に認識している別の組み込み関数またはユーザー定義関数への参照によって、データベースに対して定義されます。 ソース関数からの派生関数はスカラー関数または集約関数です。 これらは、ユーザー定義タイプの既存の関数のサポートに有用です。
  • インターフェース関数 は、データベースが既に認識しているいくつかのユーザー定義ルーチンへの参照を使用して、データベースに対して定義されます。 インターフェース関数になるのは、集約関数のみです。

関数の別の分類方法として、入力データ値と結果値によって、スカラー関数、集約関数、行関数、表関数に分類できます。 スカラー関数 は、呼び出されるたびに単一値の応答を戻す関数です。 例えば、組み込み関数 SUBSTR() はスカラー関数です。 スカラー UDF は、外部関数とソースからの派生関数のどちらであっても構いません。

集約関数 は、概念上、類似値の集合 (列) を渡され、単一値の応答を戻す関数です。 集約関数の例としては、組み込み関数 AVG () があります。 組み込み集約関数の 1 つをソースとする列 UDF を定義することができます。 これは、特殊タイプに対して有用です。 例えば、特殊タイプ SHOESIZE が基本タイプ INTEGER を使用して定義されている場合、 組み込み関数 AVG(INTEGER) をソースとする UDF AVG(SHOESIZE) を定義することができ、 これは集約関数になります。 複数のユーザー定義ルーチンをソースとする集約インターフェース関数を定義できます。

行関数 とは、値を一行で戻す関数です。 これは、行式がサポートされるコンテキストで使用できます。 また、構造化タイプの属性値を行の値にマップするトランスフォーム関数として使用することもできます。 行関数は、SQL 関数と定義する必要があります。

表関数 は、その関数を参照する SQL ステートメントに表を戻す関数です。 SELECT ステートメントの FROM 節でのみ参照することができます。 そのような関数を使用して、データベース内に所在しないデータに SQL 言語処理能力を適用したり、そのようなデータをデータベース内の表に変換したりすることができます。 表関数は、ファイルの読み取り、Web からのデータの取得、または Lotus Notes® データベースへのアクセスと結果表の戻しを行うことができます。 このような情報は、データベースの他の表と結合することができます。 表関数は、外部関数または SQL 関数と定義できます。 (表関数はソース関数であってはなりません。)

関数シグニチャー

スキーマ関数は、そのスキーマ名、関数名、パラメーター数、 およびそのパラメーターのデータ・タイプによって識別されます。 モジュール関数は、そのスキーマ名、関数名、パラメーター数、 およびそのパラメーターのデータ・タイプによって識別されます。 このスキーマ関数またはモジュール関数の識別は、関数シグニチャー と呼ばれ、データベース内で固有である必要があります。例: TEST.RISK(INTEGER)。 プロシージャーごとにパラメーターの数が違っていれば、 1 つのスキーマまたはモジュールに同じ名前のプロシージャーが複数存在しても構いません。 同じ数のパラメーターを持つ複数の関数インスタンスのある関数名は、多重定義 関数と呼ばれます。 ある関数名があるスキーマ内で多重定義される場合、そのスキーマには同じ数のパラメーターを持つその名前で 2 つ以上の関数があるということです。 同様に、ある関数名があるモジュール内で多重定義される場合、そのモジュールには同じ数のパラメーターを持つその名前で 2 つ以上の関数があるということです。 これらの関数は、それぞれ別々のパラメーター・データ・タイプをもっていなければなりません。 また関数は SQL パス内の複数のスキーマにおいても多重定義可能です。その場合、その SQL パス内の異なるスキーマに、同じ数のパラメーターを持つその名前の付いた関数が 2 つ以上あることになります。 必ずしもパラメーター・データ・タイプがそれぞれ異なっている必要はありません。

関数の呼び出し

関数への各参照は、以下の構文に準拠します。

Read syntax diagramSkip visual syntax diagramfunction-name( 1ALLDISTINCT ,argument )
argument
Read syntax diagramSkip visual syntax diagramparameter-name=>expressionrow-expressionDEFAULT
Notes:
  • 1 The ALL or DISTINCT keyword can be specified for certain built-in aggregate functions or a user-defined function that is sourced on certain built-in aggregate functions. The ALL keyword can be specified for an aggregate interface function.

前述の構文の、 expression および row-expression に、集約関数を含めることはできません。 expressionに関する他の規則については、『』を参照してください。

関数を呼び出すには、後に括弧に入った引数のリストの付いた修飾関数名または非修飾関数名を (使用可能なコンテキストで) 参照します。 関数名に可能な修飾子は次のとおりです。
  • スキーマ名
  • 非修飾モジュール名
  • スキーマによって修飾されたモジュール名
関数を呼び出す際に使用される修飾子によって、対応する関数の検索に使用される有効範囲が決まります。
  • スキーマ修飾されたモジュール名が修飾子として使用される場合、有効範囲は指定のモジュールになります。
  • 単一の ID が修飾子として使用される場合、有効範囲には以下が含まれます。
    • 修飾子と一致するスキーマ。
    • 以下のモジュールの 1 つ。
      • 呼び出しモジュール (呼び出しモジュールの名前が修飾子と一致する場合)。
      • 修飾子と一致する SQL パス内のスキーマにある最初のモジュール。
  • 有効範囲は、修飾子が使用されない場合には SQL パス内のスキーマとなり、関数がモジュール・オブジェクトの内部から呼び出される場合には関数の呼び出し元の同じモジュールになります。
静的 SQL ステートメントの場合、SQL パスは FUNCPATH バインド・オプションを使用して指定されます。 動的 SQL ステートメントの場合、 SQL パスは CURRENT PATH 特殊レジスターの値です。

関数が呼び出されたら、データベース・マネージャーは実行する関数を判別する必要があります。 このプロセスを関数解決 と言い、組み込み関数とユーザー定義関数の両方に適用されます。 関数呼び出しがユーザー定義関数を呼び出すことを意図している場合には、完全修飾するように推奨されています。 このようにすると関数解決のパフォーマンスが向上し、新しい関数が追加されたり、特権が付与されたりする際に予期しない関数解決の結果が生じてしまうのを避けられます。

引数 とは、呼び出し時に関数に渡される値、または DEFAULT で指定されるデフォルト値です。 SQL の中で呼び出されるとき、関数にはゼロ個以上の引数のリストが渡されます。 このような引数は、引数のセマンティクスが引数リスト内の位置によって決定されるという意味で定位置と言えます。 パラメーター は、関数への入力または関数からの出力の形式上の定義です。 データベースに対して内部的に (組み込み関数) またはユーザーによって (ユーザー定義関数) 関数が定義されるときは、 関数のパラメーターが (ゼロ個以上) 指定されます。 また、パラメーターの定義の順序によって、パラメーターの位置とセマンティクスが定義されることになります。 したがって、どのパラメーターも関数への特定の定位置入力または関数からの出力になります。 呼び出し時に、定位置構文かまたは名前付き構文を使用して引数がパラメーターに代入されます。 定位置構文を使用する場合、引数は引数リストにおける位置によって特定のパラメーターに対応します。 名前付き構文を使用する場合、引数はパラメーターの名前に基づいて特定のパラメーターに対応します。 名前付き構文を使用して、ある引数がパラメーターに代入される場合、それに続く引数もすべて名前付き構文を使用して代入される必要があります (SQLSTATE 4274K)。 名前付き引数の名前は、関数呼び出し 1 つにつき一度だけ使用できます (SQLSTATE 4274K)。 関数呼び出しの引数のデータ・タイプが、選択した関数のパラメーターのデータ・タイプと一致しない場合には、列への値の代入と同じ規則が適用され、引数は実行時にパラメーターのデータ・タイプに変換されます。 これには、引数とパラメーターの間で精度、位取り、または長さが異なる場合も含まれます。 関数呼び出しの引数が DEFAULT の指定である場合は、引数に使用される実際の値は、関数定義で対応パラメーターのデフォルトに指定された値になります。 パラメーターのデフォルト値が定義されていない場合は、NULL 値が使用されます。 型なし式 (パラメーター・マーカー、NULL キーワード、または DEFAULT キーワード) が引数として使用された場合、引数に関連付けられるデータ・タイプは、選択した関数のパラメーターのパラメーター・データ・タイプによって決まります。

スキーマ関数へのアクセスは、スキーマ関数における EXECUTE 特権を使って制御します。 関数を呼び出すステートメントの許可 ID に EXECUTE 特権がないと、このスキーマ関数は、たとえ一致の度合いが高くても、関数解決アルゴリズムによって考慮されません。 SYSIBM および SYSFUN スキーマの組み込み関数では、暗黙で PUBLIC に EXECUTE 特権が付与されます。

モジュール関数へのアクセスは、そのモジュール内のすべての関数に関して、そのモジュールにおける EXECUTE 特権を介して制御されます。 関数を呼び出すステートメントの許可 ID には、モジュールにおける EXECUTE 特権がない可能性があります。 そのよう場合、スキーマ関数とは異なり、そのモジュール内のモジュール関数は実行できない場合であっても関数解決アルゴリズムによって引き続き考慮されます。

ユーザー定義関数が呼び出される際、その引数のそれぞれの値が、ストレージ代入を使用して、関数の対応するパラメーターに代入されます。 ホスト言語の呼び出し規則に応じて、制御が外部関数に渡されます。 ユーザー定義スカラー関数またはユーザー定義集約関数の実行が完了すると、関数の結果がストレージ代入を使用して、結果のデータ・タイプに代入されます。 代入規則についての詳細は、『代入と比較』を参照してください。

表関数を参照できるのは、副選択の FROM 節でのみです。 表関数の参照について詳しくは、 表参照を参照してください。

関数解決

関数が呼び出されたら、データベース・マネージャーは実行する関数を判別する必要があります。 このプロセスを関数解決と言い、組み込み関数とユーザー定義関数の両方に適用されます。

データベース・マネージャーはまず、以下の情報に基づいて、候補関数のセットを判別します。
  • 呼び出される関数の名前の修飾
  • 関数を呼び出しているコンテキスト
  • 呼び出される関数の非修飾名
  • 指定された引数の数
  • 指定された引数の名前
  • スキーマ関数の許可
詳しくは、 候補関数のセットの決定 を参照してください。

次にデータベース・マネージャーは、呼び出される関数の引数のデータ・タイプと、候補関数のセットに含まれる関数のパラメーターのデータ・タイプを比較し、その結果に基づいて候補関数のセットから最適な関数を判別します。 SQL パスとパラメーター数も考慮されます。 詳しくは、「 最適なものを決定する 」を参照してください。

関数が選択されても、以下のいずれかの理由でエラーが戻される可能性があります。
  • モジュール関数が選択され、その関数がモジュール外から呼び出される場合、または関数がモジュール・オブジェクト内部から呼び出され、修飾子がコンテキスト・モジュール名と一致しない場合、関数を呼び出したステートメントの許可 ID は、選択された関数が含まれるモジュールにおける EXECUTE 特権がなければなりません (SQLSTATE 42501)。
  • 関数が選択された場合、正常に使用されるかどうかは、その関数が、戻される結果が許可されるコンテキストにおいて呼び出されるかどうかによって決まります。 例えば、関数が表を戻したものの、そこでは表が許可されていない場合、エラーが戻されます (SQLSTATE 42887)。
  • 組み込みであれユーザー定義であれ cast 関数が選択されたとき、いずれかの引数をパラメーターのより小さなデータ・タイプに暗黙的にキャスト (プロモートでなく) する必要がある場合は、エラーが戻されます (SQLSTATE 42884)。
  • 関数呼び出しに名前のない行タイプを持つ引数が関係する場合、以下のいずれかの条件が発生すると、エラーが戻されます (SQLSTATE 42884)。
    • 引数のフィールド数がパラメーターのフィールド数と一致しない。
    • 引数のフィールドのデータ・タイプを、パラメーターのフィールドの対応するデータ・タイプに割り当てることができない。

一群の候補関数の判別

  • 関数呼び出しの引数の数を A とします。
  • 関数シグニチャー中のパラメーターの数を P とします。
  • 関数シグニチャーでデフォルトが定義されていないパラメーターの数を N とします。
関数呼び出しを解決するための候補関数は、以下の基準で選択されます。
  • 各候補関数は、一致する名前と適用可能なパラメーター数を持つ。 適用可能なパラメーター数とは、NAP という条件を満たすパラメーター数のことです。
  • 各候補関数には、関数呼び出しに含まれる名前付き引数ごとに、名前は一致するが定位置 (名前なし) 引数にはまだ合致していないパラメーターが存在する。
  • 候補関数のパラメーターのうち、対応引数が関数呼び出しで位置でも名前でも指定されていない各パラメーターは、デフォルトを使用して定義される。
  • 1 つ以上のスキーマの集合に含まれる各候補関数は、関数を呼び出しているステートメントの許可 ID に関連付けられた EXECUTE 特権を持つ。
  • コンテキスト・モジュール以外のモジュールに含まれる各候補関数は、パブリッシュ済みモジュール関数である。
一群の候補関数に選択される関数は、以下の検索スペースの 1 つ以上から選択されます。
  1. コンテキスト・モジュール。これは、関数を呼び出したモジュール・オブジェクトが含まれるモジュールです。
  2. 1 つ以上のスキーマの集合
  3. コンテキスト・モジュール以外のモジュール
考慮対象となる特定の検索スペースは、呼び出される関数の名前の修飾子によって影響を受けます。
  • 修飾された関数呼び出し: 関数名と修飾子を使用して関数が呼び出されると、データベース・マネージャーはその修飾子と、場合によっては、呼び出される関数のコンテキストも使用して、候補関数のセットを判別します。
    1. 関数が修飾子付きの関数名を使用してモジュール・オブジェクト内部から呼び出される場合、データベース・マネージャーはその修飾子がコンテキスト・モジュール名と一致するかどうかを考慮します。 修飾子が単一の修飾子である場合、一致の判定時にモジュールのスキーマ名は無視されます。 修飾子が 2 つの部分から成る ID の場合、突き合わせを考慮する際にスキーマによって修飾されたモジュール名と比較されます。 修飾子がコンテキスト・モジュール名と一致する場合、データベース・マネージャーはコンテキスト・モジュールで候補関数を検索します。

      コンテキスト・モジュールで 1 つ以上の候補関数が見つかると、最適を判別するためにこの一群の候補関数が処理され、その際にその他の検索スペースで可能性のある候補関数を考慮することはありません (『最適の判別』を参照してください)。 見つからなければ、次の検索スペースに進みます。

    2. 修飾子が単一の ID の場合、データベース・マネージャーはその修飾子をスキーマ名と見なしそのスキーマで候補関数を検索します。

      スキーマで 1 つ以上の候補関数が見つかると、最適を判別するためにこの一群の候補関数が処理され、その際にその他の検索スペースで可能性のある候補関数を考慮することはありません (『最適の判別』を参照してください)。 見つからなければ、該当する場合には次の検索スペースに進みます。

    3. 関数がモジュールの外部から呼び出される場合、またはモジュール・オブジェクト内部から呼び出される際に修飾子がコンテキスト・モジュール名と一致しない場合には、データベース・マネージャーはその修飾子をモジュール名と見なします。 データベース・マネージャーは、モジュールにおける EXECUTE 特権を考慮することなく、以下の基準に基づいて一致する最初のモジュールを選択します。
      • モジュール名がスキーマ名で修飾されている場合、そのスキーマ名とモジュール名のモジュールを選択します。
      • モジュール名がスキーマ名で修飾されていない場合、SQL パス内の最初のスキーマで見つかるモジュール名を持つモジュールを選択します。
      • モジュールが SQL パスを使用しても見つからない場合、そのモジュール名を持つモジュールのパブリック別名を選択します。
      一致するモジュールが見つからない場合、候補関数はありません。 一致するモジュールが見つかると、データベース・マネージャーは選択したモジュールで候補関数を検索します。

      選択されたモジュールで 1 つ以上の候補関数が見つかると、最適を判別するためにこの一群の候補関数が処理されます (『最適の判別』を参照してください)。

  • 修飾されていない関数呼び出し: 関数が修飾子なしで呼び出されると、データベース・マネージャーは呼び出される関数のコンテキストを考慮して、候補関数のセットを判別します。
    1. 関数が、モジュール・オブジェクト内部から非修飾の関数名で呼び出される場合、データベース・マネージャーはコンテキスト・モジュールで候補関数を検索します。

      コンテキスト・モジュールで 1 つ以上の候補関数が見つかると、SQL パス内のスキーマからの候補関数にこれらの候補関数が組み込まれます (次の項目を参照してください)。

    2. 関数が、モジュール・オブジェクト内部からまたはモジュール外部から、非修飾の関数名で呼び出される場合、データベース・マネージャーは、SQL パス内のスキーマのリストを検索して、実行する関数インスタンスを解決します。 SQL パス (『SQL パス』を参照) 内のスキーマごとに、データベース・マネージャーはそのスキーマで候補関数を検索します。

      SQL パスのスキーマで 1 つ以上の候補関数が見つかると、コンテキスト・モジュールからの候補関数にこれらの候補関数が組み込まれます (前の項目を参照してください)。 最適を判別するために、この一群の候補関数が処理されます (『最適の判別』を参照してください)。

データベース・マネージャーが候補関数を全く見つけないと、エラーが戻ります (SQLSTATE 42884)。

最適の判別

一群の候補関数には、1 つの関数、または同じ名前の複数の関数が含まれる場合があります。 どちらの場合にも、候補関数のセットに含まれる各関数のパラメーターのデータ・タイプ、SQL パスでのスキーマの位置、パラメーターの総数を使用して、関数が最適要件を満たすかどうかが判別されます。

候補関数のセットに複数の関数が含まれており、関数呼び出しで名前付き引数が使用されている場合、名前付き引数に対応するパラメーターの順序位置は、すべての候補関数で同じでなければなりません (SQLSTATE 4274K)。

パラメーター・セット という用語は、候補関数のセットの (上記のようなパラメーターが存在する) パラメーター・リストで同じ位置にあるすべてのパラメーターを表します。 パラメーターの対応引数は、関数呼び出しで引数がどのように指定されているかに基づいて判別されます。 定位置引数の場合、パラメーターの対応引数は、関数呼び出しにおいて候補関数のパラメーター・リストでのパラメーターと同じ位置にある引数です。 名前付き引数の場合、パラメーターの対応引数は、パラメーターと同じ名前の引数です。 この場合、関数呼び出しにおける引数の順序は、最適を判別する際に考慮されません。 候補関数のパラメーター数が関数呼び出しでの引数の数よりも多い場合、対応引数のない各パラメーターは、あたかも DEFAULT キーワードを値として持つ対応引数があるかのように処理されます。

最適である関数を判別するために、以下のステップが使用されます。
ステップ 1: 型付き式である引数の考慮
データベース・マネージャーは、各パラメーターのデータ・タイプと対応引数のデータ・タイプを比較することによって、呼び出しの最適要件を満たす関数、また関数のセットを判別します。
パラメーターのデータ・タイプがその対応引数のデータ・タイプと同じかどうかは、以下のように判別されます。
  • データ・タイプの同義語が一致します。 例えば、FLOAT と DOUBLE は同じであると見なされます。
  • 長さ、精度、スケール、およびコード・ページなどのデータ・タイプの属性は無視されます。 したがって、CHAR(8) と CHAR(35)、また DECIMAL(11,2) と DECIMAL(4,3) はそれぞれ同じタイプと見なされます。
関数呼び出しにおける型なし式でない各引数のデータ・タイプが、関数インスタンスの対応パラメーターのデータ・タイプと一致する関数か、またはそのデータ・タイプにプロモート可能である関数のみを考慮することにより、候補関数のサブセットが取得されます。 関数呼び出しの引数が型なし式である場合、対応パラメーターのデータ・タイプは、どのデータ・タイプでも構いません。 「データ・タイプのプロモーション」 にあるデータ・タイプのプロモーションの優先順位リストには、各データ・タイプに適合する (プロモーションを考慮した) データ・タイプが、優先順位の高いものから順に表示されます。 このサブセットが空でない場合は、候補関数のこのサブセットに対する プロモート可能プロセス を使用して最適が決定されます。 このサブセットが空の場合、候補関数の元のセットに対する キャスト可能プロセス を使用して最適なものが決定されます。
プロモート可能なプロセス
このプロセスは、関数呼び出しの引数が、関数定義の対応するパラメーターのデータ・タイプと一致するか、またはそのデータ・タイプにプロモートできるかどうかを考慮した場合にのみ、最適を決定します。 候補関数のサブセットの場合、パラメーター・リストが左から右へと処理されていきます。つまり、候補関数のサブセットの最初の位置のパラメーター・セットをまず処理してから、2 番目の位置のパラメーター・セットに進むというように処理されます。 候補関数のサブセットから候補関数を除去するために、以下のステップが使用されます (プロモーションのみを考慮)。
  1. ある候補関数のパラメーターの対応引数のデータ・タイプが、(プロモーションのみを考慮した場合に) 他の候補関数よりもパラメーターのデータ・タイプに適合する場合、関数呼び出しに対する適合度が同等でない候補関数は除去されます。 「データ・タイプのプロモーション」 にあるデータ・タイプのプロモーションの優先順位リストには、各データ・タイプに適合する (プロモーションを考慮した) データ・タイプが、優先順位の高いものから順に表示されます。
  2. 対応引数のデータ・タイプが型なし式である場合、候補関数は除去されません。
  3. これらのステップは、残りの候補関数の次のパラメーター・セットに対しても行われ、パラメーター・セットがそれ以上なくなるまで繰り返されます。
キャスト可能なプロセス
このプロセスではまず、関数呼び出しにおける対応引数のデータ・タイプが、関数定義のパラメーターのデータ・タイプに一致するかどうか、またはそのデータ・タイプにプロモートできるかどうかをパラメーターごとに調べて、最適が判別されます。 次にデータベース・マネージャーは、プロモート可能だったデータ・タイプを持つ対応引数がない各パラメーター・セットについて、関数解決のために対応引数のデータ・タイプをパラメーターのデータ・タイプに暗黙的にキャストできるかどうかを、パラメーターごとに調べます。
候補関数のセットの場合、パラメーター・リストに含まれるパラメーターが左から右へと処理されていきます。つまり、すべての候補関数の最初の位置のパラメーター・セットをまず処理してから、2 番目の位置のパラメーター・セットに進むというように処理されます。 候補関数のセットから候補関数を除去するために、以下のステップが使用されます (プロモーションのみを考慮)。
  1. ある候補関数のパラメーターの対応引数のデータ・タイプが、(プロモーションのみを考慮した場合に) 他の候補関数よりもパラメーターのデータ・タイプに適合する場合、関数呼び出しに対する適合度が同等でない候補関数は除去されます。 「データ・タイプのプロモーション」 にあるデータ・タイプのプロモーションの優先順位リストには、各データ・タイプに適合する (プロモーションを考慮した) データ・タイプが、優先順位の高いものから順に表示されます。
  2. 対応引数のデータ・タイプをいずれの候補関数のパラメーターのデータ・タイプにもプロモートできない場合 (対応引数が型なし式である場合を含む)、候補関数は除去されません。
  3. これらのステップは、残りの候補関数の次のパラメーター・セットに対しても行われ、パラメーター・セットがそれ以上なくなるまで繰り返されます。
(プロモーションのみを考慮した場合に) 適合する対応引数が少なくとも 1 つのパラメーター・セットになく、パラメーター・セットの対応引数がデータ・タイプを持つ場合、データベース・マネージャーは、こうしたパラメーター・セットを 1 つずつ左から右へと比較していきます。 候補関数のセットから候補関数を除去するために、以下のステップが使用されます (暗黙的キャストを考慮)。
  1. 残りのすべての候補関数のパラメーター・セットのすべてのデータ・タイプが、 データ・タイプのプロモーションで指定されている同じデータ・タイプ優先順位リストに属していない場合、エラーが戻されます (SQLSTATE 428F5)。
  2. 対応引数のデータ・タイプを、『関数解決のための暗黙的キャスト』で指定されているパラメーターのデータ・タイプに暗黙的にキャストできない場合は、エラーが戻されます (SQLSTATE 42884)。
  3. ある候補関数のパラメーターの対応引数のデータ・タイプが、(暗黙的キャストを考慮した場合に) 他の候補関数よりもパラメーターのデータ・タイプに適合する場合、関数呼び出しに対する適合度が同等でない候補関数は除去されます。 関数解決のための暗黙的キャスト のデータ・タイプ・リストは、(暗黙的キャストを考慮して) 適合するデータ・タイプを示しています。
  4. これらのステップは、(プロモーションのみを考慮した場合に) 適合する対応引数がなく、対応引数がデータ・タイプを持つ次のパラメーター・セットに対しても行われ、こうしたパラメーター・セットがなくなるかエラーが発生するまで繰り返されます。
ステップ 2: SQL パスの考慮
複数の候補関数が残っており、候補関数をまだ含んでいるコンテキスト・モジュールが存在する場合、データベース・マネージャーはそれらの関数を選択します。 コンテキスト・モジュールが存在しない場合、またはコンテキスト・モジュールに候補関数が残っていない場合、データベース・マネージャーは、SQL パスの最初にスキーマがある候補関数を選択します。
ステップ 3: 関数呼び出しにおける引数の数の考慮
複数の候補関数が残っており、ある候補関数のパラメーター数が他の候補関数のパラメーター数以下である場合、パラメーター数の多い候補関数は除去されます。
ステップ 4: 型なし式である引数の考慮
複数の候補関数が残っており、少なくとも 1 つのパラメーター・セットの対応引数が型なし式である場合、データベース・マネージャーは、こうしたパラメーター・セットを左から右へと比較していきます。 候補関数のセットから候補関数を除去するために、以下のステップが使用されます。
  1.     残りのすべての候補関数のパラメーター・セットのすべてのデータ・タイプが、 データ・タイプのプロモーションで指定されている同じデータ・タイプ優先順位リストに属していない場合、エラーが戻されます (SQLSTATE 428F5)。
  2. ある候補関数のパラメーターのデータ・タイプが、暗黙的キャストのデータ・タイプ順序付けで他の候補関数よりも左にある場合、パラメーターのデータ・タイプがデータ・タイプ順序付けで右にある候補関数は除去されます。 『関数解決のための暗黙的キャスト』にあるデータ・タイプ・リストは、暗黙的キャストのデータ・タイプ順序付けを示しています。
複数の候補関数がまだ存在する場合は、エラーが戻されます (SQLSTATE 428F5)。
関数解決のための暗黙的キャスト
ユーザー定義タイプ、参照タイプ、または XML データ・タイプを持つ引数については、関数解決の暗黙的キャストはサポートされません。 また、組み込み cast 関数またはユーザー定義 cast 関数についてもサポートされません。 サポートされるのは、以下の場合です。
  • 1 つのデータ・タイプの値は、「 データ・タイプのプロモーション」で指定されているように、同じデータ・タイプ優先順位リストにある他の任意のデータ・タイプにキャストできます。
  • 数値または日時データ・タイプは、以下にキャストできます。
    • Unicode データベースでは、CLOB 以外の文字データ・タイプ、または DBCLOB 以外のグラフィック・データ・タイプ。
    • 非 Unicode データベースでは、CLOB 以外の文字データ・タイプ。
  • CLOB 以外の文字データ・タイプは、数値データ・タイプまたは日時データ・タイプにキャストできます。
  • Unicode データベースでは、DBCLOB 以外のグラフィック・データ・タイプは、数値データ・タイプまたは日時データ・タイプにキャストできます。
  • 文字 FOR BIT DATA はバイナリー・ストリング・データ・タイプにキャストできます。
  • バイナリー・ストリング・データ・タイプは、文字 FOR BIT DATA にキャストできます。
  • TIMESTAMP データ・タイプを TIME データ・タイプにキャストできる。
  • BOOLEAN データ・タイプは、2 進整数データ・タイプ、CLOB 以外の文字データ・タイプ、または DBCLOB 以外のグラフィック・データ・タイプにキャストできます。
  • 2 進整数データ・タイプ、CLOB 以外の文字データ・タイプ、または DBCLOB 以外のグラフィック・データ・タイプは、BOOLEAN にキャストできます。
  • 型なし引数をどのデータ・タイプにもキャストできる。

プロモーション用のデータ・タイプ優先順位リストと同様に、暗黙的キャストの場合も関連したデータ・タイプのグループ内のデータ・タイプに対する順序があります。 この順序は、暗黙的キャストを考慮する関数解決の実行時に使用されます。 表 1 は、関数解決のための暗黙的キャストのデータ・タイプの順序を示しています。 データ・タイプは優先順位の高いものから順にリストされます (これは、プロモーション用のデータ・タイプ優先順位リストの順序とは異なることに注意してください)。 Unicode データベースでは、関数解決で SYSIBM スキーマの組み込み関数が選択され、 一部の引数に暗黙的キャストが必要となった場合、 組み込み関数がパラメーターの文字入力とグラフィック入力の両方をサポートしていれば、 その引数は暗黙のうちに文字にキャストされます。

表 1. 関数解決のための暗黙的キャストに使用するデータ・タイプの順序
データ・タイプ・グループ 関数解決のための暗黙的キャストに使用するデータ・タイプ・リスト (優先順位の高いものから順に)
数値データ・タイプ DECFLOAT、 double、 real、 decimal、 BIGINT、 INTEGER、 SMALLINT
文字データ・タイプおよび GRAPHIC ストリング・データ・タイプ VARCHAR または VARGRAPHIC、CHAR または GRAPHIC、CLOB または DBCLOB
バイナリー・ストリング・データ・タイプ VARBINARY、BINARY、BLOB
日時データ・タイプ TIMESTAMP、DATE
注:
  1. 上記の表に小文字で示したタイプは、以下のように定義されます。
    • decimal = DECIMAL (p,s) または NUMERIC(p,s)
    • real = REAL または FLOAT(n)。ここで、n は 24 を超えない値。
    • double = DOUBLE、DOUBLE-PRECISION、FLOAT、または FLOAT(n)。 ここで、n は 25 以上。
    リストの中のデータ・タイプの短形式および長形式の同義語は、 リストの中の同義語と同じであると見なされます。
  2. Unicode データベースのみの場合、以下は、等価のデータ・タイプと見なされます。
    • CHAR または GRAPHIC
    • VARCHAR および VARGRAPHIC
    • CLOB および DBCLOB
表 2. 暗黙的キャストが必要な場合に SYSIBM スキーマの組み込みスカラー関数を呼び出したときに得られる引数の長さ
ソース・データ・タイプ ターゲット・タイプおよび長さ
 
CHAR
GRAPHIC
VARCHAR
VARGRAPHIC
CLOB
DBCLOB
BINARY
VARBINARY
BLOB
TIMESTAMP
DECFLOAT
BOOLEAN
UNTYPED 127 127 254 254 32767 32767 - - 32767 12 34 5
SMALLINT 6 6 6 6 - - - - - - - 5
INTEGER 11 11 11 11 - - - - - - - 5
BIGINT 20 20 20 20 - - - - - - - 5
DECIMAL (p,s) 2 +p 2 +p 2 +p 2 +p - - - - - - - -
REAL 24 24 24 24 - - - - - - - -
DOUBLE 24 24 24 24 - - - - - - - -
DECFLOAT 42 42 42 42 - - - - - - - -
CHAR (n) 型 - - - - - - n n n 12 34 -
VAR CHAR (n) (VAR CHAR (n)) 最小 (n、254) 最小 (n、127) - - - - 最小 (n、254) n n 12 34 -
CLOB (n) (CLOB (n)) 最小 (n、254) 最小 (n、127) 最小 (n、32672) min (n、16336) - - - - - - - -
GRAPHIC (n) - - - - - - - - - 12 34 -
VARGRAPHIC (n) 最小 (n、254) 最小 (n、127) - - - - - - - 12 34 -
DBCLOB (n) 最小 (n、254) 最小 (n、127) 最小 (n、32672) min (n、16336) - - - - - - - -
BINARY (n) (BINARY (n)) n - n - - - - - - - - -
VARBINARY (n) 最小 (n、254) - n - - - 最小 (n、254) - - - - -
BLOB (n) 最小 (n、254) - 最小 (n、32672) - - - 最小 (n、254) 最小 (n、32672) - - - -
時刻 8 8 8 8 - - - - - - - -
日数 10 10 10 10 - - - - - - - -
TIMESTAMP (p) p=0 の場合は 19、それ以外の場合は 19 p+20 p=0 の場合は 19、それ以外の場合は 19 p+20 p=0 の場合は 19、それ以外の場合は 19 p+20 p=0 の場合は 19、それ以外の場合は 19 p+20 - - - - - - - -
BOOLEAN 5 5 5 5 - - - - - - - -

この表は、ストリング単位のデフォルトが SYSTEM の Unicode データベース環境に関連付けられたストリング単位で、文字ストリング・データ・タイプと グラフィック・ストリング・データ・タイプを示しています。 Unicode データベース環境のストリング単位が CODEUNITS32 に設定されている場合は、データ・タイプの最大長を表す文字ストリングまたはグラフィック・ストリングの長さ属性を、CODEUNITS32 のデータ・タイプの最大値を表すものと見なす必要があります。 すべての文字ストリング・データ・タイプまたはグラフィック・ストリング・データ・タイプで、データベース環境のデフォルトのストリング単位を使用します。

組み込み関数の SQL パスに関する考慮事項

関数解決は、 組み込みまたはユーザー定義のスキーマ関数およびモジュール関数を含む、 すべての関数に適用されます。 関数をスキーマ名なしで呼び出すと、 関数呼び出しを特定の関数に解決するときに SQL パスが使用されます。

SYSIBM スキーマの組み込み関数は、SYSIBM が SQL パスに明示的に含まれていない場合でも、関数解決の際に必ず考慮されます。 したがって、パスから SYSIBM を省いても、(関数およびデータ・タイプの解決では) SYSIBM がパスの最初のスキーマであると想定されることになります。

例えば、ユーザーの SQL パスが以下のように定義されているとします。
"SHAREFUN","SYSIBM","SYSFUN"
また、引数の数とタイプが SYSIBM.LENGTH と同じである LENGTH 関数が SHAREFUN スキーマに定義されているとします。 この場合、このユーザーの SQL ステートメントで、 修飾なしで LENGTH を参照すると、SHAREFUN.LENGTH が選択されます。 一方、ユーザーの SQL パスが以下のように定義されている場合には、
"SHAREFUN","SYSFUN"
同じ SHAREFUN.LENGTH 関数が存在していたとしても、 このユーザーの SQL ステートメントで修飾せずに LENGTH を参照すると、 SYSIBM.LENGTH が選択されることになります。 これは、SYSIBM が暗黙のうちにパス中で最初に出現するためです。
この状況下では、次のようにすれば、問題を未然に最小化することができます。
  • ユーザー定義関数には組み込み関数の名前を決して使用しないようにします。
  • 何らかの理由で組み込み関数と同じ名前のユーザー定義関数を作成する必要のある場合は、 そのような関数への参照には必ず修飾子を付けます。
注: 組み込み関数の呼び出しの中には、明示的な修飾子として SYSIBM をサポートせず、SQL パスを考慮せずに組み込み関数に直接解決するものがあります。 組み込み関数の説明には、特定の事例が取り上げられています。

関数解決の例

以下に、関数解決の例を示します。 (必要なキーワードがすべて示されているわけではないことに注意してください。)
  • 以下に、関数解決での SQL パスの考慮事項を示す例があります。 この例では、3 つの異なるスキーマに 8 つの ACT 関数があり、以下のように登録されています。
    CREATE FUNCTION AUGUSTUS.ACT (CHAR(5), INT, DOUBLE) SPECIFIC ACT_1 ...
    CREATE FUNCTION AUGUSTUS.ACT (INT, INT, DOUBLE) SPECIFIC ACT_2 ...
    CREATE FUNCTION AUGUSTUS.ACT (INT, INT, DOUBLE, INT) SPECIFIC ACT_3 ...
    CREATE FUNCTION JULIUS.ACT (INT, DOUBLE, DOUBLE) SPECIFIC ACT_4 ...
    CREATE FUNCTION JULIUS.ACT (INT, INT, DOUBLE) SPECIFIC ACT_5 ...
    CREATE FUNCTION JULIUS.ACT (SMALLINT, INT, DOUBLE) SPECIFIC ACT_6 ...
    CREATE FUNCTION JULIUS.ACT (INT, INT, DECFLOAT) SPECIFIC ACT_7 ...
    CREATE FUNCTION NERO.ACT (INT, INT, DEC(7,2)) SPECIFIC ACT_8 ...
    以下のように関数が参照されるとします (I1 および I2 は INTEGER 列、 D は DECIMAL 列です)。
    SELECT ... ACT(I1, I2, D) ...
    この参照を行うアプリケーションの SQL パスが次のようになっているとします。
    "JULIUS","AUGUSTUS","CAESAR"
    アルゴリズムに従っていきます。
    • スキーマ NERO が SQL パスに組み込まれていないため、特定の名前 ACT_8 の付いた関数は候補から除かれます。
    • パラメーターの数が違っているため、ACT_3 は候補から除かれます。 第 1 引数が第 1 パラメーターのデータ・タイプにプロモートできないため、 ACT_1 と ACT_6 はどちらも候補から除かれます。
    • この時点で複数の候補が残っているため、次に引数が順に検討されます。
    • 最初の引数については、残りのすべての関数 ACT_2、ACT_4、ACT_5、および ACT_7 がその引数タイプと完全に一致します。 この検討ではどの関数も検討の対象から除かれないため、 次の引数を検討する必要があります。
    • 2 番目の引数では、ACT_2、ACT_5、および ACT_7 が完全に一致していますが、 ACT_4 は一致していないため、ACT_4 が検討の対象から除かれます。 ACT_2、ACT_5、および ACT_7 の間の何らかの差異を判別するために、さらに次の引数が検討されます。
    • 第 3 の最後の引数では、ACT_2、ACT_5、ACT_7 のいずれも、引数のタイプと完全には一致していません。 ACT_2 と ACT_5 の適合度は同程度ですが、ACT_7 は他の 2 つよりも適合度が劣ります。タイプ DOUBLE は DECFLOAT よりも、DECIMAL に近いからです。 ACT_7 は除去されます。
    • この時点で、 パラメーター・シグニチャーが同じである関数として ACT_2 と ACT_5 の 2 つが残っています。 最終的な決定要因は、どちらの関数のスキーマが SQL パスで先に出現するかであり、 この基準によって ACT_5 が最終的に選択されます。
  • 以下に、関数解決の結果、エラー (SQLSTATE 428F5) が発生するという状況の例を示します。このエラーは、複数の候補関数が呼び出しに等しく適合するが、引数のいずれかの対応するパラメーターが同じタイプ優先順位リストに属していないために発生します。
    この例では、以下のように定義された単一のスキーマに 3 つの関数のみ含まれています。
    CREATE FUNCTION CAESAR.ACT (INT, VARCHAR(5), VARCHAR(5))SPECIFIC ACT_1 ...
    CREATE FUNCTION CAESAR.ACT (INT, INT, DATE)     SPECIFIC ACT_2 ...
    CREATE FUNCTION CAESAR.ACT (INT, INT, DOUBLE)   SPECIFIC ACT_3 ...
    
    以下のように関数が参照されるとします (I1 および I2 は INTEGER 列、VC は VARCHAR 列です)。
    SELECT ... ACT(I1, I2, VC) ...
    この参照を行うアプリケーションの SQL パスが次のようになっているとします。
    "CAESAR"
    アルゴリズムに従っていきます。
    • 関数呼び出しの各入力引数のデータ・タイプが、関数インスタンスの対応するパラメーターのデータ・タイプと一致するか、またはそのデータ・タイプにプロモート可能かどうかを判別するために、それぞれの候補関数が評価されます。
      • 最初の引数については、候補となるすべての関数にこのパラメーター・タイプと 完全に一致するデータ・タイプが含まれます。
      • 2 番目の引数については、INTEGER を VARCHAR にプロモートできないため、ACT_1 は除去されます。
      • 3 番目の引数については、VARCHAR を DATE または DOUBLE にプロモートできないため、候補関数が残らないように、ACT_2 と ACT_3 の両方が除去されます。
    • 候補関数のサブセットが空のため、候補関数はキャスト可能なプロセスを使用して考慮されます。
      • 最初の引数については、候補となるすべての関数にこのパラメーター・タイプと 完全に一致するデータ・タイプが含まれます。
      • 2 番目の引数については、INTEGER を VARCHAR にプロモートできないため、ACT_1 は除去されます。 ACT_2 と ACT_3 が候補として適しています。
      • 3 番目の引数については、ACT_2 および ACT_3 の対応するパラメーターのデータ・タイプが同じデータ・タイプの優先順位リストに属していないため、エラーが戻されます (SQLSTATE 428F5)。
  • この例では、キャスト可能なプロセスを使用して関数解決が成功する状況を示しています。 この例では、以下のように定義された単一のスキーマに 3 つの関数のみ含まれています。
    CREATE FUNCTION CAESAR.ACT (INT, VARCHAR(5), VARCHAR(5))SPECIFIC ACT_1 ...
    CREATE FUNCTION CAESAR.ACT (INT, INT, DECFLOAT)     SPECIFIC ACT_2 ...
    CREATE FUNCTION CAESAR.ACT (INT, INT, DOUBLE)   SPECIFIC ACT_3 ...
    
    以下のように関数が参照されるとします (I1 および I2 は INTEGER 列、VC は VARCHAR 列です)。
    SELECT ... ACT(I1, I2, VC) ...
    この参照を行うアプリケーションの SQL パスが次のようになっているとします。
    "CAESAR"
    アルゴリズムに従っていきます。
    • 関数呼び出しの各入力引数のデータ・タイプが、関数インスタンスの対応するパラメーターのデータ・タイプと一致するか、またはそのデータ・タイプにプロモート可能かどうかを判別するために、それぞれの候補関数が評価されます。
      • 最初の引数については、候補となるすべての関数にこのパラメーター・タイプと 完全に一致するデータ・タイプが含まれます。
      • 2 番目の引数については、INTEGER を VARCHAR にプロモートできないため、ACT_1 は除去されます。
      • 3 番目の引数については、VARCHAR を DECFLOAT または DOUBLE にプロモートできないため、候補関数が残らないように、ACT_2 と ACT_3 の両方が除去されます。
    • 候補関数のサブセットが空のため、候補関数はキャスト可能なプロセスを使用して考慮されます。
      • 最初の引数については、候補となるすべての関数にこのパラメーター・タイプと 完全に一致するデータ・タイプが含まれます。
      • 2 番目の引数については、INTEGER を VARCHAR にプロモートできないため、ACT_1 は除去されます。 ACT_2 と ACT_3 が候補として適しています。
      • 3 番目の引数については、DECFLOAT と DOUBLE の両方が同じデータ・タイプの優先順位リストにあり、VARCHAR は DECFLOAT と DOUBLE の両方を暗黙のうちにキャストできます。 DECFLOAT は暗黙的キャストに適しているため、 ACT_2 が最適です。
  • この例では、キャスト可能なプロセスを使用した関数解決時に、後の引数のプロモーションが暗黙的キャストより優先することを示しています。 この例では、以下のように定義された単一のスキーマに 3 つの関数のみ含まれています。
    CREATE FUNCTION CAESAR.ACT (INT, INT, VARCHAR(5))SPECIFIC ACT_1 ...
    CREATE FUNCTION CAESAR.ACT (INT, INT, DECFLOAT) SPECIFIC ACT_2 ...
    CREATE FUNCTION CAESAR.ACT (INT, INT, DOUBLE)  SPECIFIC ACT_3 ...
    
    以下のように関数が参照されるとします (I1 は INTEGER 列、VC1 は VARCHAR 列、および C1 は CHAR 列です)。
    SELECT ... ACT(I1, VC1, C1) ...
    この参照を行うアプリケーションの SQL パスが次のようになっているとします。
    "CAESAR"
    アルゴリズムに従っていきます。
    • 関数呼び出しの各入力引数のデータ・タイプが、関数インスタンスの対応するパラメーターのデータ・タイプと一致するか、またはそのデータ・タイプにプロモート可能かどうかを判別するために、それぞれの候補関数が評価されます。
      • 最初の引数については、候補となるすべての関数にこのパラメーター・タイプと 完全に一致するデータ・タイプが含まれます。
      • 2 番目の引数については、VARCHAR を INTEGER にプロモートできないため、候補関数が残らないように、すべての候補関数が除去されます。
    • 候補関数のサブセットが空のため、候補関数はキャスト可能なプロセスを使用して考慮されます。
      • 最初の引数については、候補となるすべての関数にこのパラメーター・タイプと 完全に一致するデータ・タイプが含まれます。
      • 2 番目の引数については、候補関数のどれにも対応する引数をプロモートできるパラメーターがないため、候補関数は除去されません。
      • 3 番目の引数は ACT_1 のパラメーターにプロモートできますが、ACT_2 または ACT_3 のパラメーターにはプロモートできないため、ACT_1 が最適です。