ALTER OPERATOR FAMILY

Name

ALTER OPERATOR FAMILY -- 更改操作符类的定义

Synopsis

ALTER OPERATOR FAMILY name USING index_method ADD
  {  OPERATOR strategy_number operator_name ( op_type, op_type )
   | 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

描述

ALTER OPERATOR FAMILY更改一个操作符类的定义。 您可以添加操作符和支撑函数到类中,将它们从类中移除,或者更改类的名称或者属主。

当操作符和支撑函数通过ALTER OPERATOR FAMILY命令被添加到类中, 它们不是类中的任何具体操作符类,但是,它们仅仅是类中的"loose"。这表明 这些操作符和函数与类的语义兼容,但是对于任何特定索引的准确运行是不必要的。 (相反,如此要求的操作符和函数应该被声明为一个操作符类的一部分,参阅 CREATE OPERATOR CLASS。)PostgreSQL 将允许释放随时会从类中删除的类成员,但是一个操作符类的成员,在没删除整个类以及 基于它的所有索引之前是不能被删除的。典型地,单一数据类型操作符和函数时操作符类的一部分, 因为需要用他们来支持自那些特定数据类型的索引,跨数据类型操作符和函数使得释放类成员。

您必须是超级用户才能使用ALTER OPERATOR FAMILY。 (做这个约束是因为一个错误的操作符类定义会困住或者摧毁服务器。)

ALTER OPERATOR FAMILY不会在当前检查操作符类是否包含所有 索引方法需要的操作符和函数,也不会检查操作符和函数是否来自一个独立集合。 定义一个有效的操作符类是用户的责任。

参阅Section 35.14获取更多信息。

参数

name

现有操作符类的名称(选择性地添加模式修饰)

index_method

此操作符类的索引方法的名称。

strategy_number

The index method's strategy number for an operator associated with the operator family. 索引方法对于一个与操作符类相连的操作符的策略数量。

operator_name

The name (optionally schema-qualified) of an operator associated with the operator family. 与操作符类相关的操作符的名称(可有模式修饰)。

op_type

在一个OPERATOR子句中,操作符的操作数数据类型、或者 表示左一元或者右一元操作符的NONE。与CREATE OPERATOR CLASS 中的可比较语法不同,操作数数据类型必须是声明的。

在一个ADD FUNCTION子句中, 如果不同于函数的输入数据类型, 函数打算支持的操作数数据类型。对于B-树和哈希索引,既然函数的输入数据 类型总是使用的正确的,那就没必要声明op_type。 对于GIN和GiST索引,不需要声明函数使用的输入数据类型。

在一个DROP FUNCTION子句中,函数旨在支持的操作数类型必须被声明。

support_number

对于函数来说,索引方法的支持进程数与操作符类有关。

function_name

一个支持操作符类进程的索引方法函数的名称(可以有模式修饰)。

argument_type

函数的参数数据类型。

new_name

操作符类的新名称。

new_owner

操作符类的新属主。

OPERATORFUNCTION子句可以任意顺序出现。

Notes

请注意DROP语法仅仅声明操作符类中的"slot",通过策略或者 支持数和输入数据类型。操作符的名称或者占据槽的函数不会涉及。而且,对于 DROP FUNCTION来说,要声明的类型是函数旨在支持的输入数据类型; 对于GIN 和GiST索引,这可能与函数的实际输入参数类型无关。

因为索引机器在使用函数之前不检查函数上的访问权限,包括在操作符类中的函数或操作符 在内等同于授予其公共执行权限。这对于在操作符类中的函数查询来说不是问题。

操作符不应该由SQL函数定义。一个SQL函数有可能被内联为调用函数,这将阻止 优化器发现查询匹配索引。

PostgreSQL8.4之前,OPERATOR子句应该包括 一个RECHECK选项。这不再支持,因为不管索引操作符是否是"lossy", 都会在运行时由邻近备用设备决定。

例子

以下示例命令,添加跨数据类型操作符和支撑函数,到已包含针对int4int2数据类型的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语句。

又见

CREATE OPERATOR FAMILY, DROP OPERATOR FAMILY, CREATE OPERATOR CLASS, ALTER OPERATOR CLASS, DROP OPERATOR CLASS