加载失败
RegreSQL 是一个针对 PostgreSQL 查询进行回归测试的工具，目标将查询语义与性能回归纳入 CI/CD 流程。讨论主要围绕三类现场问题：用小规模 CI/开发机数据与 EXPLAIN 做性能回归是否可靠（评论指出查询计划依赖统计与基数、缓存与并发会改变行为）；如何用 fixtures、BEGIN..ROLLBACK 或 savepoints 建立可重复的测试状态以避免测试互相污染；以及如何与现有工具链集成，例如 pgTAP（Postgres 单元测试框架）、pglite（可在浏览器运行的轻量 Postgres）、ephemeralpg（临时 Postgres 实例工具）、sqlc（将 SQL 转为类型安全代码的工具）和 SQLAlchemy（Python ORM）。总体意见是 RegreSQL 可作为低成本的基线回归检测工具，但要捕捉生产级性能回归仍需真实数据分布、并发负载和对运行时差异的考量。
多位评论者指出在 CI 或开发机上做 Postgres 性能回归测试存在根本性局限。Postgres 的查询计划高度依赖统计信息和基数分布，小规模或不代表生产分布的数据集会让优化器选择不同策略（例如在小表上全表扫描反而更快），从而掩盖生产问题。文件系统与数据库缓存、不同的并发负载和 IO/CPU 基线都会导致本地测得的表现与生产不一致；而 EXPLAIN 只给出估算数据而非实际执行时间，因此不能完全替代真实运行指标。有人用实际案例证明：在本地与预发布环境表现良好的递归查询在生产环境反复超时，说明没有万能解，RegreSQL 目前更适合作为低成本的基线检测工具而非生产级性能保证。
关于如何为回归测试建立初始数据库状态，讨论集中在 fixtures 和事务回滚机制上。RegreSQL 目前通过 fixtures（inline SQL 或 SQL 文件）支持初始化，且 fixture 顺序是固定的，评论者希望增加 pre/post hooks、完整的 schema reload 和更灵活的初始化流程。为了防止测试间污染，常见做法是在每个测试外层用 BEGIN..ROLLBACK 包裹，或将内部事务转换为 savepoints；目前 RegreSQL 对 fixtures 支持事务清理选项，但对修改数据库状态的测试还需增强回滚能力。对只通过暴露的 SQL 函数修改状态的系统（例如状态机或任务队列），有人表示只能用 API 脚本构建测试状态，这会增加维护成本，因而更需要框架级的初始化钩子。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
评论强调与现有 SQL/ORM 工具链的兼容性是采用障碍之一：SQLAlchemy 的集成显得有用但过于针对性，SQL 生成方式千差万别，交互式事务（数据库与服务器的来回操作）带来额外复杂性。多位评论建议借鉴或对接成熟工具：pgTAP（Postgres 的单元测试框架）用于断言与事务回滚，ephemeralpg 可用于临时 Postgres 实例，pglite 可以在浏览器或轻量环境跑 Postgres。针对 sqlc（将 SQL 转为类型安全代码的工具），当前语法不完全兼容，作者计划引入 boringsql/queries 的解析库来对齐 SQL 文件语法；同时有人提到可以参考 dbt 的 unit-test 风格来设计 YAML/fixture 的习惯用法。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
多位评论者在测试定位上存在分歧，但趋向一致的实践是以快速、并发且互不干扰的集成/端到端测试为主而不是过度依赖孤立的查询单元测试。有人分享实践经验：构建随机化数据与并发执行的全 API 集成测试，可以在笔记本上把数百个完整测试跑到几十秒，从而在修改数据库层时有更高置信度。单元层面仍有价值（例如语义回归或语法正确性），但对性能和并发相关的 bug 更需要真实数据分布、并发负载和相同版本的数据库来验证。总体建议是把 RegreSQL 当做发现“低垂果实”的工具，同时投资能在 CI 中保存历史指标并对比以捕捉回归。
有人询问对 MySQL 等其他数据库的支持，讨论集中在可行性与长期维护成本上。作者认为从技术上扩展到 MySQL 并不难，但维护会带来持续负担，故尚未决定优先级并且倾向于专注 PostgreSQL。评论者建议如果要支持多种后端，应设计插件化接口以降低实现成本并便于社区贡献。结论是对跨数据库支持存在需求，但需明确扩展接口、测试矩阵与维护资源才可推进。
fixtures: fixtures（测试初始化数据或脚本）：在测试开始前建立数据库的可重复初始状态，常以 inline SQL 或 SQL 文件形式提供，用于保证测试环境一致性。
pgTAP: pgTAP（PostgreSQL 的单元测试框架）：用于在数据库层写断言和测试，支持在事务内回滚测试更改，适合验证函数、触发器和约束的语义正确性。
EXPLAIN: EXPLAIN（PostgreSQL 的查询计划工具）：输出查询优化器的估算执行计划、成本和行数估计，反映的是估算信息而非实际执行时间，可能与真实性能存在差距。
pglite: pglite（在浏览器或轻量环境运行 Postgres 的库）：可在浏览器或轻量化环境中运行一个简化的 Postgres 实例，用于某些“单元级”联接测试，但与生产环境存在显著差异。