10.2. 演算子

例 10-1. 階乗演算子の型解決

階乗演算子として、bigintを引数とするものが標準カタログ内に1つのみ定義されています（!を後に付けます）。 スキャナは、以下の問い合わせ式の引数にまずinteger型を割り当てます。

SELECT 40 ! AS "40 factorial";

                   40 factorial
--------------------------------------------------
 815915283247897734345611269596115894272000000000
(1 row)

パーサはオペランドを型変換し、問い合わせは以下と等価になります。

SELECT CAST(40 AS bigint) ! AS "40 factorial";

例 10-2. 文字列連結演算子の型解決

文字列類似構文は、文字列の作業の他、複雑な拡張型の作業にも使用されます。 型の指定がない文字列は、類似演算子候補に一致します。

例えば、以下は指定がない引数が1つあります。

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

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

この場合、パーサは両引数でtextを取る演算子があるかどうかを検索します。 この演算子は存在しますので、第二引数はtext型として解釈されるものと仮定されます。

以下は型の指定がない2つの値の連結です。

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

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

この場合、問い合わせ内に型が指定されていませんので、どの型を使用すべきかについての初期の指針がありません。 ですから、パーサは全ての演算子候補を検索し、文字列カテゴリとビット列カテゴリ入力を受け付ける候補を見つけます。 使用できる場合は文字列カテゴリが優先されますので、文字列カテゴリが選択され、それからその好ましい型であるtextが、不明のリテラルを解決する型として使用されます。

例 10-3. 絶対値と否定演算子の型解決

PostgreSQLの演算子カタログには、前置演算子@用に複数の項目があります。 これは全て各種数値データ型に対する絶対値計算を実装するものです。 その1つは、数値カテゴリの好ましい型であるfloat8型用の項目です。 したがって、PostgreSQLは、unknownの入力があった場合にこれを使用します。

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

ここでシステムは、選択した演算子を適用する前に、unknown型のリテラルをfloat8へ暗黙的に型変換します。 以下のようにfloat8が使用され、他の型が使用されていないことを検証することができます。

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

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

一方、前置演算子~（ビット否定）は、整数データ型のみで定義され、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.

これは、システムが、複数の~演算子候補のうちどれが好ましいかを決定することができなかったため発生します。 明示的なキャストを使用することで補助することができます。

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

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

例 10-4. 配列包含演算子の型解決

一方は既知でありもう一方は未知である入力を伴った演算子の解決のもう一つの例です。

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

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

PostgreSQLの演算子カタログは、<@中置演算子のためのいくつかのエントリを持っていますが、 数値型配列を左側に受け付けることができるのは配列包含(anyarray <@ anyarray)と範囲包含(anyelement <@ anyrange)の2つのみです。 これらの多様な擬似データ型項8.20を参照は好ましいと見なされないため、このような方法ではパーサは曖昧さを解決することができません。 しかし、ステップ3.fでは、未知の型のリテラルを別の入力と同じ型であると仮定するために数値配列とみなします。 今のところ2つのうち一つの演算子だけがマッチできるため、配列包含が選択されます。(範囲包含が選択された場合、演算子の右側にある文字列は正しい範囲型のリテラルではないため、エラーとなるでしょう。)

例 10-5. ドメイン型の独自の演算子

利用者は時々ドメイン型にのみ適用される演算子を宣言しようとします。 これは可能ですが、思ったほど便利ではありません。演算子の解決規則がドメイン基本型に適用される演算子を選ぶように設計されているからです。 例として、以下を考えてください。

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';

この問い合わせは独自の演算子を使いません． パーサはまずmytext = mytext演算子(ステップ2.a)があるか確認しますが、ありません。次にドメイン基本型textを考慮してtext = text演算子(ステップ2.b)があるか確認すると、あります。そのためunknown型はtextとして解決され、text = text演算子が使われます。 独自の演算子を使う唯一の方法は、「正確な一致」規則に従ってmytext = text演算子がすぐに見つかるように、リテラルを明示的にキャストすることだけです。

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

もし、「最善の一致」規則に達した場合、ドメイン型の演算子を積極的に差別します。 そうでなければ、そのような演算子は非常に多くの「曖昧な演算子」の失敗を引き起こします。キャストの規則はドメインをその基本型からもしくは基本型へキャスト可能と考え、ドメイン演算子は基本型の似たような名前の演算子とすべて同じ状況で利用できると考えられるからです。