ALTER OPERATOR FAMILY — 演算子族の定義を変更する
ALTER OPERATOR FAMILYname
USINGindex_method
ADD { OPERATORstrategy_number
operator_name
(op_type
,op_type
) [ FOR SEARCH | FOR ORDER BYsort_family_name
] | FUNCTIONsupport_number
[ (op_type
[ ,op_type
] ) ]function_name
[ (argument_type
[, ...] ) ] } [, ... ] ALTER OPERATOR FAMILYname
USINGindex_method
DROP { OPERATORstrategy_number
(op_type
[ ,op_type
] ) | FUNCTIONsupport_number
(op_type
[ ,op_type
] ) } [, ... ] ALTER OPERATOR FAMILYname
USINGindex_method
RENAME TOnew_name
ALTER OPERATOR FAMILYname
USINGindex_method
OWNER TO {new_owner
| CURRENT_USER | SESSION_USER } ALTER OPERATOR FAMILYname
USINGindex_method
SET SCHEMAnew_schema
ALTER OPERATOR FAMILY
は演算子族の定義を変更します。
演算子やサポート関数を演算子族に追加することやそれらを演算子族から削除すること、演算子族の名前や所有者を変更することが可能です。
ALTER OPERATOR FAMILY
を使用して演算子とサポート関数が演算子族に追加される時、これらは演算子族内の特定の演算子クラスの一部とはならず、単に演算子族内で「自由」なものになります。
これは、これらの演算子と関数が演算子族と意味的な互換性を持つが、特定のインデックスの正しい動作には必要とされないことを意味します。
(必要な演算子と関数は演算子クラスの一部として宣言しなければなりません。
CREATE OPERATOR CLASSを参照してください。)
PostgreSQLでは演算子族の自由なメンバをいつでも演算子族から削除することができます。
しかし演算子クラス内のメンバは、クラス全体と依存するインデックスすべてを削除しなければ削除することはできません。
通常、単一データ型の演算子と関数は、特定のデータ型に対するインデックスをサポートするために必要ですので、演算子クラスの一部となります。
一方、データ型を跨る演算子と関数は、演算子族内の自由なメンバとなります。
ALTER OPERATOR FAMILY
を使用するには、スーパーユーザでなければなりません
(誤った演算子族定義はサーバを混乱させクラッシュさせることさえありますので、この制限がなされています)。
現時点ではALTER OPERATOR FAMILY
は、インデックスメソッドで必要とされる演算子族がすべての演算子と関数を含んでいるかどうかを検査しません。
また、演算子と関数が自身で整合性のある集合を形成しているかどうかも検査しません。
有効な演算子族を定義することはユーザの責任です。
詳細は38.15を参照してください。
name
既存の演算子族の名前です(スキーマ修飾可)。
index_method
演算子族が対象とするインデックスメソッドの名前です。
strategy_number
演算子族と関連した演算子に対するインデックスメソッドの戦略番号です。
operator_name
演算子族と関連した演算子の名前です(スキーマ修飾可)。
op_type
OPERATOR
句では演算子の入力データ型、または左単項演算子、右単項演算子を表すNONE
です。
CREATE OPERATOR CLASS
と類似の構文と異なり、入力データ型を常に指定しなければなりません。
ADD FUNCTION
句では、関数がサポートする予定の入力データ型です(関数の入力データ型と異なる場合)。
B-tree比較関数およびHash関数では、関数の入力データ型は常に正しく使用するデータ型であるため、op_type
を指定する必要がありません。
B-treeソートサポート関数とGiST、SP-GiST、GIN演算子クラスのすべての関数では、関数が使用する入力データ型を指定する必要があります。
DROP FUNCTION
句では、関数がサポートする予定の入力データ型を指定しなければなりません。
sort_family_name
順序付け演算子に関連するソート順序を記述する、既存のbtree
演算子族の名前(スキーマ修飾も可)です。
FOR SEARCH
もFOR ORDER BY
も指定されない場合、FOR SEARCH
がデフォルトです。
support_number
演算子族に関連する関数用のインデックスメソッドのサポート関数の番号です。
function_name
演算子族用のインデックスメソッドのサポート関数となる関数の名前です(スキーマ修飾名でも可)。 引数リストを指定しない場合、名前はスキーマ内で一意でなければなりません。
argument_type
関数のパラメータのデータ型です。
new_name
演算子族の新しい名前です。
new_owner
演算子族の新しい所有者です。
new_schema
演算子族の新しいスキーマです。
OPERATOR
とFUNCTION
句は任意の順番で記述できます。
DROP
構文が、戦略番号またはサポート番号と入力データ型という、演算子族の「スロット」のみを指定していることに注意してください。
そのスロットに存在する演算子または関数の名前については言及されません。
また、DROP FUNCTION
では、指定する型は関数がサポートする予定の入力データ型です。
GiST、SP-GiSTおよびGINインデックスでは、関数の実際の入力引数の型と関連しない可能性があります。
インデックス機構は使用する前に関数のアクセス権限を検査しません。 演算子族内の関数や演算子を含めることは、公的な実行権限を与えることと同じです。 これは通常、演算子族内で使用される関数では問題になりません。
演算子をSQL関数で定義してはいけません。 SQL関数はよく、呼び出し元の問い合わせ内でインライン展開されます。 すると、オプティマイザが問い合わせがインデックスに一致するかどうか認識できなくなります。
PostgreSQL 8.4より前までは、OPERATOR
句にRECHECK
オプションを含めることができました。
インデックス演算子に「損失がある」かどうかは実行時にその場で決定されるようになりましたので、これはサポートされなくなりました。
これにより、演算子に損失があるかもしれないしないかもしれないような場合を効率的に扱うことができるようになりました。
以下のコマンド例は、データ型を跨る演算子とサポート関数をint4
とint2
データ型用のB-Tree演算子クラスをすでに含む演算子族に追加します。
ALTER OPERATOR FAMILY integer_ops USING btree ADD -- int4 vs int2 OPERATOR 1 < (int4, int2) , OPERATOR 2 <= (int4, int2) , OPERATOR 3 = (int4, int2) , OPERATOR 4 >= (int4, int2) , OPERATOR 5 > (int4, int2) , FUNCTION 1 btint42cmp(int4, int2) , -- int2 vs int4 OPERATOR 1 < (int2, int4) , OPERATOR 2 <= (int2, int4) , OPERATOR 3 = (int2, int4) , OPERATOR 4 >= (int2, int4) , OPERATOR 5 > (int2, int4) , FUNCTION 1 btint24cmp(int2, int4) ;
これらの項目を再度削除します。
ALTER OPERATOR FAMILY integer_ops USING btree DROP -- int4 vs int2 OPERATOR 1 (int4, int2) , OPERATOR 2 (int4, int2) , OPERATOR 3 (int4, int2) , OPERATOR 4 (int4, int2) , OPERATOR 5 (int4, int2) , FUNCTION 1 (int4, int2) , -- int2 vs int4 OPERATOR 1 (int2, int4) , OPERATOR 2 (int2, int4) , OPERATOR 3 (int2, int4) , OPERATOR 4 (int2, int4) , OPERATOR 5 (int2, int4) , FUNCTION 1 (int2, int4) ;
標準SQLにはALTER OPERATOR FAMILY
文はありません。