ALTER OPERATOR FAMILY name USING index_method ADD
{ OPERATOR strategy_number operator_name ( op_type, op_type )
| FUNCTION support_number [ ( op_type [ , op_type ] ) ] funcname ( argument_type [, ...] )
} [, ... ]
ALTER OPERATOR FAMILY name USING index_method DROP
{ OPERATOR strategy_number ( op_type [ , op_type ] )
| FUNCTION support_number ( op_type [ , op_type ] )
} [, ... ]
ALTER OPERATOR FAMILY name USING index_method RENAME TO newname
ALTER OPERATOR FAMILY name USING index_method OWNER TO newownerALTER OPERATOR FAMILYは演算子族の定義を変更します。 演算子やサポート関数を演算子族に追加することやそれらを演算子族から削除すること、演算子族の名前や所有者を変更することが可能です。
ALTER OPERATOR FAMILYを使用して演算子とサポート関数が演算子族に追加される時、これらは演算子族内の特定の演算子クラスの一部とはならず、単に演算子族内で"自由"なものになります。 これは、これらの演算子と関数が演算子族と意味的な互換性を持つが、特定のインデックスの正しい動作には必要とされないことを意味します。 （代わりに必要な演算子と関数は演算子クラスの一部として宣言しなければなりません。CREATE OPERATOR CLASSを参照してください。） PostgreSQLでは演算子族の自由なメンバをいつでも演算子族から削除することができます。 しかし演算子クラス内のメンバは、クラス全体と依存するインデックスすべてを削除する以外に削除することはできません。 通常、単一データ型の演算子と関数は、特定のデータ型に対するインデックスをサポートするために必要ですので、演算子クラスの一部となります。 一方、データ型を跨る演算子と関数は、演算子族内の自由なメンバとなります。
ALTER OPERATOR FAMILYを使用するには、スーパーユーザでなければなりません （おかしな演算子族定義はサーバを混乱させクラッシュさせることがありますので、この制限がなされています）。
現時点ではALTER OPERATOR FAMILYは、インデックスメソッドで必要とされる演算子族がすべての演算子と関数を含んでいるかどうかを検査しません。 また、演算子と関数が自己制約集合を形成しているかどうかも検査しません。 有効な演算子族を定義することはユーザの責任です。
詳細は項34.14を参照してください。
既存の演算子族の名前です（スキーマ修飾可）。
演算子族が対象とするインデックスメソッドの名前です。
演算子族と関連した演算子に対するインデックスメソッドの戦略番号です。
演算子族と関連した演算子の名前です（スキーマ修飾可）。
OPERATOR句では演算子の入力データ型、または左単項演算子、右単項演算子を表すNONEです。 CREATE OPERATOR CLASSと類似の構文と異なり、入力データ型を常に指定しなければなりません。
ADD FUNCTIONでは、関数の入力データ型と異なる場合、関数がサポートする予定の入力データ型です。 関数の入力データ型は常に正しく使用するデータ型であるため、B-TreeおよびHashインデックスではop_typeを指定する必要がありません。 GINとGiSTインデックスでは、関数が使用する入力データ型を指定する必要があります。
DROP FUNCTION句では、関数がサポートする予定の入力データ型を指定しなければなりません。
演算子族に関連する関数用のインデックスメソッドのサポートプロシージャの番号です。
演算子族用のインデックスメソッドのサポートプロシージャとなる関数の名前です（スキーマ修飾名でも可）。
関数のパラメータのデータ型です。
演算子族の新しい名前です。
演算子族の新しい所有者です。
OPERATORとFUNCTION句は任意の順番で記述できます。
DROP構文が、戦略番号またはサポート番号と入力データ型という、演算子族の"スロット"のみを指定していることに注意してください。 そのスロットに存在する演算子または関数の名前については言及されません。 また、DROP FUNCTIONでは、指定する型は関数がサポートする予定の入力データ型です。 GINおよびGiSTインデックスでは、関数の実際の入力引数の型と関連しない可能性があります。
インデックス機構は使用する前に関数のアクセス権限を検査しません。 演算子族内の関数や演算子を含めることは、公的な実行権限を与えることと同じです。 これは通常、演算子族内で使用される関数では問題になりません。
演算子を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) ;