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 | CURRENT_USER | SESSION_USER }
ALTER OPERATOR FAMILY name USING index_method
SET SCHEMA new_schemaALTER OPERATOR FAMILY更改一个操作符族的定义。 你能增加操作符以及支持函数到该家族、从该族中移除它们或者更改该族的名称或者拥有者。
在用ALTER OPERATOR FAMILY增加操作符和支持函数到一个族中时， 它们不是族内任何特定操作符类的组成部分，而只是"松散"地存在于该族中。 这表示这些操作符和函数与该族的语义兼容，但是没有被任何特定索引的正确功能所要求 （所要求的操作符和函数应该被作为一个操作符类的一部分声明， 见CREATE OPERATOR CLASS）。PostgreSQL 将允许一个族的松散成员在任何时候被从该族中删除，但是在删除一个操作符类的成员之前， 必须已经删除整个类以及依赖于该成员的索引。具有代表性的是， 单一数据类型操作符和函数是操作符类的一部分，因为在特定数据类型上的索引需要它们的支持。 而跨数据类型操作符和函数则被作为该族的松散成员。
要使用ALTER OPERATOR FAMILY，你必须是超级用户（ 做这样的限制是因为一个错误的操作符族定义可能会迷惑服务器甚至让它崩溃）。
ALTER OPERATOR FAMILY 目前不检测操作符族定义是否包括该索引方法所要求的所有操作符和函数， 也不检查操作符和函数是否来自一个自我一致的集合。定义一个有效的操作符族是用户的责任。
进一步的信息请参考第 35.14 节。
一个现有操作符族的名称（可以是模式限定的）。
这个操作符族所应用的索引方法的名称。
与该操作符族相关的一个操作符的索引方法策略号。
与该操作符族相关的一个操作符的名称（可以是模式限定的）。
在一个OPERATOR子句中，操作符的操作数数据类型， 或者用NONE来表示一个左一元或者右一元操作符。 不同于CREATE OPERATOR CLASS中可比较语法， 操作数数据类型必须总是被指定。
在一个ADD FUNCTION子句中指定该函数意图支持的操作数数据类型 （如果不同于该函数的输入数据类型）。对于 B-树比较函数和哈希函数， 没有必要指定op_type， 因为该函数的输入数据类型总是正确的。对于 B-树排序支持函数和 GiST、SP-GiST 和 GIN 操作符类中的所有函数，有必要指定该函数要使用的操作数数据类型。
在一个DROP FUNCTION子句中，必须指定该函数要支持的操作数数据类型。
一个现有btree操作符族的名称（可能是模式限定的）， 它描述与一个排序操作符相关的排序顺序。
如果既没有指定FOR SEARCH也没有指定FOR ORDER BY， 默认值是FOR SEARCH。
一个与该操作符族相关的函数的索引方法的支持过程编号。
作为该操作符族的一种索引方法支持过程的函数的名称（可以是模式限定的）。
该函数的参数数据类型。
该操作符族的新名称。
该操作符族的新拥有者。
该操作符族的新模式。
OPERATOR和FUNCTION子句可以以任何顺序出现。
注意DROP语法只通过策略或者支持号以及输入数据类型指定该操作符族中的 "slot"。占用这个槽的操作符或函数的名称不会被提及。 还有，对于DROP FUNCTION，要指定的类型是该函数意图支持的输入数据类型。 对于 GiST、SP-GiST 以及 GIN 索引，这可能与函数的实际输入参数类型无关。
因为索引机制在使用函数之前不会检查其上的访问权限， 包括一个操作符族中的函数或操作符都等同于授予了其上的公共执行权限。 这对于操作符族中很有用的这类函数来说，这通常不成问题。
操作符不应该由 SQL 函数定义。一个 SQL 函数很可能被内联到调用查询中， 这将阻止优化器识别出该查询匹配一个索引。
在PostgreSQL 8.4 之前， OPERATOR子句可以包括一个RECHECK选项。 这不再被支持，因为一个索引操作符是否为"lossy"现在会在运行时即时决定。 这允许高效地处理一个操作符可能或者不可能为有损的情况。
下列示例命令为一个操作符族增加跨数据类型的操作符和支持函数， 该操作符族已经包含用于数据类型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) ;