There is only one square root operator (prefix <literal>|/</literal>) defined in the standard catalog, and it takes an argument of type <type>double precision</type>. The scanner assigns an initial type of <type>integer</type> to the argument in this query expression: 平方根演算子として、double precisionを引数とするものが標準カタログ内に1つのみ定義されています（|/を前に付けます）。 スキャナは、以下の問い合わせ式の引数にまずinteger型を割り当てます。

SELECT |/ 40 AS "square root of 40";
 square root of 40
-------------------
 6.324555320336759
(1 row)

So the parser does a type conversion on the operand and the query is equivalent to: パーサはオペランドを型変換し、問い合わせは以下と等価になります。

SELECT |/ CAST(40 AS double precision) AS "square root of 40";

A string-like syntax is used for working with string types and for working with complex extension types. Strings with unspecified type are matched with likely operator candidates. 文字列類似構文は、文字列の作業の他、複雑な拡張型の作業にも使用されます。 型の指定がない文字列は、類似演算子候補に一致します。

An example with one unspecified argument: 例えば、以下は指定がない引数が1つあります。

SELECT text 'abc' || 'def' AS "text and unknown";

 text and unknown
------------------
 abcdef
(1 row)

In this case the parser looks to see if there is an operator taking <type>text</type> for both arguments. Since there is, it assumes that the second argument should be interpreted as type <type>text</type>. この場合、パーサは両引数でtextを取る演算子があるかどうかを検索します。 この演算子は存在しますので、第二引数はtext型として解釈されるものと仮定されます。

Here is a concatenation of two values of unspecified types: 以下は型の指定がない2つの値の連結です。

SELECT 'abc' || 'def' AS "unspecified";

 unspecified
-------------
 abcdef
(1 row)

In this case there is no initial hint for which type to use, since no types are specified in the query. So, the parser looks for all candidate operators and finds that there are candidates accepting both string-category and bit-string-category inputs. Since string category is preferred when available, that category is selected, and then the preferred type for strings, <type>text</type>, is used as the specific type to resolve the unknown-type literals as. この場合、問い合わせ内に型が指定されていませんので、どの型を使用すべきかについての初期の指針がありません。 ですから、パーサは全ての演算子候補を検索し、文字列カテゴリとビット列カテゴリ入力を受け付ける候補を見つけます。 使用できる場合は文字列カテゴリが優先されますので、文字列カテゴリが選択され、それから文字列に対して優先される型であるtextが、不明のリテラルを解決する型として使用されます。

The <productname>PostgreSQL</productname> operator catalog has several entries for the prefix operator <literal>@</literal>, all of which implement absolute-value operations for various numeric data types. One of these entries is for type <type>float8</type>, which is the preferred type in the numeric category. Therefore, <productname>PostgreSQL</productname> will use that entry when faced with an <type>unknown</type> input: PostgreSQLの演算子カタログには、前置演算子@用に複数の項目があります。 これは全て各種数値データ型に対する絶対値計算を実装するものです。 その1つは、数値カテゴリの優先される型であるfloat8型用の項目です。 したがって、PostgreSQLは、unknownの入力があった場合にこれを使用します。

SELECT @ '-4.5' AS "abs";
 abs
-----
 4.5
(1 row)

Here the system has implicitly resolved the unknown-type literal as type <type>float8</type> before applying the chosen operator. We can verify that <type>float8</type> and not some other type was used: ここでシステムは、選択した演算子を適用する前に、unknown型のリテラルをfloat8へ暗黙的に型変換します。 以下のようにfloat8が使用され、他の型が使用されていないことを検証できます。

SELECT @ '-4.5e500' AS "abs";

ERROR:  "-4.5e500" is out of range for type double precision

On the other hand, the prefix operator <literal>~</literal> (bitwise negation) is defined only for integer data types, not for <type>float8</type>. So, if we try a similar case with <literal>~</literal>, we get: 一方、前置演算子~（ビット否定）は、整数データ型のみで定義され、float8用は定義されていません。 ですから、~における上と同様の場合では、以下のような結果になります。

SELECT ~ '20' AS "negation";

ERROR:  operator is not unique: ~ "unknown"
HINT:  Could not choose a best candidate operator. You might need to add
explicit type casts.

This happens because the system cannot decide which of the several possible <literal>~</literal> operators should be preferred. We can help it out with an explicit cast: これは、システムが、複数の~演算子候補のうちどれが優先されるかを決定することができなかったため発生します。 明示的なキャストを使用することで補助することができます。

SELECT ~ CAST('20' AS int8) AS "negation";

 negation
----------
      -21
(1 row)

Here is another example of resolving an operator with one known and one unknown input: 一方は既知でありもう一方は未知である入力を伴った演算子の解決のもう一つの例です。

SELECT array[1,2] <@ '{1,2,3}' as "is subset";

 is subset
-----------
 t
(1 row)

The <productname>PostgreSQL</productname> operator catalog has several entries for the infix operator <literal>&lt;@</literal>, but the only two that could possibly accept an integer array on the left-hand side are array inclusion (<type>anyarray</type> <literal>&lt;@</literal> <type>anyarray</type>) and range inclusion (<type>anyelement</type> <literal>&lt;@</literal> <type>anyrange</type>). Since none of these polymorphic pseudo-types (see <xref linkend="datatype-pseudo"/>) are considered preferred, the parser cannot resolve the ambiguity on that basis. However, <xref linkend="op-resol-last-unknown"/> tells it to assume that the unknown-type literal is of the same type as the other input, that is, integer array. Now only one of the two operators can match, so array inclusion is selected. (Had range inclusion been selected, we would have gotten an error, because the string does not have the right format to be a range literal.) PostgreSQLの演算子カタログは、<@中置演算子のためのいくつかのエントリを持っていますが、 数値型配列を左側に受け付けることができるのは配列包含(anyarray <@ anyarray)と範囲包含(anyelement <@ anyrange)の2つのみです。 これらの多様な擬似データ型(8.21を参照)は優先されると見なされないため、このような方法ではパーサは曖昧さを解決することができません。 しかし、ステップ 3.fでは、未知の型のリテラルを別の入力と同じ型であると仮定するために数値配列とみなします。 今のところ2つのうち一つの演算子だけがマッチできるため、配列包含が選択されます。(範囲包含が選択された場合、演算子の右側にある文字列は正しい範囲型のリテラルではないため、エラーとなるでしょう。)

Users sometimes try to declare operators applying just to a domain type. This is possible but is not nearly as useful as it might seem, because the operator resolution rules are designed to select operators applying to the domain's base type. As an example consider 利用者はときどきドメイン型にのみ適用される演算子を宣言しようとします。 これは可能ですが、思ったほど便利ではありません。演算子の解決規則がドメイン基本型に適用される演算子を選ぶように設計されているからです。 例として、以下を考えてください。

CREATE DOMAIN mytext AS text CHECK(...);
CREATE FUNCTION mytext_eq_text (mytext, text) RETURNS boolean AS ...;
CREATE OPERATOR = (procedure=mytext_eq_text, leftarg=mytext, rightarg=text);
CREATE TABLE mytable (val mytext);

SELECT * FROM mytable WHERE val = 'foo';

This query will not use the custom operator. The parser will first see if there is a <type>mytext</type> <literal>=</literal> <type>mytext</type> operator (<xref linkend="op-resol-exact-unknown"/>), which there is not; then it will consider the domain's base type <type>text</type>, and see if there is a <type>text</type> <literal>=</literal> <type>text</type> operator (<xref linkend="op-resol-exact-domain"/>), which there is; so it resolves the <type>unknown</type>-type literal as <type>text</type> and uses the <type>text</type> <literal>=</literal> <type>text</type> operator. The only way to get the custom operator to be used is to explicitly cast the literal: この問い合わせには独自の演算子を使いません。 パーサはまずmytext = mytext演算子（ステップ 2.a）があるか確認しますが、ありません。次にドメイン基本型textを考慮してtext = text演算子（ステップ 2.b）があるか確認すると、あります。そのためunknown型はtextとして解決され、text = text演算子が使われます。 独自の演算子を使う唯一の方法は、リテラルを明示的にキャストすることだけです。

SELECT * FROM mytable WHERE val = text 'foo';

so that the <type>mytext</type> <literal>=</literal> <type>text</type> operator is found immediately according to the exact-match rule. If the best-match rules are reached, they actively discriminate against operators on domain types. If they did not, such an operator would create too many ambiguous-operator failures, because the casting rules always consider a domain as castable to or from its base type, and so the domain operator would be considered usable in all the same cases as a similarly-named operator on the base type. これにより、「正確な一致」規則に従ってmytext = text演算子がすぐに見つかります。 もし、「最善の一致」規則に達した場合、ドメイン型の演算子を積極的に差別します。 そうでなければ、そのような演算子は非常に多くの「曖昧な演算子」の失敗を引き起こします。キャストの規則はドメインをその基本型からもしくは基本型へキャスト可能と考え、ドメイン演算子は基本型の似たような名前の演算子とすべて同じ状況で利用できると考えられるからです。