pgFormatter中类型转换格式问题的分析与修复

在SQL代码格式化工具pgFormatter的最新版本中，开发团队发现并修复了一个关于类型转换语法格式的问题。这个问题主要影响CREATE TABLE语句中默认值部分的类型转换表达式的格式化输出。

问题现象

当使用pgFormatter格式化包含类型转换的CREATE TABLE语句时，工具会在类型转换操作符(::)前错误地插入一个额外的空格。例如，对于以下SQL语句：

CREATE TABLE IF NOT EXISTS scanner._migrations (
    applied_at timestamptz NOT NULL DEFAULT now()::timestamptz
)

格式化后会变成：

CREATE TABLE IF NOT EXISTS scanner._migrations (
    applied_at timestamptz NOT NULL DEFAULT now() ::timestamptz
)

可以看到，在now()函数和::timestamptz类型转换操作符之间多出了一个不必要的空格。虽然这个空格不会影响SQL语句的执行，但它违反了PostgreSQL社区常见的代码风格规范。

问题根源

这个问题源于pgFormatter在解析和重新生成SQL代码时，对类型转换操作符的处理逻辑不够精确。类型转换操作符(::)在PostgreSQL中是一个整体运算符，不应该被空格分隔。pgFormatter在格式化过程中错误地将其视为两个独立的冒号字符，从而在中间插入了空格。

修复方案

开发团队在commit ea61e3d中修复了这个问题。修复后的版本能够正确识别类型转换操作符，并保持其作为一个整体不被空格分隔。这不仅解决了CREATE TABLE语句中的问题，也修复了其他所有SQL语句中类型转换表达式的格式化问题，例如常见的JSON类型转换：

-- 修复前
SELECT '{}' ::jsonb;

-- 修复后
SELECT '{}'::jsonb;

相关格式化风格

值得注意的是，pgFormatter对于SQL语句的右括号位置也有特定的格式化规则。当SQL语句以分号(;)结尾时，右括号会被放在新的一行；而省略分号时，右括号则保持在同一行。这种设计是为了适应不同的编码风格偏好。

总结

这次修复体现了pgFormatter项目对代码细节的关注和对PostgreSQL社区编码规范的尊重。类型转换作为PostgreSQL中常用的特性，其格式化的正确性直接影响到代码的可读性和一致性。开发团队及时响应并修复这个问题，进一步提升了工具的专业性和可靠性。