ALTER OPERATOR FAMILY — 更改运算符族的定义
ALTER OPERATOR FAMILYnameUSINGindex_methodADD { OPERATORstrategy_numberoperator_name(op_type,op_type) [ FOR SEARCH | FOR ORDER BYsort_family_name] | FUNCTIONsupport_number[ (op_type[ ,op_type] ) ]function_name[ (argument_type[, ...] ) ] } [, ... ] ALTER OPERATOR FAMILYnameUSINGindex_methodDROP { OPERATORstrategy_number(op_type[ ,op_type] ) | FUNCTIONsupport_number(op_type[ ,op_type] ) } [, ... ] ALTER OPERATOR FAMILYnameUSINGindex_methodRENAME TOnew_nameALTER OPERATOR FAMILYnameUSINGindex_methodOWNER TO {new_owner| CURRENT_ROLE | CURRENT_USER | SESSION_USER } ALTER OPERATOR FAMILYnameUSINGindex_methodSET 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 语句。
如果您在文档中发现任何不正确的内容，与您使用特定功能的体验不符，或者需要进一步澄清，请使用 此表单 报告文档问题。