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
目前不检查运算符族定义是否包括索引方法所需的所有运算符和函数,也不检查运算符和函数是否形成自洽的集合。定义有效的运算符族是用户的责任。
有关详细信息,请参阅 第 38.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 树运算符类的运算符族。
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
语句。