PostgreSQL的运算符体系并非封闭的，用户可以通过CREATE OPERATOR命令将任意已有函数包装成新的运算符，从而让SQL语句的写法更接近数学表达式或领域习惯。要完成这一操作，需要先明确一个核心事实：运算符只是函数的一种语法糖，它在系统目录pg_operator中存储名称、底层函数OID、操作数类型以及优化信息。理解这一点后，创建过程就可以拆成两步：先编写并注册函数，再声明运算符与函数的绑定关系。下面从语法入手展开说明。
一、CREATE OPERATOR的核心语法与参数
CREATE OPERATOR命令的基本结构如下所示。名称部分可以使用+、-、*、/、<、>、=、~等符号序列，也可以使用模式限定，例如myschema.+。PROCEDURE子句指向一个已经存在的函数，该函数必须与运算符的参数个数匹配：一元运算符对应一个参数的函数，二元运算符对应两个参数的函数。LEFTARG和RIGHTARG分别声明左操作数和右操作数的数据类型，如果省略其中一个，表示运算符是一元的；如果两个都省略，PostgreSQL会报错，因为无法确定操作数类型。
除最基础的参数外，还有几个影响优化器行为的关键选项。COMMUTATOR声明交换子运算符，比如加法运算符的交换子通常是其自身，而小于运算符的交换子可能是大于运算符。NEGATOR声明求反子运算符，例如小于的求反子可以是大于等于。正确设置这两个参数后，规划器可以自动改写表达式来利用索引或简化条件。RESTRICT和JOIN分别用于指定选择率估算函数和连接选择率估算函数，如果省略，查询优化器会使用默认估算，可能导致执行计划不够准确。HASHES和MERGES标记运算符是否可用于哈希连接和合并连接，通常针对等值比较运算符设置。
下面给出一个语法示例，用于创建一个针对自定义类型complex的加法运算符。代码中先创建一个复合类型complex，包含real_part和imaginary_part两个real字段，然后定义加法函数，最后创建运算符。代码块中的比较运算符均做了转义处理，实际执行时请使用原始符号。
CREATE TYPE complex AS (
real_part real,
imaginary_part real
);
CREATE FUNCTION complex_add(complex, complex)
RETURNS complex
LANGUAGE sql
IMMUTABLE
AS $$
SELECT ROW(
$1.real_part + $2.real_part,
$1.imaginary_part + $2.imaginary_part
)::complex;
$$;
CREATE OPERATOR + (
LEFTARG = complex,
RIGHTARG = complex,
PROCEDURE = complex_add,
COMMUTATOR = +
);
这个例子中，COMMUTATOR = + 表示该运算符的交换子就是它自己，因为复数加法满足交换律。如果运算符不满足交换律，例如矩阵乘法，就不能这样声明。创建完成后，就可以直接写作complex值 + complex值，而不必调用complex_add函数，SQL的可读性得到明显提升。
二、从函数到运算符：实际创建流程拆解
创建自定义运算符之前，必须确保底层函数已经存在且权限正确。函数可以用SQL、PL/pgSQL或C语言编写，但需要满足两个条件：参数类型和返回类型必须与运算符定义一致，函数必须被标记为IMMUTABLE或STABLE之一，否则在索引表达式或分区键中使用时会受到限制。以忽略大小写的文本比较为例，先定义一个函数ci_compare，它接受两个text参数并返回boolean，内部使用lower函数转换后比较。
CREATE FUNCTION ci_compare(text, text)
RETURNS boolean
LANGUAGE sql
IMMUTABLE
AS $$
SELECT lower($1) = lower($2);
$$;
接下来创建运算符，运算符名可以使用=、<、>等，但=运算符已经被内置text类型使用，如果给text类型再次创建=会冲突。所以要选择一个不冲突的符号，例如===或者自定义符号。PostgreSQL允许使用多个字符组成运算符，但必须以+、-、*、/、<、>、=、~、!、@、#、%、^、&、|、`、?中的字符开头，且不能以注释符--或/*开头。这里选用===作为忽略大小写相等的运算符，并指定其NEGATOR为!==。但需要先创建!==运算符的函数，否则无法设置NEGATOR。可以先创建两个运算符，再通过ALTER OPERATOR更新关联。
CREATE OPERATOR === (
LEFTARG = text,
RIGHTARG = text,
PROCEDURE = ci_compare,
COMMUTATOR = ===
);
CREATE FUNCTION ci_not_compare(text, text)
RETURNS boolean
LANGUAGE sql
IMMUTABLE
AS $$
SELECT lower($1) <> lower($2);
$$;
CREATE OPERATOR !== (
LEFTARG = text,
RIGHTARG = text,
PROCEDURE = ci_not_compare,
COMMUTATOR = !==
);
上述代码中，ci_not_compare函数使用了<>表示不等于，因为PostgreSQL的SQL函数体内直接写<>没有歧义，但为了展示转义规则，代码块里写作<>。两个运算符分别创建后，可以再使用ALTER OPERATOR将!==设置成===的NEGATOR，把===设置成!==的NEGATOR。这样优化器就能推导出a === b和a !== b之间的互斥关系。
实战中还有一个常见需求：为已有的枚举类型或JSONB字段创建自定义比较运算符。例如给jsonb类型添加一个操作符@>?来检查某个键是否存在且值大于指定数字。创建之前需要写一个函数接收jsonb和int参数，返回boolean，内部使用jsonb_extract_path_text和to_number进行解析。然后通过CREATE OPERATOR声明，注意LEFTARG为jsonb，RIGHTARG为int。这样在查询中就可以写WHERE data @>? 10，比嵌套函数调用直观得多。
三、COMMUTATOR与NEGATOR对查询计划的影响
COMMUTATOR和NEGATOR并不是装饰性参数，它们直接影响优化器能否生成高效的执行计划。以索引扫描为例，假设表t的列a上创建了B-tree索引，查询条件是10 < a，如果<运算符没有设置交换子，PostgreSQL无法自动转换为a > 10来使用索引，只能进行顺序扫描。但如果在创建<运算符时声明COMMUTATOR为>，规划器就会将10 < a改写成a > 10，从而利用索引。这个优化对于处理用户自定义运算符尤其重要，因为大部分开发者在编写自定义运算时只关注功能实现，忽略交换子信息，导致查询性能下降。
NEGATOR的作用类似，它帮助规划器推导条件之间的逻辑关系。例如创建>运算符时指定NEGATOR为<=，那么当查询中出现a > 10 OR a <= 10时，规划器可以识别出这是互补条件，从而简化表达式或者选择合适的分支。如果缺少NEGATOR，规划器只能把两个条件当作独立谓词处理，可能会执行不必要的重复过滤。同样地，对于自定义的===运算符，如果正确设置了NEGATOR!==，那么WHERE a === b OR a !== b可以被优化为恒真条件，避免扫描数据的开销。
设置交换子和求反子有一个常见陷阱：两个运算符互相引用时无法一次性创建。PostgreSQL要求COMMUTATOR和NEGATOR指向的运算符必须已经存在，因此在创建第一个运算符时可以先省略这些参数，等两个运算符都创建完成后，再使用ALTER OPERATOR补充设置。ALTER OPERATOR语法同样支持修改COMMUTATOR、NEGATOR、RESTRICT、JOIN等字段，不会重建运算符，只会更新pg_operator系统目录。需要注意的是，修改后需要重新收集统计信息或执行ANALYZE，优化器才会利用新的元数据。
四、权限管理、常见错误与事务处理
创建运算符所需的权限比较特殊：用户必须对运算符所在的schema拥有CREATE权限，同时必须是底层函数的owner或者拥有该函数的EXECUTE权限。如果函数是用SECURITY DEFINER创建的，还需要额外检查安全上下文。当CREATE OPERATOR执行成功时，运算符的所有者会被设定为执行命令的用户，其他用户要使用该运算符，需要被授予相应的USAGE权限，例如GRANT USAGE ON SCHEMA myschema TO app_user。这一点在团队协作中容易被忽略，导致应用角色无法解析自定义运算符。
常见的创建错误包括函数签名不匹配、操作数类型与函数参数类型不一致、运算符名与内置运算符冲突、以及使用了不支持的运算符字符。例如函数定义为(complex, complex)返回complex，但CREATE OPERATOR时LEFTARG写成了int，PostgreSQL会报function does not exist。另外，运算符名称不能以分号结尾，不能包含空白字符，长度不得超过63字节。遇到冲突时，最简单的办法是使用模式限定名称，例如CREATE OPERATOR myschema.+ (...)，这样同一个名称可以存在于不同schema中，避免污染公共命名空间。
在正式环境中，建议将CREATE OPERATOR放在事务中执行，并与其他依赖对象（类型、函数、权限授予）一起提交或回滚。因为运算符一旦创建，如果后续函数被删除，运算符会变成悬空引用，导致查询报错。如果确实需要删除运算符，可以使用DROP OPERATOR命令，语法为DROP OPERATOR IF EXISTS name (left_type, right_type)。删除运算符不会自动删除底层函数，需要单独处理。对于需要升级运算符定义的场景，由于CREATE OR REPLACE OPERATOR并不存在，通常的做法是先在事务中DROP OPERATOR，再重新CREATE OPERATOR，确保短暂的锁窗口内完成切换。
最后要强调，自定义运算符虽然扩展了SQL的表达能力，但也引入了文档和维护成本。团队中新成员可能不理解===或@>?的确切语义，建议在代码库附近放置注释，或者在数据库中用COMMENT ON OPERATOR命令添加说明。只有在适度使用并配合完善的测试时，CREATE OPERATOR才能真正提升代码可维护性，而不是变成晦涩的语法糖。
PostgreSQLCREATE OPERATOR自定义运算符修改时间：2026-09-27 05:36:23