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 树操作符族的族中。
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
语句。
如果您发现文档中有任何不正确的内容,与您使用特定功能的经验不符或需要进一步澄清,请使用此表单报告文档问题。