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)