ALTER OPERATOR FAMILY · PostgreSQL 中文文檔 9.3

# ALTER OPERATOR FAMILY ## Name ALTER OPERATOR FAMILY?--?修改操作符族的定義 ## Synopsis ``` ALTER OPERATOR FAMILY _name_ USING _index_method_ ADD { OPERATOR _strategy_number_ _operator_name_ ( _op_type_, _op_type_ ) [ FOR SEARCH | FOR ORDER BY _sort_family_name_ ] | FUNCTION _support_number_ [ ( _op_type_ [ , _op_type_ ] ) ] _function_name_ ( _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 _new_name_ ALTER OPERATOR FAMILY _name_ USING _index_method_ OWNER TO _new_owner_ ALTER OPERATOR FAMILY _name_ USING _index_method_ SET SCHEMA _new_schema_ ``` ## 描述 `ALTER OPERATOR FAMILY`修改一個操作符族的定義。你可以添加操作符和支持函數到該族、從該族中刪除它們或修改該族的名字或所有者。當使用`ALTER OPERATOR FAMILY`添加操作符和支持函數到一個族時，它們不是該操作符族中任意指定操作符類的一部分，只是"松散"在該族中。這表明這些操作符和函數與該族的語義兼容，但不是正確運行任何指定索引的所需。（操作符和函數要成為索引的所需，應該被聲明為一個操作符類的一部分；參閱 [CREATE OPERATOR CLASS](#calibre_link-53)。）PostgreSQL 將允許一個族的松散成員在任何時候被從該族中刪除，但是操作符類的成員不能被刪除，除非刪除整個類和任何依賴于它的索引。典型的，單數據類型操作符和函數是操作符類的一部分，因為需要它們支持一個特定數據類型的索引，而交叉數據類型操作符和函數由族的松散成員組成。要使用`ALTER OPERATOR FAMILY`，你必須是一個超級用戶。（做這個限制是因為一個錯誤的操作符族定義會混淆或者甚至崩潰服務器。） `ALTER OPERATOR FAMILY` 目前并不檢查操作符族定義是否包括索引方法所需的所有操作符和函數，也不檢查操作符和函數是否來自一個自相一致的集合。定義一個有效的操作符族是用戶的責任。參閱[Section 35.14](#calibre_link-54)獲取更多信息。 ## 參數 `_name_` 一個現有操作符族的名字（可以有模式修飾）。 `_index_method_` 使用這個操作符族的索引方法的名字。 `_strategy_number_` 該索引方法的與該操作符族相關的一個操作符的策略數。 `_operator_name_` 與該操作符族相關的一個操作符的名字（可以有模式修飾）。 `_op_type_` 在一個`OPERATOR`子句中，該操作符的操作數的數據類型或`NONE` 表示一個左目或右目操作符。不像`CREATE OPERATOR CLASS` 中可比較的語法，必須總是指定操作數的數據類型。在一個`ADD FUNCTION`子句中，函數的操作數的數據類型如果與該函數的輸入數據類型不同，則打算支持操作數的數據類型。對于B-tree比較函數和哈希函數，不需要指定 `_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`語句。 ## 又見 [CREATE OPERATOR FAMILY](#calibre_link-11), [DROP OPERATOR FAMILY](#calibre_link-56), [CREATE OPERATOR CLASS](#calibre_link-53), [ALTER OPERATOR CLASS](#calibre_link-57), [DROP OPERATOR CLASS](#calibre_link-58)