由 John Doe 二月 10, 2026
随着 PostgreSQL 逐渐成为企业级的“新 Linux”，定义兼容性至关重要。社区将以在里加和布鲁塞尔奠定的基础上，继续完善细粒度的兼容性矩阵和测试框架。
目录
确立兼容性标准的背景
开源数据库的蓬勃发展催生了大批衍生产品，这些产品纷纷宣称自身具备 “即插即用的兼容性”。但实际情况是，这种宣传往往会造成用户困惑，还会导致品牌价值稀释。兼容性并非非黑即白的绝对概念，即便是同一款数据库的不同版本，也会因部分功能被弃用或新增，而无法实现 100% 兼容。
去年 10 月在里加举办的 2025 年欧洲 PostgreSQL 大会上，“确立 PostgreSQL 标准” 工作组取得了各项成果。
社区已摒弃非黑即白的 “通过 / 不通过” 认证模式，转而采用精细化的兼容性矩阵判定体系。我们必须确保，当一款产品宣称 “兼容 PostgreSQL” 时，其内涵绝不仅仅是匹配了通信协议这么简单。判断兼容性，还需考量以下核心维度：
1. 核心 SQL 语法与隐式行为：兼容性绝非只看功能是否实现，更要关注用户实际依赖、却未被官方文档说明的隐式行为，比如INSERT ... SELECT ... ORDER BY语句的执行表现。
2. 系统表：各类监控工具的正常运行，依赖于pg_catalog系统表的存在，且其表现需具备可预测性。
3. 无静默失败：像CREATE INDEX这类命令，必须真正完成索引构建，而非仅返回 “执行成功”，实际却未执行任何操作。
确立 PostgreSQL 标准：何为 PostgreSQL 兼容？
何为 “PostgreSQL 兼容”？随着 PostgreSQL 成为企业级领域的 “新一代 Linux”，这一问题的重要性日益凸显。本项目诚邀 PostgreSQL 开发者、贡献者及社区成员，共同制定一套实用的 PostgreSQL 兼容性判定标准与测试框架。
会议成果总结（里加共识）
相关工作已从非黑即白的 “通过 / 不通过” 认证模式，转向精细化的兼容性矩阵判定模式。
兼容性矩阵
简单粗暴的判定结果会扼杀创新。该标准将采用带权重的核查清单（核心要求 vs 可选要求），以此适配那些在 95% 的功能上保持兼容、仅在特定功能上存在差异的衍生版本。
托管式 PostgreSQL
该矩阵允许托管式部署环境存在特定例外情况（如限制超级用户权限、限制文件系统访问），且不会因此导致整体兼容性测试不通过。
无静默失败
兼容性要求 SQL 命令实现预期功能。例如CREATE INDEX（创建索引）命令必须真正完成索引构建，而非仅返回 “执行成功” 却未执行实际操作。
研讨议题
行为特性与核心使用体验
应纳入哪些基于客户端连接执行的具体行为测试？
核心 SQL 合规性
PostgreSQL 官方文档中 “第二部分：SQL 命令” 所涵盖的所有内容均为必选要求。即便部分规则极少被使用，“兼容型” 数据库系统也必须提供支持。
隐式行为
需对用户实际依赖、但未被官方文档说明的隐式行为开展测试。
示例：INSERT ... SELECT ... ORDER BY语句必须遵循物理插入顺序（这一点对数据聚集、系统性能至关重要）。
事务隔离
必须支持标准的事务隔离级别（读已提交、可重复读、串行化），且在处理竞态条件、自动死锁检测方面的行为表现需与原生 PostgreSQL 完全一致。
错误码
针对常见错误，必须返回与原生 PostgreSQL 完全相同的 SQLSTATE 错误码，确保应用层的错误处理逻辑保持一致。
系统表
必须内置pg_catalog（系统表）。
标准监控工具必须能正常连接并查询系统表，且不会出现崩溃情况，即便数据库引擎并未填充该系统表的所有数据项。
连接性
psql（PostgreSQL 命令行工具）必须返回标准的版本结构信息，避免客户端出现警告或错误。
标准驱动程序（JDBC、psycopg）必须无需修改即可直接使用。
pg_dump（数据备份工具）必须能从社区版 PostgreSQL 中导出数据库模式，并导入至衍生版本中。
硬性限制
衍生版本的各项硬性限制指标，原则上需与原生 PostgreSQL 保持一致（如最大列数）。若相关指标出现大幅缩减，该产品将被判定为不兼容。
功能特性
功能依赖（隐含支持要求）
触发器功能隐含 PL/pgSQL 语言支持要求：尽管触发器可通过 C 语言或 SQL 编写，但绝大多数生态工具均基于 PL/pgSQL 开发。因此，实现触发器兼容性，即意味着需提供完整的 PL/pgSQL 语言支持。
执行计划与执行结果
不要求执行计划与原生 PostgreSQL 完全一致（允许在存储机制、查询规划方面进行创新）。
但功能执行结果必须完全匹配。例如，若衍生版本支持分区表功能，其分区剪枝逻辑必须能有效减少数据扫描范围，即便具体的执行计划节点与原生版本存在差异。
索引
相关命令必须执行实际操作，CREATE INDEX（创建索引）不得成为 “无实际操作” 却提示成功的命令。
数据类型
实现核心兼容性，必须支持数组（ARRAY）、二进制数据（BYTEA）、二进制 JSON（JSONB）等特定数据类型。
备份与复制
逻辑复制
必须支持双向逻辑复制（既能从某款衍生产品向 PostgreSQL 创建订阅 / 发布关系，也能从 PostgreSQL 向该衍生产品创建订阅 / 发布关系）。
必须支持通过标准的复制相关的系统视图对复制状态进行监控。
厂商定制的扩展功能不得破坏与原生 PostgreSQL 节点的连接。
物理复制
必须支持二进制文件的物理复制（或通过等效方式导出集群的标准状态）。
必须支持双向物理复制。若外部接口符合标准，厂商提供的 “中间件” 或代理服务均被认可。
混合集群：应支持原生节点与厂商衍生节点混合部署（例如，将原生主节点提升为新主节点，替代厂商衍生的备节点）。
工具
与各类标准工具（Patroni、pgbasebackup、RepMgr）的兼容性，是 “备份” 兼容性层级的核心判定指标。
恢复
必须支持时间点恢复（PITR）功能，且允许访问预写式日志（WAL）数据。
测试框架
外部架构
该测试套件独立于 PostgreSQL 代码库之外。
版本控制
测试套件的版本号与 PostgreSQL 的版本号保持数字对应，但二者为相互独立的实体。
厂商责任（“基础环境” 要求）
厂商必须提供可用于测试的兼容型构建目标环境（容器 / 基础运行环境）。
漏洞兼容考量
本测试聚焦于功能合规性验证，而非漏洞复刻。若衍生版本修复了原生 PostgreSQL 中已发现的漏洞，不应因此导致兼容性测试不通过。
低优先级事项（后续工作）
以下议题曾在往期会议中讨论，但未纳入本次核心的里加共识，或仍需进一步定义：
- 支持第三版客户端有线协议，包括所有标准认证方式（如 SCRAM、MD5、GSSAPI）。
- 与 SSL/TLS 及其各类工作模式（优先使用、强制使用、验证证书颁发机构等）的兼容性。
- 配置文件与全局配置参数（GUC）的兼容性要求（如
postgresql.conf、pg_hba.conf）。 - 对 PL/pgSQL 之外其他标准过程化语言的支持（如 PL/Python、PL/Perl）。
- 除索引创建外，各类索引方法的具体行为要求（如 GIN、GiST、BRIN 索引）。
- 对特定时间函数的支持，如
SELECT now()（获取当前时间）。 - PostgreSQL 扩展插件的兼容性标准。
- 与标准外部数据包装器（FDW）的兼容性。
- 应用程序二进制接口（ABI）稳定性检查器测试。
- 品牌标识界定：若某款产品满足所有兼容性判定标准，但并非基于 C 语言的原生实现，其应被标注为 “PostgreSQL” 还是 “PostgreSQL 兼容”？
参考
PostgreSQL 社区：PGConf.EU 2025 Establishing the PostgreSQL standard What is Postgres compatible