無料スクリプト配布のPHP.TO   PHPの実用的なtips PHPマニュアル MySQLマニュアル Apacheマニュアル PostgreSQLマニュアル マニュアル検索    

10.3. 関数

関数呼び出しによって参照される特定の関数は、以下の手順に従って解決されます。

関数における型の解決

  1. pg_proc システムカタログから、調査の対象とする関数を選択します。 スキーマ修飾がされていない関数名が使用される場合、現行の検索パスで可視になっていて、同一の名前と引数の数を持つ関数が調査対象であるとみなされます ( 項5.7.3 を参照してください)。 修飾された関数名が与えられている場合、指定されたスキーマの関数のみが調査対象とみなされます。

    1. 検索パスで、引数のデータ型が同じである複数の関数を検出した場合、そのパスで最初に検出された関数のみを調査対象とみなします。 引数のデータ型が異なる関数は、検索パス内の位置に関係なく、同じように調べられます。

    2. もし関数が VARIADIC 型の配列パラメータを伴って定義されており、そして VARIADIC キーワードを用いずに呼ばれた場合は、呼び出しに適合するよう、一つかそれ以上の要素の型に配列のパラメータを置き換えた形で扱われます。 このような拡張後は、その関数は実際の引数の型を持つので、他の非可変長の引数を持つ関数と同一になるかもしれません。この場合、検索パスで先に見つかった関数が使われます。また、同じスキーマに2つの関数が見つかった場合は非可変長の関数が優先されます。

    3. パラメータにデフォルト値を持つ関数は、デフォルト指定可能なパラメータ位置の0以上の省略されたどのような呼び出しに対しても適合すると見なされます。もし呼び出し時にこのような関数が一つ以上適合した場合、検索パスで先に見つかったものが使用されます。もし、デフォルト指定のない位置に同じパラメータ型を持つ関数(もしそれらが異なるデフォルト指定のあるパラメータのセットを持っていればあり得ます)が同じスキーマに2つ以上あった時は、どの関数を使うべきを決定できず、適合する関数が見つからなかったという "ambiguous function call" エラーが結果として返るでしょう。

  2. 正確に入力引数型を受け付ける関数があるかどうか検査します。 該当する関数があれば(調査される関数の集合内で正確に一致するものは1つしかあり得ません)、それを使用します ( unknown を含む場合は、この段階で一致するものは決して見つかりません)。

  3. 正確に一致するものが存在しなかった場合、その関数呼び出しが特別な型変換要求であるかどうかを確認します。 これは、関数呼び出しがただ1つの引数を取り、関数名が何らかのデータ型の(内部的な)名前と同一である場合に発生します。 さらに、その関数の引数は、unknown型のリテラルか指定されたデータ型へのバイナリ変換可能な型か、型の入出力関数を適用することで指定された型に変換可能な型(つまり、変換が標準文字列型との間の変換である)であるかのいずれかでなければなりません。 これらの条件に合う場合、関数呼び出しは CAST 仕様の形式と同様に扱われます。 [1]

  4. 最適なものを検索します。

    1. 関数の候補のうち、入力値のデータ型が一致せず、また、(暗黙的な変換を使用して)一致するように変換できないものを破棄します。 unknown リテラルは、上記の目的で何にでも変換可能とみなされます。 1つの候補しか残らない場合、それを使います。 それ以外の場合は次の段階に進みます。

    2. 全ての候補を検索し、入力型に最も正確に合うものを残します (この時、ドメインはその基本型と同一であるとみなします)。 正確に合うものが何もなければ全ての候補を残します。 1つの候補しか残らない場合、それを使います。 それ以外の場合は次の段階に進みます。

    3. 全ての候補を検索し、型変換が必要とされるところで(入力データ型カテゴリの)好ましい型を受け付けるものを残します。 好ましい型を受け付けるものが何もなければ全ての候補を残します。 1つの候補しか残らない場合、それを使います。 それ以外の場合は次の段階に進みます。

    4. 入力引数で unknown のものがあった場合、それらの残った候補に引数位置で受け入れられる型カテゴリを検査します。 各位置で候補が string カテゴリを受け付ける場合は、そのカテゴリを選択します (unknown 型のリテラルは文字列のようなものですので、この文字列への重み付けは適切です)。 そうでなければ、もし残った全ての候補が同じ型カテゴリを受け入れる場合はそのカテゴリを選択します。 そうでもなければ、さらに手掛かりがなければ正しい選択が演繹されることができませんので、失敗となります。 ここで、選択された型カテゴリを受け付けない演算子候補は破棄されます。 さらに、このカテゴリ内の好ましい型を受け付ける候補が1つでもある場合、その引数の好ましい型ではないものを受け付ける候補は破棄されます。 これらの検査をどれも通らなかったら全ての候補を残します。 1つの候補しか残らない場合、それを使います。 それ以外の場合は次の段階に進みます。

    5. もし unknown と既知の型の引数の両方があり、そして全ての既知の型の引数が同じ型を持っていた場合、 unknown 引数も同じ型であると仮定し、 どの候補が unknown 引数の位置にある型を受け付けることができるかを検査します。 正確に1つの候補がこの検査を通過した場合、それを使います。それ以外は失敗します。

この "最善一致" 規則は演算子と関数の型解決で同一であることに注意してください。 以下に例を示します。

例 10-5. 丸め関数引数の型解決

2つの引数を取る round 関数は1つしかありません 第1引数として numeric 型、第2引数として integer 型を取ります。 ですから、以下の問い合わせは自動的に、 integer 型の第1引数を numeric に変換します。

SELECT round(4, 4);

 round
--------
 4.0000
(1 row)

問い合わせはパーサによって実質以下のように変形されます。

SELECT round(CAST (4 AS numeric), 4);

小数点を持つ数値定数はまず numeric に割り当てられますので、以下の問い合わせでは型変換が不要です。そのためかなり効率的になる可能性があります。

SELECT round(4.0, 4);

例 10-6. 部分文字列関数の型解決

substr 関数は複数存在します。 その1つは text integer 型を取ります。 型の指定がない文字列定数で呼び出した場合、システムは好ましいカテゴリ string (すなわち text 型)の引数を受け付ける候補関数を選択します。

SELECT substr('1234', 3);

 substr
--------
     34
(1 row)

文字列が varchar 型と宣言された場合、これはテーブルから取り出した場合が考えられますが、パーサはそれを text になるように変換しようと試みます。

SELECT substr(varchar '1234', 3);

 substr
--------
     34
(1 row)

これは以下になるようにパーサによって変換されます。

SELECT substr(CAST (varchar '1234' AS text), 3);

注意: パーサは pg_cast カタログから text varchar がバイナリ互換、つまり、何らかの物理的な変換を行うことなく片方を受け付ける関数にもう片方を渡すことができることを学習します。 したがって、この場合実際に挿入される型変換呼び出しはありません。

また、 integer 型の引数でこの関数が呼び出された場合、パーサはそれを text に変換しようと試みます。

SELECT substr(1234, 3);
ERROR:  function substr(integer, integer) does not exist
HINT:  No function matches the given name and argument types. You might need
to add explicit type casts.

integer text への暗黙的なキャストを持たないため、これは失敗します。 成功させるには、以下のように明示的なキャストを行います。

SELECT substr(CAST (1234 AS text), 3);

 substr
--------
     34
(1 row)

注意

[1]

この処理の理由は、実際にはキャスト関数が存在しない状況において、関数形態のキャスト仕様をサポートすることです。 キャスト関数が存在する場合、慣習的に出力型に因んで名付けられます。 ですので、特殊な状況を持つ必要はありません。 詳細な解説については CREATE CAST を参照してください。


powered by SEO.CUG.NET