SQLFluff 项目中 ClickHouse 方言的标识符大小写处理问题分析

问题背景

在 SQLFluff 3.1.0 版本中，使用 ClickHouse 方言时发现了一个关于标识符大小写处理的异常行为。当用户同时配置了 AL09 规则（关于未加引号的标识符）和 CP02 规则（关于大小写规范）时，SQLFluff 的修复功能会错误地删除某些列别名。

问题现象

用户提交的原始查询包含多个列选择，其中部分列使用了别名。特别值得注意的是，有一行列选择同时包含了大小写不一致的列名和别名，并使用了 noqa: CP02 注释来忽略大小写检查。

原始查询示例：

SELECT
    myidcol AS col_id,
    my_expected_drop_alias AS my_expected_drop_alias,
    My_Wrong_Case_Col as my_wrong_case_col, -- noqa: CP02
    my_good_col,
FROM
    file('myfile.parquet', 'Parquet')

经过 SQLFluff 修复后，输出结果意外地删除了部分别名：

SELECT
    myidcol AS col_id,
    my_expected_drop_alias,  -- 别名被错误删除
    My_Wrong_Case_Col, -- noqa: CP02  -- 别名被错误删除
    my_good_col,
FROM
    file('myfile.parquet', 'Parquet')

技术分析

ClickHouse 的标识符处理特性

ClickHouse 对于未加引号的标识符有其独特的处理方式。根据 ClickHouse 的文档和实践经验：

1. 默认情况下，ClickHouse 对未加引号的标识符是大小写敏感的
2. 当从 Parquet 等外部文件读取数据时，列名的大小写必须与文件中的定义完全匹配
3. 即使使用别名，原始列名的大小写也必须正确

SQLFluff 规则交互问题

在这个案例中，出现了两个规则的交互问题：

1. AL09 规则：处理未加引号标识符的大小写转换
2. CP02 规则：检查标识符的命名规范（包括大小写）

当用户使用 noqa: CP02 注释忽略大小写检查时，AL09 规则仍然会尝试处理这些标识符，导致意外的别名删除行为。这表明在规则处理逻辑中，对注释指令的处理顺序或优先级存在缺陷。

解决方案方向

要解决这个问题，需要考虑以下几个方面：

1. 规则执行顺序：确保注释指令能够正确影响相关规则的执行
2. 方言特性兼容：针对 ClickHouse 的大小写敏感特性进行特殊处理
3. 别名保留逻辑：在大小写转换过程中确保别名不会被意外删除

最佳实践建议

对于使用 SQLFluff 处理 ClickHouse SQL 的用户，在问题修复前可以采取以下临时解决方案：

1. 对于需要保留大小写的列名，考虑使用引号明确标识
2. 暂时禁用 AL09 规则，如果大小写敏感性是关键需求
3. 对需要忽略大小写检查的部分使用更精确的注释范围

总结

这个问题揭示了 SQL 格式化工具在处理不同数据库方言特性时的复杂性，特别是在大小写敏感性方面的差异。SQLFluff 需要增强对 ClickHouse 方言特性的支持，并改进规则之间的交互逻辑，以确保在各种场景下都能产生符合预期的格式化结果。