SQL Formatter 项目中的 T-SQL 关键字格式化问题解析

在 SQL 代码格式化工具 SQL Formatter 中，开发者发现了一个关于 T-SQL 关键字和数据类型作为列标识符时的格式化问题。这个问题主要涉及关键字大小写转换的不准确性，值得数据库开发者和工具使用者关注。

问题现象

当使用 SQL Formatter 格式化包含特定标识符的 T-SQL 查询时，工具会将某些本应保留原样的标识符错误地进行大小写转换。例如，在以下查询中：

SELECT Name, Value, 123 as Timestamp FROM Zone zone;

使用配置选项 keywordCase: "upper" 和 dataTypeCase: "lower" 时，格式化结果会将 Value 转换为 VALUE，Timestamp 转换为 timestamp，以及 Zone zone 转换为 ZONE ZONE，这显然不符合预期。

问题根源分析

经过项目维护者的调查，发现这个问题主要由两个因素导致：

1. 关键字列表过广：T-SQL 解析器中包含了过多的关键字，其中许多实际上并非 T-SQL 的保留关键字。特别是包含了 ODBC 关键字，这些在标准 T-SQL 中并不需要特殊处理。

2. 数据类型与标识符的歧义：对于像 TIMESTAMP 这样既是数据类型名称又是普通标识符的情况，当前 SQL Formatter 的架构无法区分其使用场景，导致无论作为数据类型还是标识符都会被转换。

解决方案

项目维护者已经采取了以下措施：

1. 清理关键字列表：移除了非标准的 ODBC 关键字，仅保留官方文档中明确的 T-SQL 保留关键字。这解决了大部分非关键字被错误转换的问题。

2. 数据类型转换的局限性：对于数据类型名称作为标识符的情况，建议用户避免使用 dataTypeCase: "lower" 选项，或者使用方括号明确标识符边界（如 AS [Timestamp]）。

最佳实践建议

对于使用 SQL Formatter 进行 T-SQL 格式化的开发者，建议：

1. 仔细检查格式化后的输出，特别是当查询中包含可能的关键字或数据类型名称作为标识符时。

2. 对于关键业务查询，考虑使用方括号明确标识符边界，避免解析歧义。

3. 了解 T-SQL 的实际保留关键字列表，避免使用这些关键字作为标识符。

4. 在团队协作中，统一格式化配置，特别是关键字和数据类型的转换规则。

这个问题展示了 SQL 格式化工具在处理复杂 SQL 方言时的挑战，也提醒我们在使用自动化工具时需要理解其局限性。