SQLC 项目中实现按规则选择性禁用查询校验的探讨

在 SQLC 项目中，当前存在一个关于查询校验规则的痛点问题：开发者只能通过@sqlc-vet-disable注释完全禁用某个查询的所有校验规则，而无法针对特定规则进行选择性禁用。本文将深入分析这一功能需求的技术背景、实现思路以及对开发实践的影响。

当前机制的问题分析

SQLC 的查询校验功能（vetting）通过一系列预定义的规则来检查 SQL 查询语句的质量和安全性。目前的禁用机制采用全有或全无的方式，当开发者在查询前添加@sqlc-vet-disable注释时，该查询将跳过所有校验规则的检查。

这种设计存在明显局限性：

1. 过度禁用：即使只需要规避某一条规则，也必须放弃所有规则的校验
2. 安全性风险：禁用全部规则可能导致其他重要规则（如防注入检查）也被意外绕过
3. 维护困难：无法精确记录哪些规则被有意禁用，影响代码审查和后续维护

需求场景示例

考虑一个实际开发场景：项目中有个名为no-delete-without-where的自定义规则，用于防止不带WHERE条件的DELETE语句（避免全表删除）。但在某些特殊业务逻辑中，确实需要执行全表清除操作。

当前解决方案是：

/* @sqlc-vet-disable */
DELETE FROM temp_sessions;

这会导致该查询跳过所有校验，包括可能需要的其他重要规则检查。理想情况下，开发者应该能够：

/* @sqlc-vet-disable no-delete-without-where */
DELETE FROM temp_sessions;

技术实现方案

语法设计扩展

建议扩展注释语法，支持以空格分隔的规则名列表：

• 无参数时保持现有行为（禁用所有规则）
• 带参数时仅禁用指定的规则

示例：

/* @sqlc-vet-disable rule1 rule2 */ -- 仅禁用rule1和rule2
/* @sqlc-vet-disable */ -- 禁用所有规则

核心修改点

1. 注释解析器：增强注释解析逻辑，提取可选的规则名列表
2. 规则引擎：修改规则应用逻辑，支持基于查询的规则过滤
3. 兼容性处理：确保旧格式注释的向后兼容

多数据库支持

该功能需要统一实现在PostgreSQL、MySQL和SQLite的编译器中，保持一致的语法和行为。

对开发实践的影响

1. 精确控制：开发者可以更精细地控制哪些规则需要跳过
2. 代码可读性：明确显示被禁用的具体规则，提高代码可维护性
3. 安全提升：避免因完全禁用规则而引入潜在风险
4. 团队协作：便于代码审查时理解规则禁用的具体原因

总结

SQLC 项目中实现按规则选择性禁用查询校验的功能，将显著提升工具在实际开发中的灵活性和实用性。这一改进既保持了现有功能的简洁性，又为复杂场景提供了更精细的控制能力，是框架功能演进的重要方向。