The specific function that is referenced by a function call is determined using the following procedure. 関数呼び出しによって参照される特定の関数は、以下の手順に従って解決されます。
関数における型の解決
<title>Function Type Resolution</title>
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を参照してください)。
修飾された関数名が与えられている場合、指定されたスキーマの関数のみが調査対象とみなされます。
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. 検索パスで、引数のデータ型が同じである複数の関数を検出した場合、そのパスで最初に検出された関数のみを調査対象とみなします。 引数のデータ型が異なる関数は、検索パス内の位置に関係なく、同じように調べられます。
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
キーワードを含む定式化がありません。
この呼び出しを安全に行うには、関数のスキーマは信用できるユーザだけがオブジェクトを作成できるようにしなければなりません。
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]呼び出す時に、これは濫用の危険を起こします。 悪意のあるユーザは、既存の関数の名前で、その関数のパラメータを複製し、デフォルト値を持つ新しいパラメータを追加した関数を作成できます。 これは元の関数への新しい呼び出しを妨げます。 この危険を未然に防ぐには、関数を信用できるユーザだけがオブジェクトを作成できるスキーマに置いてください。
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
を含む場合は、この段階で一致するものは決して見つかりません。)
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]
Look for the best match. 最適なものを検索します。
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つの候補しか残らない場合、それを使います。
それ以外の場合は次の段階に進みます。
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. 入力引数のいずれかがドメイン型であれば、以降の段階すべてでドメインの基本型であるかのように扱います。 これにより、曖昧な関数を解決するのを目的としてその基本型であるかのようにドメインが振る舞うことを確実にします。
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つの候補しか残らない場合、それを使います。 それ以外の場合は次の段階に進みます。
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つの候補しか残らない場合、それを使います。 それ以外の場合は次の段階に進みます。
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つの候補しか残らない場合、それを使います。
それ以外の場合は次の段階に進みます。
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つの候補がこの検査を通過した場合、それを使います。それ以外は失敗します。
Note that the <quote>best match</quote> rules are identical for operator and function type resolution. Some examples follow. この「最善一致」規則は演算子と関数の型解決で同一であることに注意してください。 以下に例を示します。
例10.6 丸め関数引数の型解決
There is only one <function>round</function> function that takes two
arguments; it takes a first argument of type <type>numeric</type> and
a second argument of type <type>integer</type>.
So the following query automatically converts
the first argument of type <type>integer</type> to
<type>numeric</type>:
2つの引数を取るround
関数は1つしかありません
第1引数としてnumeric
型、第2引数としてinteger
型を取ります。
ですから、以下の問い合わせは自動的に、integer
型の第1引数をnumeric
に変換します。
SELECT round(4, 4); round -------- 4.0000 (1 row)
That query is actually transformed by the parser to: 問い合わせはパーサによって実質以下のように変形されます。
SELECT round(CAST (4 AS numeric), 4);
Since numeric constants with decimal points are initially assigned the
type <type>numeric</type>, the following query will require no type
conversion and therefore might be slightly more efficient:
小数点を持つ数値定数はまずnumeric
に割り当てられますので、以下の問い合わせでは型変換が不要です。そのためかなり効率的になる可能性があります。
SELECT round(4.0, 4);
例10.7 可変長引数の関数の解決
CREATE FUNCTION public.variadic_example(VARIADIC numeric[]) RETURNS int LANGUAGE sql AS 'SELECT 1'; CREATE FUNCTION
This function accepts, but does not require, the VARIADIC keyword. It tolerates both integer and numeric arguments: この関数は、必須ではないですがVARIADICキーワードを受け付けます。 整数の引数と数値の引数の両方を許容します。
SELECT public.variadic_example(0), public.variadic_example(0.0), public.variadic_example(VARIADIC array[0.0]); variadic_example | variadic_example | variadic_example ------------------+------------------+------------------ 1 | 1 | 1 (1 row)
However, the first and second calls will prefer more-specific functions, if available: しかしながら、1番目と2番目の呼び出しは、もし利用可能なら、より特定の関数を優先します。
CREATE FUNCTION public.variadic_example(numeric) RETURNS int LANGUAGE sql AS 'SELECT 2'; CREATE FUNCTION CREATE FUNCTION public.variadic_example(int) RETURNS int LANGUAGE sql AS 'SELECT 3'; CREATE FUNCTION SELECT public.variadic_example(0), public.variadic_example(0.0), public.variadic_example(VARIADIC array[0.0]); variadic_example | variadic_example | variadic_example ------------------+------------------+------------------ 3 | 2 | 1 (1 row)
Given the default configuration and only the first function existing, the
first and second calls are insecure. Any user could intercept them by
creating the second or third function. By matching the argument type exactly
and using the <literal>VARIADIC</literal> keyword, the third call is secure.
もしデフォルトの設定で最初の関数だけが存在しているなら、1番目と2番目の呼び出しは安全ではありません。
ユーザは、2番目や3番目の関数を作成することで、それらを妨害できます。
引数の型を厳密に一致させVARIADIC
キーワードを使うのなら、3番目の呼び出しは安全です。
例10.8 部分文字列関数の型解決
There are several <function>substr</function> functions, one of which
takes types <type>text</type> and <type>integer</type>. If called
with a string constant of unspecified type, the system chooses the
candidate function that accepts an argument of the preferred category
<literal>string</literal> (namely of type <type>text</type>).
substr
関数は複数存在します。
その1つはtext
とinteger
型を取ります。
型の指定がない文字列定数で呼び出した場合、システムは優先されるカテゴリstring
(すなわちtext
型)の引数を受け付ける候補関数を選択します。
SELECT substr('1234', 3); substr -------- 34 (1 row)
If the string is declared to be of type <type>varchar</type>, as might be the case
if it comes from a table, then the parser will try to convert it to become <type>text</type>:
文字列がvarchar
型と宣言された場合、これはテーブルから取り出した場合が考えられますが、パーサはそれをtext
になるように変換しようと試みます。
SELECT substr(varchar '1234', 3); substr -------- 34 (1 row)
This is transformed by the parser to effectively become: これは以下になるようにパーサによって変換されます。
SELECT substr(CAST (varchar '1234' AS text), 3);
The parser learns from the <structname>pg_cast</structname> catalog that
<type>text</type> and <type>varchar</type>
are binary-compatible, meaning that one can be passed to a function that
accepts the other without doing any physical conversion. Therefore, no
type conversion call is really inserted in this case.
パーサはpg_cast
カタログからtext
とvarchar
がバイナリ互換、つまり、何らかの物理的な変換を行うことなく片方を受け付ける関数にもう片方を渡すことができることを知ります。
したがって、この場合実際に挿入される型変換呼び出しはありません。
And, if the function is called with an argument of type <type>integer</type>,
the parser will try to convert that to <type>text</type>:
また、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.
This does not work because <type>integer</type> does not have an implicit cast
to <type>text</type>. An explicit cast will work, however:
integer
はtext
への暗黙的なキャストを持たないため、これは失敗します。
成功させるには、以下のように明示的なキャストを行います。
SELECT substr(CAST (1234 AS text), 3); substr -------- 34 (1 row)
[10] The hazard does not arise with a non-schema-qualified name, because a search path containing schemas that permit untrusted users to create objects is not a <link linkend="ddl-schemas-patterns">secure schema usage pattern</link>. 信用できないユーザにオブジェクトの作成を許可するスキーマを含む検索パスは、安全なスキーマ使用パターンではありませんので、スキーマで修飾されていない名前では危険は起こりません。
</footnote>, a variadic function found in a schema that permits untrusted users to create objects. A malicious user can take control and execute arbitrary SQL functions as though you executed them. Substitute a call bearing the <literal>VARIADIC</literal> keyword, which bypasses this hazard. Calls populating <literal>VARIADIC "any"</literal> parameters often have no equivalent formulation containing the <literal>VARIADIC</literal> keyword. To issue those calls safely, the function's schema must permit only trusted users to create objects.[11] The reason for this step is to support function-style cast specifications in cases where there is not an actual cast function. If there is a cast function, it is conventionally named after its output type, and so there is no need to have a special case. See <xref linkend="sql-createcast"/> for additional commentary. この処理の理由は、実際にはキャスト関数が存在しない状況において、関数形態のキャスト仕様をサポートすることです。 キャスト関数が存在する場合、慣習的に出力型に因んで名付けられます。 ですので、特殊な状況を持つ必要はありません。 詳細な解説についてはCREATE CASTを参照してください。