"CREATE OPERATOR" SQL 11/05/95 日本語PostgreSQL 日本語PostgreSQL

名称

create operator - 新しいユーザ演算子を定義します

形式

create operator operator_name
	([ leftarg = type-1 ]
	 [ , rightarg = type-2 ]
	 , procedure = func_name
	 [, commutator = com_op ]
	 [, negator = neg_op ]
	 [, restrict = res_proc ]
	 [, hashes]
	 [, join = join_proc ]
	 [, sort = sor_op1 {, sor_op2 } ]
	)

説明

このコマンドは新しいユーザ演算子operator_nameを定義します。演算子を定義したユーザがその所有者になります。

operator_nameは連続して16文字までの句読点文字です。次の文字が1文字の演算子の名前として有効です:

~ ! @ # % ^ & ` ?
もし演算子の名前が 1文字よりも長いならば、上の文字の、または次の文字のどのような組合せでも可能です。

| $ : + - * / < > =
演算子 != は入力時に <> にマップされるので、同じ意味となります。

少なくとも leftargと rightargのどちらかが定義されなくてはなりません。バイナリの演算子は両方が定義されるべきです。右項演算子は、 arg1だけが定義され、左項演算子は arg2だけが定義されるでしょう。

演算子の名前 operator_nameは記号のみから成り立つことができます。また、 func_name手続きは前もって create function (l)で定義されていて、1つまたは2つの引数を取らなくてはなりません。

転換演算子(commutator)があることで、 Postgres がオペランドの順番を逆にすることができます。例えば、演算子のエリアがより小さい >>> には転換演算子エリアがより大きい <<<があるでしょう。演算子エリアが等しい === と、エリアが等しくない !== があったとしましょう。ここで、問い合わせ最適化機構は自由に変換をすることができます:

0,0,1,1::box >>> MYBOXES.description
を

MYBOXES.description <<< 0,0,1,1::box
にできるのです。これは実行コードをいつも後者の表現を使うようにでき、若干問い合わせ最適化を単純にできます。

否定(negator)演算子は問い合わせ最適化機構に以下の変換を許します。

NOT MYBOXES.description === 0,0,1,1::box
を

MYBOXES.description !== 0,0,1,1::box
にします。もし転換(commutator)演算子の名前が与えられると、 Postgres はカタログを探します。もし見つかって、しかもそれが転換(commutator)演算子を自身に持っていなければ、その転換演算子のエントリは現在の(新規)演算子がそれ自身の転換演算子として更新されます。これは否定(negator)にもあてはまります。

これで互いに転換(commutator)あるいは否定(negator)の関係にある 2つの演算子を定義できます。最初の演算子は転換(commutator)あるいは否定(negator)なしで(適切に) 定義します。そして 2番目の演算子を定義する時に最初の演算子を転換(commutator)あるいは否定(negator)とします。最初の演算子はその副作用として更新されることになります。

次の 2つの記述があると問い合わせ最適化機構は結合を実行することをサポートします。 Postgres は常に結合を評価するのに(つまり、 2つのタプル変数が boolean を返す演算子によって分けられている句を処理することです)反復代用を使います[WONG76]。加えて、Postgres は [SHAP86] の行に従ってハッシュ結合のアルゴリズムをインプリメントするプランをしますが、しかし、この手順が適用できるかどうかを知らなくてはなりません。例えば、ハッシュ結合のアルゴリズムは次のようなフォームの句:

MYBOXES.description === MYBOXES2.description
には使えますが、次のようなフォームの句:

MYBOXES.description <<< MYBOXES2.description.
には使えません。 ハッシュ フラッグは質問の演算子にハッシュ結合の手段が使えるかどうかを心配する問い合わせ最適化機構に必要な情報を与えます。

同様に、2つの並べ変え演算子は、問い合わせ最適化機構にマージソートが結合手順が使えるかどうかと 2つのオペランドクラスを並べ変えるのにどの演算子を使うべきかを示します。上記の === 句には、最適化機構は両リレーションを演算子 <<< を使って並べ変えます。一方で、マージソートは次の句では使えません:

MYBOXES.description <<< MYBOXES2.description
もし違う結合手順が現実的であると見つけたら、 Postgres は最適化機構と実行システムを変更してそれらを使うようにし、演算子が定義されると付加的な記述を要求します。幸い、まれに研究団体が新しい結合手順を発明するので、ユーザ定義の結合手順で加えられた普遍性が複雑さを伴うだけの価値があると思えません。

最後の 2つの記述があると、問い合わせ最適化機構は結果のサイズを評価します。次のようなフォームの句:

MYBOXES.description <<< 0,0,1,1::box
が制約句にあると、Postgres はMYBOXES のインスタンスの断片がその句を満たすかどうかを評価しなくてはならないでしょう。正しいデータ型の 1つの引数を取り、小数を返す関数 res_proc は登録された関数でなくてはなりません。 (これは既に define function (l)で定義されているということを意味します。) 問い合わせ最適化機構はパラメータ 0,0,1,1 を渡して単にこの関数を呼び出し、その結果をリレーションのサイズに掛け合わせて望ましいインスタンスの数を得ます。

同様に、演算子のオペランドが両方ともインスタンス変数を含んでいる時、問い合わせ最適化機構は結合の結果のサイズを評価しなくてはなりません。関数 join_proc は望ましい結果のサイズを計算する 2つのクラスの重要性を掛け合わせられる小数を返します。

関数

my_procedure_1 (MYBOXES.description, 0,0,1,1::box)
と演算子

MYBOXES.description === 0,0,1,1::box
との違いは、 Postgres が演算子を最適化しようと試み、演算子が関係する検索スペースを制限するインデックスを使おうとすることです。しかし、関数を最適化することは試されず、力ずくで処理されます。さらに、関数はどんな数の引数も取れますが、演算子は1つか2つに制限されています。

例

-- -- 次のコマンドは BOX データ型のための -- 新しい演算子 area_equal_procedure を定義します。 -- create operator === ( leftarg = box, rightarg = box, procedure = area_equal_procedure, commutator = ===, negator = !==, restrict = area_restriction_procedure, hashes, join = area-join-procedure, sort = <<<, <<<)

参照

function(l) ,operator(l) .

バグ

Postgres では演算子の名前にアルファベットを含めることができません。

演算子が、その転換演算子が定義される前に定義されると(特に上に対して警告されたケース)、無効なフィールドのダミーの演算子がシステムカタログに置かれます。これは後の演算子の定義を妨げることがあります。