ALTER OPERATOR FAMILYは、オペレータファミリの定義を変更します。
説明
演算子とサポート機能をファミリに追加したり、ファミリから削除したり、ファミリの名前や所有者を変更したりできます。
演算子とサポート機能がALTER OPERATOR familyを持つファミリに追加された場合、それらはファミリ内の特定の演算子クラスの一部ではなく、ファミリ内で「緩い」だけです。 これは、これらの演算子と関数がファミリのセマンティクスと互換性があるが、特定のインデックスが正しく機能するためには必要ないことを示しています。 (そのように必要な演算子と関数は、代わりに演算子クラスの一部として宣言する必要があります。「演算子クラスの作成」をご参照ください。) PostgreSQLでは、ファミリーの緩いメンバーをいつでもファミリーから削除できますが、クラス全体とそれに依存するインデックスを削除せずに演算子クラスのメンバーを削除することはできません。 通常、単一データ型の演算子と関数は、その特定のデータ型のインデックスをサポートする必要があるため、演算子クラスの一部ですが、クロスデータ型の演算子と関数は、ファミリーの緩いメンバーになります。
ALTER OPERATOR FAMILYを使用するには、スーパーユーザーである必要があります。 (この制限は、誤ったオペレータファミリ定義がサーバーを混乱させたり、クラッシュさせたりする可能性があるためです。)
ALTER OPERATOR FAMILYは、現在、演算子ファミリ定義がインデックスメソッドによって必要とされるすべての演算子および関数を含むかどうか、または演算子および関数が自己矛盾のないセットを形成するかどうかをチェックしない。 有効なオペレータファミリを定義するのはユーザの責任です。
概要
ALTER OPERATOR FAMILY名USING index_method ADD
{OPERATOR strategy_number operator_name ( op_type, op_type)
[FOR SEARCH | 注文のためにsort_family_name]
| FUNCTION support_number [ ( op_type [ , op_type ] ) ]
function_name [ ( argument_type [, ...] ) ]
} [, ... ]
ALTER OPERATOR FAMILY名USING index_method DROP
{OPERATOR strategy_number ( op_type [ , op_type ] )
| FUNCTION support_number ( op_type [ , op_type ] )
} [, ... ]
ALTER OPERATOR FAMILY名USING index_method
new_nameに名前を付ける
ALTER OPERATOR FAMILY名USING index_method
{new_owner | CURRENT_USER | SESSION_USER} への所有者
ALTER OPERATOR FAMILY名USING index_method
SET SCHEMA new_schema パラメーター
name: 既存の演算子ファミリの名前 (オプションでスキーマ修飾) 。
index_method: この演算子ファミリーのインデックスメソッドの名前。
strateg_number: 演算子ファミリーに関連付けられた演算子のインデックスメソッドの戦略番号。
operator_name: 演算子ファミリーに関連付けられた演算子の名前 (スキーマ修飾) 。
op_type: OPERATOR句で、演算子のオペランドデータ型、またはプレフィックス演算子を示すNONE。 CREATE OPERATOR CLASSの同等の構文とは異なり、オペランドデータ型は常に指定する必要があります。
ADD FUNCTION句では、関数の入力データ型と異なる場合、関数がサポートすることが意図されているオペランドデータ型。 Bツリー比較関数とハッシュ関数の場合、関数の入力データ型は常に正しいものであるため、op_typeを指定する必要はありません。 Bツリー・ソート・サポート関数、Bツリー・イクイル・イメージ関数、およびGiST、SP-GiST、およびGIN演算子クラスのすべての関数では、関数が使用されるオペランド・データ・タイプを指定する必要があります。 DROP FUNCTION句では、関数がサポートするオペランドデータ型を指定する必要があります。
sort_family_name: 順序付け演算子に関連付けられたソート順序を記述する既存のbtree演算子ファミリーの名前 (オプションでスキーマ修飾) 。
FOR SEARCHもFOR ORDER BYも指定されていない場合、FOR SEARCHがデフォルトです。
support_number: 演算子ファミリに関連付けられた関数のインデックスメソッドのサポート関数番号。
function_name: 演算子ファミリーのインデックスメソッドサポート関数である関数の名前 (オプションでスキーマ修飾) 。 引数リストを指定しない場合、名前はスキーマ内で一意である必要があります。
argum_type: 関数のパラメーターデータ型。
new_name: 演算子ファミリーの新しい名前。
new_owner: オペレーターファミリーの新しい所有者。
new_schema: 演算子ファミリーの新しいスキーマです。
OPERATORおよびFUNCTION句は、任意の順序で表示できます。
注
DROP構文は、戦略またはサポート番号と入力データ型によって、演算子ファミリの「スロット」のみを指定することに注意してください。 スロットを占有する演算子または機能の名前は記載されていない。 また、DROP FUNCTIONの場合、指定する型は、関数がサポートすることを意図した入力データ型です。GiST、SP-GiST、およびGINインデックスの場合、これは関数の実際の入力引数型とは関係ありません。
インデックスマシンは、関数を使用する前に関数のアクセス許可をチェックしないため、演算子ファミリーに関数または演算子を含めることは、その関数に対するパブリック実行許可を付与することと同じです。 これは通常、演算子ファミリで役立つ関数の種類では問題になりません。
演算子はSQL関数で定義しないでください。 SQL関数は、呼び出し元のクエリにインライン化される可能性があります。これにより、オプティマイザは、クエリがインデックスに一致することを認識できなくなります。
例
次のコマンド例では、データtypesint4andint2のBツリー演算子クラスが既に含まれている演算子ファミリに、クロスデータ型演算子とサポート関数を追加します。
btree ADDを使用してALTER OPERATOR FAMILY integer_ops
-- int4 vs int2
オペレーター1 < (int4、int2) 、
オペレーター2 <= (int4、int2) 、
オペレーター3 = (int4、int2) 、
オペレーター4 >= (int4、int2) 、
オペレーター5 > (int4、int2) 、
関数1 btint42cmp(int4、int2) 、
-- int2 vs int4
オペレーター1 < (int2、int4) 、
オペレーター2 <= (int2、int4) 、
オペレーター3 = (int2、int4) 、
オペレーター4 >= (int2、int4) 、
オペレーター5 > (int2、int4) 、
機能1 btint24cmp(int2、int4) ; これらのエントリを再度削除するには:
btreeドロップを使用してALTER OPERATOR FAMILY integer_ops
-- int4 vs int2
オペレーター1 (int4、int2) 、
オペレーター2 (int4、int2) 、
オペレーター3 (int4、int2) 、
オペレーター4 (int4、int2) 、
オペレーター5 (int4、int2) 、
関数1 (int4、int2) 、
-- int2 vs int4
オペレーター1 (int2、int4) 、
オペレーター2 (int2、int4) 、
オペレーター3 (int2、int4) 、
オペレーター4 (int2、int4) 、
オペレーター5 (int2、int4) 、
機能1 (int2、int4) ;