ALTER OPERATOR FAMILY

名字

ALTER OPERATOR FAMILY -- 修改一个操作符族的定义

语法概要

   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。）

PostgreSQL 允许在任意时刻将这些松散关系的成员移除出族，但是要移除操作符类的成员的话需要首先移除整个操作符类和所有依赖这个类的索引。一般来说，操作单一数据类型的操作符和函数应该作为操作符类的一部分，因为针对特定数据类型的索引需要这些东西的支持；而操作不同数据类型的操作符和函数应该作为族的松散成员。

只有超级用户可以使用 ALTER OPERATOR FAMILY 命令。（有错误的操作符族定义会扰乱服务器，甚至将服务器down掉，所以会有这一条限制。）

ALTER OPERATOR FAMILY 不会在定义时检查操作符族的定义是否包含索引方法需要的所有操作符和函数，也不会马上检查操作符和函数是否形成自相容集（无矛盾的，一致的）。定义一个正确的操作符族是用户的责任。

更多信息请参考 9.1第三十五章 。

参数

name

现有操作符族的名字。（可以有模式修饰）

index_method

使用该操作符族的索引方法的名字。

strategy_number

族中的操作符所关联的索引方法的策略号。

operator_name

族中的操作符的名字，可以有模式修饰。

op_type

OPERATOR 子句中操作符操作的数据类型，或者在单目操作符的时候用NONE占位。 比较CREATE OPERATOR CLASS命令的语法，操作数的数据类型必须设置。

ADD FUNCTION 子句中，如果函数支持的操作数的数据类型与输入数据类型不一样，需指定操作数的数据类型。B树和散列索引不需要设定op_type 因为函数的输入数据类型就是操作数的数据类型。GIN和GiST索引就需要设定函数使用的输入数据类型。

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命令指定的类型是函数支持的输入数据的类型；对于GIN和GiST索引如果没指定函数的实际输入参数类型的话，可能命令就没有效果。

由于索引机制在使用之前并不检查函数的访问权限，所有往操作符族中添加函数和操作符等价于给它们授予public的执行权限。这个权限放在操作符族的函数上一般不会造成什么问题。

操作符的定义中不要使用SQL函数。SQL函数一般会内联在查询里面，这样做会阻止优化器识别查询是否可以使用索引。

PostgreSQL 8.4之前，OPERATOR 子句需要包含一个 RECHECK 选项。现在不再支持这个选项了，因为索引操作符是否需要recheck在运行期自动检测。这样在操作符需不需要recheck时都能高效的处理。

示例

下面的示例命令将操作不同数据类型的操作符和支撑函数添加到一个操作符族里去（这个操作符族已经包含有针对int4和int2类型的B树操作符类）。

   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, DROP OPERATOR FAMILY, CREATE OPERATOR CLASS, ALTER OPERATOR CLASS, DROP OPERATOR CLASS