运算符家族

ALTER OPERATOR FAMILY —更改操作员系列的定义

Synopsis

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_schema

Description

ALTER OPERATOR FAMILY更改操作员系列的定义。您可以向该系列添加操作员和支持功能，将其从该系列中删除，或者更改该系列的名称或所有者。

当使用ALTER OPERATOR FAMILY将操作员和支持功能添加到一个系列中时，它们不属于该系列中任何特定的操作员类别，而只是该系列中的“松散”。这表明这些运算符和函数与该族的语义兼容，但对于任何特定索引的正确运行而言并不是必需的。 (需要的运算符和函数应声明为运算符类的一部分，而不是；请参见创建操作员班。)PostgreSQL 允许随时从家族中删除家族的松散成员，但不能将运算符类的成员删除而不删除整个类和依赖它的任何索引。通常，单数据类型的运算符和函数是运算符类的一部分，因为需要它们来支持该特定数据类型的索引，而跨数据类型的运算符和函数则成为该族的松散成员。

您必须是超级用户才能使用ALTER OPERATOR FAMILY。 (之所以做出此限制，是因为错误的操作员系列定义可能会使服务器混乱甚至崩溃.)

ALTER OPERATOR FAMILY目前不检查运算符族定义是否包括索引方法所需的所有运算符和函数，也不检查运算符和函数是否形成一个自洽集合。定义有效的操作员系列是用户的责任。

有关更多信息，请参考Section 38.15。

Parameters

name
- 现有操作员系列的名称(可选，通过模式限定)。
index_method
- 该运算符系列所针对的索引方法的名称。
strategy_number
- 与操作员系列关联的操作员的索引方法的策略编号。
operator_name
- 与操作员系列相关联的操作员的名称(可选的模式限定)。
op_type
- 在OPERATOR子句中，运算符的操作数数据类型，或NONE表示左一元或右一元运算符。与CREATE OPERATOR CLASS中类似的语法不同，必须始终指定操作数数据类型。

在ADD FUNCTION子句中，如果函数的 Importing 数据类型不同，则该函数应支持的操作数数据类型。对于 B 树比较函数和哈希函数，无需指定* op_type *，因为该函数的 Importing 数据类型始终是要使用的正确数据类型。对于 B 树排序支持功能以及 GiST，SP-GiST 和 GIN 运算符类中的所有功能，有必要指定该功能将与之一起使用的操作数数据类型。

在DROP FUNCTION子句中，必须指定函数要支持的操作数数据类型。

sort_family_name
- 现有的btree运算符系列的名称(可选，由模式限定)，该名称描述与排序运算符关联的排序 Sequences。

如果既未指定FOR SEARCH也未指定FOR ORDER BY，则默认值为FOR SEARCH。

support_number
- 与操作员系列相关的功能的索引方法的支持功能编号。
function_name
- 作为操作员系列的索引方法支持功能的函数的名称(可选，由模式限定)。如果未指定参数列表，则名称在其架构中必须唯一。
argument_type
- 函数的参数数据类型。
new_name
- 运算符家族的新名称。
new_owner
- 运算符家族的新所有者。
new_schema
- 运算符系列的新架构。

OPERATOR和FUNCTION子句可以按任何 Sequences 出现。

Notes

请注意，DROP语法仅按策略或支持编号以及 Importing 数据类型在操作员系列中指定“插槽”。没有提及占用插槽的操作员或函数的名称。同样，对于DROP FUNCTION，要指定的类型是函数要支持的 Importing 数据类型。对于 GiST，SP-GiST 和 GIN 索引，这可能与函数的实际 Importing 参数类型无关。

因为索引机制在使用函数之前不会检查对它们的访问权限，所以包括运算符家族中的函数或运算符就等于授予了对其的公共执行权限。对于操作员系列中有用的各种功能，通常这不是问题。

运算符不应由 SQL 函数定义。 SQL 函数很可能内联到调用查询中，这将阻止优化器识别查询与索引匹配。

在 PostgreSQL 8.4 之前，OPERATOR子句可以包含RECHECK选项。不再支持此操作，因为现在可以在运行时即时确定索引运算符是否“有损”。这样可以有效地处理操作员可能会或可能不会有损失的情况。

Examples

以下示例命令将跨数据类型的运算符和支持功能添加到一个运算符系列中，该运算符系列已经包含数据类型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) ;

Compatibility

SQL 标准中没有ALTER OPERATOR FAMILY语句。

Docs

Docs4dev

Title here