関数における型の解決

1. Select the functions to be considered from the <classname>pg_proc</classname> system catalog. If a non-schema-qualified function name was used, the functions considered are those with the matching name and argument count that are visible in the current search path (see <xref linkend="ddl-schemas-path"/>). If a qualified function name was given, only functions in the specified schema are considered. pg_procシステムカタログから、調査の対象とする関数を選択します。 スキーマ修飾がされていない関数名が使用される場合、現行の検索パスで可視になっていて、同一の名前と引数の数を持つ関数が調査対象であるとみなされます （5.10.3を参照してください）。 修飾された関数名が与えられている場合、指定されたスキーマの関数のみが調査対象とみなされます。

   1. If the search path finds multiple functions of identical argument types, only the one appearing earliest in the path is considered. Functions of different argument types are considered on an equal footing regardless of search path position. 検索パスで、引数のデータ型が同じである複数の関数を検出した場合、そのパスで最初に検出された関数のみを調査対象とみなします。 引数のデータ型が異なる関数は、検索パス内の位置に関係なく、同じように調べられます。

   2. If a function is declared with a <literal>VARIADIC</literal> array parameter, and the call does not use the <literal>VARIADIC</literal> keyword, then the function is treated as if the array parameter were replaced by one or more occurrences of its element type, as needed to match the call. After such expansion the function might have effective argument types identical to some non-variadic function. In that case the function appearing earlier in the search path is used, or if the two functions are in the same schema, the non-variadic one is preferred. もし関数がVARIADIC型の配列パラメータを伴って定義されており、そしてVARIADICキーワードを用いずに呼ばれた場合は、呼び出しに適合するよう、一つかそれ以上の要素の型に配列のパラメータを置き換えた形で扱われます。 このような拡張後は、その関数は実際の引数の型を持つので、他の非可変長の引数を持つ関数と同一になるかもしれません。この場合、検索パスで先に見つかった関数が使われます。また、同じスキーマに2つの関数が見つかった場合は非可変長の関数が優先されます。

      This creates a security hazard when calling, via qualified name 信用できないユーザにオブジェクトの作成を許可しているスキーマで見つかる可変長引数の関数を、修飾された名前で ^[10], 呼び出す時にセキュリティの危険が発生します。 悪意のあるユーザは、支配権を奪い、あたかもあなたが実行したかのように任意のSQL関数を実行できます。 VARIADICキーワードを持つ呼び出しを代わりに使ってください。そうすればこの危険は避けられます。 VARIADIC "any"パラメータにデータを入れての呼び出しには、しばしば同等のVARIADICキーワードを含む定式化がありません。 この呼び出しを安全に行うには、関数のスキーマは信用できるユーザだけがオブジェクトを作成できるようにしなければなりません。

   3. Functions that have default values for parameters are considered to match any call that omits zero or more of the defaultable parameter positions. If more than one such function matches a call, the one appearing earliest in the search path is used. If there are two or more such functions in the same schema with identical parameter types in the non-defaulted positions (which is possible if they have different sets of defaultable parameters), the system will not be able to determine which to prefer, and so an <quote>ambiguous function call</quote> error will result if no better match to the call can be found. パラメータにデフォルト値を持つ関数は、デフォルト指定可能なパラメータ位置のうち、0以上が省略されたどのような呼び出しに対しても適合すると見なされます。 もし呼び出し時にこのような関数が2つ以上適合した場合、検索パスで先に見つかったものが使用されます。 もし、デフォルト指定のない位置に同じパラメータ型を持つ関数（もしそれらが異なるデフォルト指定のあるパラメータのセットを持っていればあり得ます）が同じスキーマに2つ以上あった時は、システムはどの関数を使うべきか決定できず、呼び出しにより適合するものが見つからなければ「ambiguous function call」エラーが結果として返るでしょう。

      This creates an availability hazard when calling, via qualified name<footnoteref linkend="func-qualified-security"/>, any function found in a schema that permits untrusted users to create objects. A malicious user can create a function with the name of an existing function, replicating that function's parameters and appending novel parameters having default values. This precludes new calls to the original function. To forestall this hazard, place functions in schemas that permit only trusted users to create objects. 信用できないユーザにオブジェクトの作成を許可しているスキーマで見つかる関数を修飾された名前で^[10]呼び出す時に、これは濫用の危険を起こします。 悪意のあるユーザは、既存の関数の名前で、その関数のパラメータを複製し、デフォルト値を持つ新しいパラメータを追加した関数を作成できます。 これは元の関数への新しい呼び出しを妨げます。 この危険を未然に防ぐには、関数を信用できるユーザだけがオブジェクトを作成できるスキーマに置いてください。

2. Check for a function accepting exactly the input argument types. If one exists (there can be only one exact match in the set of functions considered), use it. Lack of an exact match creates a security hazard when calling, via qualified name<footnoteref linkend="func-qualified-security"/>, a function found in a schema that permits untrusted users to create objects. In such situations, cast arguments to force an exact match. (Cases involving <type>unknown</type> will never find a match at this step.) 正確に入力引数型を受け付ける関数があるかどうか検査します。 該当する関数があれば（調査される関数の集合内で正確に一致するものは1つしかあり得ません）、それを使用します。 正確に一致するものがない場合、信用できないユーザにオブジェクトの作成を許可しているスキーマで見つかる関数を、修飾された名前で^[10]呼び出す時にセキュリティの危険が発生します。 そのような状況では、強制的に正確に一致するように引数をキャストしてください。 （unknownを含む場合は、この段階で一致するものは決して見つかりません。）

3. If no exact match is found, see if the function call appears to be a special type conversion request. This happens if the function call has just one argument and the function name is the same as the (internal) name of some data type. Furthermore, the function argument must be either an unknown-type literal, or a type that is binary-coercible to the named data type, or a type that could be converted to the named data type by applying that type's I/O functions (that is, the conversion is either to or from one of the standard string types). When these conditions are met, the function call is treated as a form of <literal>CAST</literal> specification. 正確に一致するものが存在しなかった場合、その関数呼び出しが特別な型変換要求であるかどうかを確認します。 これは、関数呼び出しがただ1つの引数を取り、関数名が何らかのデータ型の（内部的な）名前と同一である場合に発生します。 さらに、その関数の引数は、unknown型のリテラルか指定されたデータ型へのバイナリ変換可能な型か、型の入出力関数を適用することで指定された型に変換可能な型（つまり、変換が標準文字列型との間の変換である）であるかのいずれかでなければなりません。 これらの条件に合う場合、関数呼び出しはCAST仕様の形式と同様に扱われます。 ^[11]

4. Look for the best match. 最適なものを検索します。

   1. Discard candidate functions for which the input types do not match and cannot be converted (using an implicit conversion) to match. <type>unknown</type> literals are assumed to be convertible to anything for this purpose. If only one candidate remains, use it; else continue to the next step. 関数の候補のうち、入力値のデータ型が一致せず、また、（暗黙的な変換を使用して）一致するように変換できないものを破棄します。 unknownリテラルは、上記の目的で何にでも変換可能とみなされます。 1つの候補しか残らない場合、それを使います。 それ以外の場合は次の段階に進みます。

   2. If any input argument is of a domain type, treat it as being of the domain's base type for all subsequent steps. This ensures that domains act like their base types for purposes of ambiguous-function resolution. 入力引数のいずれかがドメイン型であれば、以降の段階すべてでドメインの基本型であるかのように扱います。 これにより、曖昧な関数を解決するのを目的としてその基本型であるかのようにドメインが振る舞うことを確実にします。

   3. Run through all candidates and keep those with the most exact matches on input types. Keep all candidates if none have exact matches. If only one candidate remains, use it; else continue to the next step. 全ての候補を検索し、入力型に最も正確に合うものを残します。 正確に合うものが何もなければ全ての候補を残します。 1つの候補しか残らない場合、それを使います。 それ以外の場合は次の段階に進みます。

   4. Run through all candidates and keep those that accept preferred types (of the input data type's type category) at the most positions where type conversion will be required. Keep all candidates if none accept preferred types. If only one candidate remains, use it; else continue to the next step. 全ての候補を検索し、型変換が必要とされるところで（入力データ型カテゴリの）優先される型を受け付けるものを残します。 優先される型を受け付けるものが何もなければ全ての候補を残します。 1つの候補しか残らない場合、それを使います。 それ以外の場合は次の段階に進みます。

   5. If any input arguments are <type>unknown</type>, check the type categories accepted at those argument positions by the remaining candidates. At each position, select the <type>string</type> category if any candidate accepts that category. (This bias towards string is appropriate since an unknown-type literal looks like a string.) Otherwise, if all the remaining candidates accept the same type category, select that category; otherwise fail because the correct choice cannot be deduced without more clues. Now discard candidates that do not accept the selected type category. Furthermore, if any candidate accepts a preferred type in that category, discard candidates that accept non-preferred types for that argument. Keep all candidates if none survive these tests. If only one candidate remains, use it; else continue to the next step. 入力引数でunknownのものがあった場合、それらの残った候補に引数位置で受け入れられる型カテゴリを検査します。 各位置で候補がstringカテゴリを受け付ける場合は、そのカテゴリを選択します。 （unknown 型のリテラルは文字列のようなものですので、この文字列への重み付けは適切です。） そうでなければ、もし残った全ての候補が同じ型カテゴリを受け入れる場合はそのカテゴリを選択します。 そうでもなければ、さらに手掛かりがなければ正しい選択が演繹されることができませんので、失敗となります。 ここで、選択された型カテゴリを受け付けない演算子候補は破棄されます。 さらに、このカテゴリ内の優先される型を受け付ける候補が1つでもある場合、その引数の優先されない型を受け付ける候補は破棄されます。 これらの検査をどれも通らなかったら全ての候補を残します。 1つの候補しか残らない場合、それを使います。 それ以外の場合は次の段階に進みます。

   6. If there are both <type>unknown</type> and known-type arguments, and all the known-type arguments have the same type, assume that the <type>unknown</type> arguments are also of that type, and check which candidates can accept that type at the <type>unknown</type>-argument positions. If exactly one candidate passes this test, use it. Otherwise, fail. もしunknownと既知の型の引数の両方があり、そして全ての既知の型の引数が同じ型を持っていた場合、unknown引数も同じ型であると仮定し、 どの候補がunknown引数の位置にある型を受け付けることができるかを検査します。 正確に1つの候補がこの検査を通過した場合、それを使います。それ以外は失敗します。