ALTER OPERATOR FAMILY - 更改运算符系列的定义
ALTER OPERATOR FAMILYname
USINGindex_method
ADD { OPERATORstrategy_number
operator_name
(op_type
,op_type
) [ FOR SEARCH | FOR ORDER BYsort_family_name
] | FUNCTIONsupport_number
[ (op_type
[ ,op_type
] ) ]function_name
[ (argument_type
[, ...] ) ] } [, ... ] ALTER OPERATOR FAMILYname
USINGindex_method
DROP { OPERATORstrategy_number
(op_type
[ ,op_type
] ) | FUNCTIONsupport_number
(op_type
[ ,op_type
] ) } [, ... ] ALTER OPERATOR FAMILYname
USINGindex_method
RENAME TOnew_name
ALTER OPERATOR FAMILYname
USINGindex_method
OWNER TO {new_owner
| CURRENT_ROLE | CURRENT_USER | SESSION_USER } ALTER OPERATOR FAMILYname
USINGindex_method
SET SCHEMAnew_schema
ALTER OPERATOR FAMILY
更改运算符系列的定义。可以向该系列添加运算符和支持函数,从该系列中删除它们,或者更改该系列的名称或所有者。
当操作符和支持函数使用 ALTER OPERATOR FAMILY
添加到具有一个系列,它们不是系列内任何特定操作符类的部分,而是在系列内只是“松散”的。这表明这些操作符和函数与系列语义兼容,但不是任何特定索引正确功能所必需的。(在此必需的操作符和函数应声明为操作符类的部分;请参见 CREATE OPERATOR CLASS。) PostgreSQL 将允许系列的松散成员在任何时候从系列中删除,但操作符类的成员不能删除,除非删除整个类以及依赖它的任何索引。通常,单数据类型操作符和函数是操作符类的部分,因为它们是所支持特定数据类型的索引所必需的,而跨数据类型操作符和函数构成了系列的松散成员。
您必须是超级用户才能使用 ALTER OPERATOR FAMILY
。(此限制之所以存在,是因为错误的操作符系列定义会使服务器陷入混乱甚至崩溃)。
ALTER OPERATOR FAMILY
目前不会检查操作符系列定义是否包括索引方法所需的全部操作符和函数,也不会检查操作符和函数是否形成自洽集合。定义有效操作符系列是用户的责任。
请参考 第 36.16 节 了解详细信息。
name
现有操作符系列的名称(可选模式限定)。
index_method
此操作符系列所属的索引方法的名称。
strategy_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
作为运算符系列的索引方法支持函数的名称(可选模式限定)。如果未指定参数列表,则名称在其模式中必须唯一。
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
语句。