SQL Formatter 项目中的 PostgreSQL ^@ 运算符格式化问题解析

PostgreSQL 数据库中的字符串操作符 ^@ 是一个不太为人所知但非常实用的运算符，它实际上等同于 starts_with() 函数的功能。然而，在 SQL 格式化工具中，这个运算符的处理却引发了一个有趣的格式化问题。

问题现象

当开发者使用 SQL Formatter 工具格式化包含 ^@ 运算符的 PostgreSQL 查询时，工具会在运算符中间错误地插入空格，将 ^@ 转换为 ^ @。这种格式化会导致原本有效的 SQL 语句变得无效，因为 PostgreSQL 无法识别被空格分隔的运算符。

例如，原始查询：

SELECT 'foo' ^@ ANY ('{f,b}')

格式化后变为：

SELECT 'foo' ^ @ ANY ('{f,b}')

这种变化会导致 PostgreSQL 抛出语法错误："ERROR: syntax error at or near "ANY""。

技术背景

^@ 运算符在 PostgreSQL 中用于检查一个字符串是否以另一个字符串开头，其功能与 starts_with() 函数完全相同。我们可以通过查询 PostgreSQL 的系统表 pg_operator 来验证这一点：

SELECT oprname, oprleft::regtype, oprright::regtype, oprresult::regtype, oprcode::regproc 
FROM pg_operator 
WHERE oprname = '^@';

查询结果会显示这个运算符的左右操作数类型都是 text，返回 boolean 类型，实际调用的函数是 starts_with。

问题根源

这个问题源于 SQL Formatter 工具对 PostgreSQL 运算符的识别不完整。PostgreSQL 拥有大量运算符，而 ^@ 这个相对少见的运算符没有被包含在工具的运算符列表中，导致格式化时被错误处理。

解决方案

SQL Formatter 项目在 15.3.1 版本中修复了这个问题。修复方法是将 ^@ 运算符添加到 PostgreSQL 的运算符列表中，确保格式化时不会被错误地分割。

最佳实践

对于开发者来说，在使用 SQL 格式化工具时应注意：

1. 确保使用的格式化工具版本是最新的，特别是当遇到类似运算符格式化问题时
2. 了解 PostgreSQL 的特殊运算符，虽然 ^@ 和 starts_with() 功能相同，但在某些上下文（如与 ANY 一起使用时）不能互换
3. 当遇到格式化导致的语法错误时，可以尝试手动验证原始 SQL 的有效性，以确定是否是格式化工具的问题

这个案例也提醒我们，即使是成熟的工具，在处理各种数据库特有的语法时也可能存在盲点，保持工具的更新和了解其限制是高效开发的重要部分。