Turso PostgreSQL 兼容性回归语料库用上游 PostgreSQL 18 测试集度量 tursopg 的 SQL 兼容性【免费下载链接】tursoA SQL database in Rust: SQLite-compatible, now also speaking Postgres (experimental). The LLVM of databases.项目地址: https://gitcode.com/GitHub_Trending/tu/turso本篇技术指南讲解 TursotursopgPostgreSQL 前端如何借助一套从 PostgreSQL 上游原样导入、逐字节比对的回归测试语料库来度量并持续收紧自身对 PostgreSQL 的兼容性。文章覆盖语料库的来源与选择原则、目录布局、三种测试状态pass / fail / skip的棘轮机制、运行与判定工具链run.py 与 pgregress runner以及如何随 PostgreSQL 新版本整体重新同步。读完你可以复现整套兼容性度量流程并理解测试通过率即兼容性标尺这一工程实践背后的设计。语料库是什么以 PostgreSQL 上游回归测试为标尺Turso 的 PostgreSQL 兼容前端tursopg其整体架构可参考 postgres/COMPAT.md是否真的像 PostgreSQL最直接的回答方式是把 PostgreSQL 自己用来验证自身的回归测试拿过来跑一遍。这正是postgres/conformance/upstream/README.md所描述的核心思想语料库是 PostgreSQL 官方回归测试src/test/regress/的精选子集共103 个测试上游共 233 个这些测试由pgregressrunner位于 postgres/regress/main.rs驱动针对tursopg运行该语料库的通过率是衡量 tursopg 与 PostgreSQL 兼容性的首要指标The pass rate of this corpus is the headline measure of how PostgreSQL compatible tursopg is。需要特别强调的是语料库的纯净性原则.sql脚本、.out期望转录含_1.out形式的备选输出以及data/*.data数据文件全部逐字复制自 PostgreSQL 上游标签仓库只自行编写README.md与schedule两个文件。不要为了让测试通过而编辑它们——它们是标尺不是我们的产物。Do not edit them to make tests pass — they are the yardstick, not ours.来源与版本溯源语料库的出处被精确记录在案这是整个度量体系可信度的基石项目内容上游来源PostgreSQL 官方仓库src/test/regress/上游版本PostgreSQL 18标签REL_18_4提交f5cc81719e6da4cbdb1f797c48b693e91018153a导入时间2026-08-05该来源说明Provenance块记录在 postgres/conformance/upstream/README.md 中并在每次重新同步时更新。入选 103 个测试的依据选取原则与排除类别语料库不是无脑全量复制而是有明确取舍原则的精选子集。选择原则是语料库覆盖的是应用真正依赖的 PostgreSQL 核心功能集。测试被排除是因为它们检验的是 PostgreSQL 的物理实现访问方法、计划形态、服务端内部机制而非其 SQL 行为或者因为对应功能领域尚未启动开发。被排除的类别及示例排除类别代表测试物理访问方法与计划形态btree_index、gin、gist、brin*、hash_index、explain、memoize、equivclass、join_hash、partition_*、incremental_sort、tuplesort、predicate服务端内部机制vacuum、stats、replication、tablespaces、TOAST、compression、parallel workers、pg_lsn、xid/txid、combocid、mvcc依赖regress.so中 C 函数的测试misc、create_type、create_function_c、create_operator、create_aggregate、create_cast目录表自洽性检查opr_sanity、oidjoins、type_sanity、sanity_check、misc_sanity平台与区域相关collate*、编码转换类测试明确推迟的功能领域plpgsql、triggers、rules、privileges/RLS、全文检索tsearch、tsdicts、tstypes、几何类型point、box、path等、xml、largeobject、without_overlaps、generated_virtual、inherit、分区partitioningSQL 语言函数定义等 CREATE FUNCTION 纳入路线图后加入create_function_sql、rangefuncs、polymorphism、plancache排除是排序而非天花板README 明确强调Exclusion is sequencing, not a ceiling——排除只是先后顺序不是能力上限。长期目标是完全兼容被推迟的测试会随各自功能领域的落地而逐步加入语料库。因此任何增删测试的决策都必须对照上述原则进行并同步更新这份清单。这与 postgres/COMPAT.md 中记录的功能状态矩阵✅ Supported / Partial / ❌ Not supported形成呼应被标记为 Not supported 的功能恰好大多对应被排除的测试类别。目录布局一个测试 一个 SQL 脚本 一份期望转录语料库目录 postgres/conformance/upstream/ 的布局如下name.sql/name.out——测试脚本与期望的 psql 转录name_1.out等是上游认可的备选输出用于处理平台或顺序相关的微小差异data/——脚本通过COPY ... FROM加载的数据文件通过\getenv abs_srcdir引用只导入语料库实际使用的文件。仓库当前共导入 15 个数据文件agg.data、array.data、constrf.data、constro.data、desc.data、emp.data、jsonb.data、onek.data、person.data、real_city.data、rect.data、streets.data、stud_emp.data、student.data、tenk.dataschedule——运行顺序文件源自上游parallel_schedule并过滤到本语料库。顺序至关重要后面的测试组会使用前面测试组建立的 fixture尤其是test_setup所以即使是串行运行也不能打乱顺序。schedule的分组结构见 postgres/conformance/upstream/schedule基本延续了上游test_setup最先执行建立公共 fixture随后是类型系统boolean、char、int2/4/8、float4/8、numeric、uuid、enum、money、rangetypes等、字符串与日期时间strings、date、time、timestamp、interval、inet、macaddr等、DMLcopy、insert、update、delete、merge、DDLcreate_table、create_index、create_view、alter_table、查询语义select*、subselect、union、join、aggregates、window、事务transactions、以及 JSON 系列json、jsonb、jsonpath、sqljson*等。一个测试脚本长什么样以公共 fixture 脚本 postgres/conformance/upstream/test_setup.sql 为例它演示了语料库如何通过环境变量解析路径、如何配置会话-- directory paths and dlsuffix are passed to us in environment variables \getenv abs_srcdir PG_ABS_SRCDIR \getenv libdir PG_LIBDIR \getenv dlsuffix PG_DLSUFFIX \set regresslib :libdir /regress :dlsuffix SET synchronous_commit on; CREATE TABLE CHAR_TBL(f1 char(4)); INSERT INTO CHAR_TBL (f1) VALUES (a), (ab), (abcd), (abcd ); VACUUM CHAR_TBL;注意这里使用了 psql 的\getenv元命令、\set变量与:name变量插值——这些恰恰是pgregressrunner 必须在 Rust 中重新实现的 psql 行为详见下文runner 源码级原理。运行与判定run.py 与三种测试状态运行方式语料库的三种运行入口postgres/conformance/run.py # 运行整个语料库 postgres/conformance/run.py boolean # 只运行单个测试按名称 make -C postgres/conformance run-upstreamrun.pypostgres/conformance/run.py的工作流程是先用cargo build -p tursopg -p turso_pg_regress构建服务端与 runner在临时目录新建数据库文件并选一个空闲端口启动tursopg --server 127.0.0.1:port然后按schedule顺序逐个测试运行pgregress最后拆除服务端。每次完整调用都会运行语料库中的每一个测试并依据STATUS表判定结果。三种状态pass / fail / skip 与棘轮机制run.py顶部的STATUS表为每个语料测试登记了三种状态之一pass已赐福 blessed——输出必须逐字节匹配。任何 diff 或崩溃都算回归regression直接导致本次运行失败fail已知不通过 known-bad——测试会运行diff 会被报告但不会导致运行失败。不过一旦它变成逐字节匹配运行反而会失败并提示请赐福它bless it因此known-bad 列表只会不断缩小永远不会扩大skip跳过——完全不运行仅用于无法运行的测试并在条目旁注明原因当前语料库中无 skip 条目。赐福一个测试的操作非常简单修复剩余 diff 后把其状态从fail改为pass。这个设计构成一个兼容性棘轮validate_status()会校验schedule 中的每个测试都有状态、STATUS 中的每个测试都在 schedule 中防止任何一次语料库或 schedule 编辑悄悄把测试移出棘轮。容错与汇总崩溃或卡死服务器的测试会因超时被判失败runner 超时 60 秒服务器会被自动重启数据库文件跨重启保留fixtures 因此存活所以单个坏测试不会毒化整个运行。Tally汇总输出形如 total: N blessed ok, M known-bad failure(s), K regression(s), X unexpected pass(es), Y skipped, Z server restart(s) REGRESSION: name is blessed pass but its output diverged——已赐福测试出现回退XPASS: name now passes byte-exact; bless it by changing its STATUS entry to pass——known-bad 测试意外通过等待赐福。run.py的退出码语义所有测试都与状态匹配返回 0出现回归或意外通过返回 1。runner 本身的退出码见 postgres/regress/main.rs为0 全部通过、1 输出不匹配、2 工具链错误、3 至少一次传输失败服务器死亡或失联驱动应在下一个测试前重启它。make -C postgres/conformance run-upstream目标postgres/conformance/Makefile等价于直接调用./run.py而run/run-one目标则驱动另一套基于testing/sqltestrunner 的pg-sqltests语料见 postgres/conformance/pg-sqltests/两套语料互补。runner 源码级原理不调 psql直接讲 PostgreSQL 线协议pgregresspostgres/regress/main.rs与上游pg_regress最大的不同在于它不 shell out 到psql而是直接用 Rust 通过 TCP 讲 PostgreSQL wire protocolsimple query protocol并在客户端重现 psql 的转录输出——回显输入、对齐的结果表格、带LINE n:位置标记的错误报告——从而让最终输出能与期望转录逐字节比对。复现的 psql 行为runner 解释语料库用到的一整套 psql 元命令postgres/regress/main.rs 中Session::meta_command实现变量系统\set、\unset、\getenv、\gset以及:name、:name转义为 SQL 字符串字面量、:name转义为带引号的 SQL 标识符三种插值形式条件控制\if/\elif/\else/\endif布尔解析支持true/false/yes/no的前缀匹配及on/off/1/0与 psql 一致false 分支内的语句仍会回显但不会执行缓冲发送命令\g、\gset、\gexec输出控制\o结果重定向错误仍留在转录中、\echo、\qecho、\x展开显示、\pset nullNULL 显示字符串默认空、SHOW_CONTEXT错误上下文渲染COPY 支持客户端侧\copy ... from/to重写为服务端COPY ... FROM STDIN/STDOUT文件内容或脚本行经CopyData消息流式传输、内联COPY ... FROM stdin数据读到\.结束标记为止重连\c/\c -重连同一数据库变量与显示选项保留连接状态重置describe 家族\d、\d、\dD、\dT、\sv、\sf实现见 postgres/regress/describe.rs通过目录查询复刻 psql 的版式居中标题、对齐列、脚注行与结尾空行未知元命令输出invalid command \name并继续保证单个模拟缺口不会中止整个脚本。psql 对空输入行、注释剥离、语句前导空白、跨行语句保留换行保证错误位置映射到正确行等细节也都被 scannerScanner/LexState一一复刻。README 也坦承了已知模拟缺口多行字段值不渲染续行标记、超长错误位置行不裁剪为...、列宽按字符数而非终端显示宽度计算——这些缺口会在语料库需要时补齐。为什么这种转录仿真重要main.rs 的文档注释给出了一条宝贵的排障指引如果所有测试突然出现统一、系统性的 diff先怀疑仿真与 psql 之间的漂移而不是服务端。这是因为 pgregress 模拟的是pg_regress从psql -X -a -q拿到的输出形态等价设置通过启动参数发送任何转录形态的偏差都会表现为全量失败。重新同步到更新的 PostgreSQL 版本README 明确这是一次审慎的、全语料库级别的操作绝不混用版本Deliberate, whole-corpus operation — never mix releases。四步流程导出上游文件git -C postgres-checkout archive new-tag src/test/regress | tar -x重新复制文件为schedule中列出的每个测试重新复制.sql、.out含备选输出及被引用的data/文件对照上游 release notes 与parallel_schedule的 diff检查新增、删除或重命名的测试重新生成 schedule从新的parallel_schedule重新生成过滤到语料库范围更新溯源块并重新基线化更新 README 中的版本溯源块并在 CI 中重新基线化通过数。整个流程确保语料库始终跟随 PostgreSQL 最新语义同时把通过率这一度量锚定在明确的版本上。与项目其他组件的协同这套语料库不是孤岛它与项目的多个层面相互印证postgres/COMPAT.md功能兼容性矩阵逐项标注 ✅ / / ❌ 并附说明如 DISTINCT ON — Accepted but silently degrades to plain DISTINCT (wrong results)。语料库中被排除的类别与矩阵中 Not supported 的条目高度一致postgres/parser与postgres/frontendtursopg 用pg_querylibpg_query真实 PostgreSQL 语法解析 SQL经 postgres/parser/translator.rs 翻译为 Turso 原生 AST 后由 Turso 引擎执行参见 postgres/cli/README.md——No SQLite text is ever generated。因此语料库的 diff 直接反映翻译器与执行引擎的差距postgres/clitursopg本体既是 psql 风格的 REPL 也能承载 wire 服务器tursopg --server 127.0.0.1:port db-file是 run.py 启动的被测对象当前状态从 postgres/conformance/run.py 的STATUS表可见目前仅有comments测试处于pass已赐福状态其余 102 个为failknown-badskip为 0——这正是known-bad 列表只会不断缩小这一棘轮机制的起点状态。总结一套可复现、可收紧的兼容性度量体系Turso 的 PostgreSQL 兼容性工程实践可以概括为三点标尺外置语料库逐字来自 PostgreSQL 官方版本、提交、导入时间全程可溯不允许为让测试通过而修改标尺度量明确通过率即兼容性首要指标逐字节比对消除一切看起来差不多的模糊地带棘轮单向pass 回退即失败known-bad 意外通过即要求赐福skip 必须注明理由——兼容性只会单调提升且任何提升都需要显式登记。对于希望复现该度量的读者postgres/conformance/run.py与make -C postgres/conformance run-upstream是入口STATUS表是地图postgres/regress/与postgres/conformance/upstream/是全部疆域。随着功能领域如 CREATE FUNCTION、plpgsql、triggers逐步落地被推迟的测试将按既定原则陆续加入语料库标尺也随之收紧。【免费下载链接】tursoA SQL database in Rust: SQLite-compatible, now also speaking Postgres (experimental). The LLVM of databases.项目地址: https://gitcode.com/GitHub_Trending/tu/turso创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Turso PostgreSQL 兼容性回归语料库：用上游 PostgreSQL 18 测试集度量 tursopg 的 SQL 兼容性
Turso PostgreSQL 兼容性回归语料库用上游 PostgreSQL 18 测试集度量 tursopg 的 SQL 兼容性【免费下载链接】tursoA SQL database in Rust: SQLite-compatible, now also speaking Postgres (experimental). The LLVM of databases.项目地址: https://gitcode.com/GitHub_Trending/tu/turso本篇技术指南讲解 TursotursopgPostgreSQL 前端如何借助一套从 PostgreSQL 上游原样导入、逐字节比对的回归测试语料库来度量并持续收紧自身对 PostgreSQL 的兼容性。文章覆盖语料库的来源与选择原则、目录布局、三种测试状态pass / fail / skip的棘轮机制、运行与判定工具链run.py 与 pgregress runner以及如何随 PostgreSQL 新版本整体重新同步。读完你可以复现整套兼容性度量流程并理解测试通过率即兼容性标尺这一工程实践背后的设计。语料库是什么以 PostgreSQL 上游回归测试为标尺Turso 的 PostgreSQL 兼容前端tursopg其整体架构可参考 postgres/COMPAT.md是否真的像 PostgreSQL最直接的回答方式是把 PostgreSQL 自己用来验证自身的回归测试拿过来跑一遍。这正是postgres/conformance/upstream/README.md所描述的核心思想语料库是 PostgreSQL 官方回归测试src/test/regress/的精选子集共103 个测试上游共 233 个这些测试由pgregressrunner位于 postgres/regress/main.rs驱动针对tursopg运行该语料库的通过率是衡量 tursopg 与 PostgreSQL 兼容性的首要指标The pass rate of this corpus is the headline measure of how PostgreSQL compatible tursopg is。需要特别强调的是语料库的纯净性原则.sql脚本、.out期望转录含_1.out形式的备选输出以及data/*.data数据文件全部逐字复制自 PostgreSQL 上游标签仓库只自行编写README.md与schedule两个文件。不要为了让测试通过而编辑它们——它们是标尺不是我们的产物。Do not edit them to make tests pass — they are the yardstick, not ours.来源与版本溯源语料库的出处被精确记录在案这是整个度量体系可信度的基石项目内容上游来源PostgreSQL 官方仓库src/test/regress/上游版本PostgreSQL 18标签REL_18_4提交f5cc81719e6da4cbdb1f797c48b693e91018153a导入时间2026-08-05该来源说明Provenance块记录在 postgres/conformance/upstream/README.md 中并在每次重新同步时更新。入选 103 个测试的依据选取原则与排除类别语料库不是无脑全量复制而是有明确取舍原则的精选子集。选择原则是语料库覆盖的是应用真正依赖的 PostgreSQL 核心功能集。测试被排除是因为它们检验的是 PostgreSQL 的物理实现访问方法、计划形态、服务端内部机制而非其 SQL 行为或者因为对应功能领域尚未启动开发。被排除的类别及示例排除类别代表测试物理访问方法与计划形态btree_index、gin、gist、brin*、hash_index、explain、memoize、equivclass、join_hash、partition_*、incremental_sort、tuplesort、predicate服务端内部机制vacuum、stats、replication、tablespaces、TOAST、compression、parallel workers、pg_lsn、xid/txid、combocid、mvcc依赖regress.so中 C 函数的测试misc、create_type、create_function_c、create_operator、create_aggregate、create_cast目录表自洽性检查opr_sanity、oidjoins、type_sanity、sanity_check、misc_sanity平台与区域相关collate*、编码转换类测试明确推迟的功能领域plpgsql、triggers、rules、privileges/RLS、全文检索tsearch、tsdicts、tstypes、几何类型point、box、path等、xml、largeobject、without_overlaps、generated_virtual、inherit、分区partitioningSQL 语言函数定义等 CREATE FUNCTION 纳入路线图后加入create_function_sql、rangefuncs、polymorphism、plancache排除是排序而非天花板README 明确强调Exclusion is sequencing, not a ceiling——排除只是先后顺序不是能力上限。长期目标是完全兼容被推迟的测试会随各自功能领域的落地而逐步加入语料库。因此任何增删测试的决策都必须对照上述原则进行并同步更新这份清单。这与 postgres/COMPAT.md 中记录的功能状态矩阵✅ Supported / Partial / ❌ Not supported形成呼应被标记为 Not supported 的功能恰好大多对应被排除的测试类别。目录布局一个测试 一个 SQL 脚本 一份期望转录语料库目录 postgres/conformance/upstream/ 的布局如下name.sql/name.out——测试脚本与期望的 psql 转录name_1.out等是上游认可的备选输出用于处理平台或顺序相关的微小差异data/——脚本通过COPY ... FROM加载的数据文件通过\getenv abs_srcdir引用只导入语料库实际使用的文件。仓库当前共导入 15 个数据文件agg.data、array.data、constrf.data、constro.data、desc.data、emp.data、jsonb.data、onek.data、person.data、real_city.data、rect.data、streets.data、stud_emp.data、student.data、tenk.dataschedule——运行顺序文件源自上游parallel_schedule并过滤到本语料库。顺序至关重要后面的测试组会使用前面测试组建立的 fixture尤其是test_setup所以即使是串行运行也不能打乱顺序。schedule的分组结构见 postgres/conformance/upstream/schedule基本延续了上游test_setup最先执行建立公共 fixture随后是类型系统boolean、char、int2/4/8、float4/8、numeric、uuid、enum、money、rangetypes等、字符串与日期时间strings、date、time、timestamp、interval、inet、macaddr等、DMLcopy、insert、update、delete、merge、DDLcreate_table、create_index、create_view、alter_table、查询语义select*、subselect、union、join、aggregates、window、事务transactions、以及 JSON 系列json、jsonb、jsonpath、sqljson*等。一个测试脚本长什么样以公共 fixture 脚本 postgres/conformance/upstream/test_setup.sql 为例它演示了语料库如何通过环境变量解析路径、如何配置会话-- directory paths and dlsuffix are passed to us in environment variables \getenv abs_srcdir PG_ABS_SRCDIR \getenv libdir PG_LIBDIR \getenv dlsuffix PG_DLSUFFIX \set regresslib :libdir /regress :dlsuffix SET synchronous_commit on; CREATE TABLE CHAR_TBL(f1 char(4)); INSERT INTO CHAR_TBL (f1) VALUES (a), (ab), (abcd), (abcd ); VACUUM CHAR_TBL;注意这里使用了 psql 的\getenv元命令、\set变量与:name变量插值——这些恰恰是pgregressrunner 必须在 Rust 中重新实现的 psql 行为详见下文runner 源码级原理。运行与判定run.py 与三种测试状态运行方式语料库的三种运行入口postgres/conformance/run.py # 运行整个语料库 postgres/conformance/run.py boolean # 只运行单个测试按名称 make -C postgres/conformance run-upstreamrun.pypostgres/conformance/run.py的工作流程是先用cargo build -p tursopg -p turso_pg_regress构建服务端与 runner在临时目录新建数据库文件并选一个空闲端口启动tursopg --server 127.0.0.1:port然后按schedule顺序逐个测试运行pgregress最后拆除服务端。每次完整调用都会运行语料库中的每一个测试并依据STATUS表判定结果。三种状态pass / fail / skip 与棘轮机制run.py顶部的STATUS表为每个语料测试登记了三种状态之一pass已赐福 blessed——输出必须逐字节匹配。任何 diff 或崩溃都算回归regression直接导致本次运行失败fail已知不通过 known-bad——测试会运行diff 会被报告但不会导致运行失败。不过一旦它变成逐字节匹配运行反而会失败并提示请赐福它bless it因此known-bad 列表只会不断缩小永远不会扩大skip跳过——完全不运行仅用于无法运行的测试并在条目旁注明原因当前语料库中无 skip 条目。赐福一个测试的操作非常简单修复剩余 diff 后把其状态从fail改为pass。这个设计构成一个兼容性棘轮validate_status()会校验schedule 中的每个测试都有状态、STATUS 中的每个测试都在 schedule 中防止任何一次语料库或 schedule 编辑悄悄把测试移出棘轮。容错与汇总崩溃或卡死服务器的测试会因超时被判失败runner 超时 60 秒服务器会被自动重启数据库文件跨重启保留fixtures 因此存活所以单个坏测试不会毒化整个运行。Tally汇总输出形如 total: N blessed ok, M known-bad failure(s), K regression(s), X unexpected pass(es), Y skipped, Z server restart(s) REGRESSION: name is blessed pass but its output diverged——已赐福测试出现回退XPASS: name now passes byte-exact; bless it by changing its STATUS entry to pass——known-bad 测试意外通过等待赐福。run.py的退出码语义所有测试都与状态匹配返回 0出现回归或意外通过返回 1。runner 本身的退出码见 postgres/regress/main.rs为0 全部通过、1 输出不匹配、2 工具链错误、3 至少一次传输失败服务器死亡或失联驱动应在下一个测试前重启它。make -C postgres/conformance run-upstream目标postgres/conformance/Makefile等价于直接调用./run.py而run/run-one目标则驱动另一套基于testing/sqltestrunner 的pg-sqltests语料见 postgres/conformance/pg-sqltests/两套语料互补。runner 源码级原理不调 psql直接讲 PostgreSQL 线协议pgregresspostgres/regress/main.rs与上游pg_regress最大的不同在于它不 shell out 到psql而是直接用 Rust 通过 TCP 讲 PostgreSQL wire protocolsimple query protocol并在客户端重现 psql 的转录输出——回显输入、对齐的结果表格、带LINE n:位置标记的错误报告——从而让最终输出能与期望转录逐字节比对。复现的 psql 行为runner 解释语料库用到的一整套 psql 元命令postgres/regress/main.rs 中Session::meta_command实现变量系统\set、\unset、\getenv、\gset以及:name、:name转义为 SQL 字符串字面量、:name转义为带引号的 SQL 标识符三种插值形式条件控制\if/\elif/\else/\endif布尔解析支持true/false/yes/no的前缀匹配及on/off/1/0与 psql 一致false 分支内的语句仍会回显但不会执行缓冲发送命令\g、\gset、\gexec输出控制\o结果重定向错误仍留在转录中、\echo、\qecho、\x展开显示、\pset nullNULL 显示字符串默认空、SHOW_CONTEXT错误上下文渲染COPY 支持客户端侧\copy ... from/to重写为服务端COPY ... FROM STDIN/STDOUT文件内容或脚本行经CopyData消息流式传输、内联COPY ... FROM stdin数据读到\.结束标记为止重连\c/\c -重连同一数据库变量与显示选项保留连接状态重置describe 家族\d、\d、\dD、\dT、\sv、\sf实现见 postgres/regress/describe.rs通过目录查询复刻 psql 的版式居中标题、对齐列、脚注行与结尾空行未知元命令输出invalid command \name并继续保证单个模拟缺口不会中止整个脚本。psql 对空输入行、注释剥离、语句前导空白、跨行语句保留换行保证错误位置映射到正确行等细节也都被 scannerScanner/LexState一一复刻。README 也坦承了已知模拟缺口多行字段值不渲染续行标记、超长错误位置行不裁剪为...、列宽按字符数而非终端显示宽度计算——这些缺口会在语料库需要时补齐。为什么这种转录仿真重要main.rs 的文档注释给出了一条宝贵的排障指引如果所有测试突然出现统一、系统性的 diff先怀疑仿真与 psql 之间的漂移而不是服务端。这是因为 pgregress 模拟的是pg_regress从psql -X -a -q拿到的输出形态等价设置通过启动参数发送任何转录形态的偏差都会表现为全量失败。重新同步到更新的 PostgreSQL 版本README 明确这是一次审慎的、全语料库级别的操作绝不混用版本Deliberate, whole-corpus operation — never mix releases。四步流程导出上游文件git -C postgres-checkout archive new-tag src/test/regress | tar -x重新复制文件为schedule中列出的每个测试重新复制.sql、.out含备选输出及被引用的data/文件对照上游 release notes 与parallel_schedule的 diff检查新增、删除或重命名的测试重新生成 schedule从新的parallel_schedule重新生成过滤到语料库范围更新溯源块并重新基线化更新 README 中的版本溯源块并在 CI 中重新基线化通过数。整个流程确保语料库始终跟随 PostgreSQL 最新语义同时把通过率这一度量锚定在明确的版本上。与项目其他组件的协同这套语料库不是孤岛它与项目的多个层面相互印证postgres/COMPAT.md功能兼容性矩阵逐项标注 ✅ / / ❌ 并附说明如 DISTINCT ON — Accepted but silently degrades to plain DISTINCT (wrong results)。语料库中被排除的类别与矩阵中 Not supported 的条目高度一致postgres/parser与postgres/frontendtursopg 用pg_querylibpg_query真实 PostgreSQL 语法解析 SQL经 postgres/parser/translator.rs 翻译为 Turso 原生 AST 后由 Turso 引擎执行参见 postgres/cli/README.md——No SQLite text is ever generated。因此语料库的 diff 直接反映翻译器与执行引擎的差距postgres/clitursopg本体既是 psql 风格的 REPL 也能承载 wire 服务器tursopg --server 127.0.0.1:port db-file是 run.py 启动的被测对象当前状态从 postgres/conformance/run.py 的STATUS表可见目前仅有comments测试处于pass已赐福状态其余 102 个为failknown-badskip为 0——这正是known-bad 列表只会不断缩小这一棘轮机制的起点状态。总结一套可复现、可收紧的兼容性度量体系Turso 的 PostgreSQL 兼容性工程实践可以概括为三点标尺外置语料库逐字来自 PostgreSQL 官方版本、提交、导入时间全程可溯不允许为让测试通过而修改标尺度量明确通过率即兼容性首要指标逐字节比对消除一切看起来差不多的模糊地带棘轮单向pass 回退即失败known-bad 意外通过即要求赐福skip 必须注明理由——兼容性只会单调提升且任何提升都需要显式登记。对于希望复现该度量的读者postgres/conformance/run.py与make -C postgres/conformance run-upstream是入口STATUS表是地图postgres/regress/与postgres/conformance/upstream/是全部疆域。随着功能领域如 CREATE FUNCTION、plpgsql、triggers逐步落地被推迟的测试将按既定原则陆续加入语料库标尺也随之收紧。【免费下载链接】tursoA SQL database in Rust: SQLite-compatible, now also speaking Postgres (experimental). The LLVM of databases.项目地址: https://gitcode.com/GitHub_Trending/tu/turso创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
