PostgreSQL 19 很可能无法按惯例在秋季如期发布。Beta 阶段以来，项目已经撤回了 53 个提交，其中包括 SQL/PGQ 属性图、GROUP BY ALL、分区合并与拆分等备受期待的功能。Beta 4 计划于 2026 年 9 月 24 日发布，最终版本则可能再延后数周，甚至数月。
这件事真正值得关注的，不只是“PostgreSQL 19 延迟了”，而是 PostgreSQL 社区选择了什么：当设计缺陷、错误结果或兼容性问题在大规模测试中暴露时，宁可缩小版本范围，也不把尚未成熟的功能交给生产环境。
PostgreSQL 的发布流程，为什么允许功能被撤回
PostgreSQL 的开发不是一个封闭团队内部完成的项目。一个典型功能会经历以下过程：
- 社区贡献补丁，并在多个公开 CommitFest 中持续讨论。
- 补丁通过评审后，由约 30 名核心提交者之一合并到未来版本。
- Beta 版本发布，社区开始进行大约半年的广泛测试。
- 在 Beta 阶段修复问题，必要时撤回功能。
- 发布正式版本，并通过季度维护版本提供 bug 修复和安全更新。
这套流程的关键在于：提交到代码库并不等于功能已经承诺进入最终版本。Beta 阶段仍然是发现设计问题、测试边界条件和验证升级兼容性的时间窗口。
因此，PostgreSQL 19 的大量撤回并不说明开发流程失控。恰恰相反，它说明问题在正式发布前被发现了，而且项目维护者愿意公开解释原因并承担延期成本。
被撤回的重点功能有哪些
SQL/PGQ 属性图查询
属性图查询会在关系表之上提供图查询视图，为 PostgreSQL 引入一种相对轻量的图查询能力。不过，Hackers 邮件列表中的讨论显示，这项功能仍存在更广泛的设计和成熟度问题。
这类功能一旦进入稳定版本，后续再调整语义、执行模型或兼容性都会非常困难。因此，将它推迟到 PostgreSQL 20，通常比带着不稳定设计发布更稳妥。
分区合并与拆分
ALTER TABLE MERGE PARTITION 和 ALTER TABLE SPLIT PARTITION 是长期被期待的分区管理能力。它们可以减少大型分区表维护时的数据搬运和手工操作。
但分区结构变化牵涉约束、索引、数据校验、锁和失败回滚等多个层面。PostgreSQL 19 的撤回讨论指出，相关设计问题已经来不及在当前发布周期内妥善解决。
UPDATE/DELETE FOR PORTION OF
这项功能面向时态数据和时间范围列，可以让 PostgreSQL 处理一段时间范围内的更新与删除，并自动处理边界时间计算。对于需要保存历史版本的系统来说，它很有吸引力，但边界语义和现有 SQL 行为的兼容性同样复杂。
GROUP BY ALL
GROUP BY ALL 在语法层面看起来很方便，但提交后的深入评审发现，它没有正确处理某些具有非默认相等语义的 ORDER BY 条目，可能产生错误结果。
数据库最不能接受的不是报错，而是悄悄返回错误数据。这个案例也说明，语法功能即使通过了初步测试，也必须覆盖排序、类型、操作符类和相等性规则等边界条件。
默认 TOAST 压缩改为 LZ4
该改动原本会改变 TOAST 数据的默认压缩方式，从而可能改善某些场景下的性能。但构建农场仍缺少相应支持，项目无法充分验证不同平台和编译配置下的行为，因此这项工作需要以后重新处理。
其他被撤回或受到影响的功能还包括：
pg_dumpall的非文本输出格式。JSON_TABLE ON ERROR的级联行为。- 带有非易失性约束的 domain 快速默认值。
- 逻辑复制的数据库级快照。
pg_stat_statements的嵌套查询跟踪。- PostgreSQL 运行期间在线修改数据校验和设置。
其中，逻辑复制相关的 REPACK 能力仍预计保留，但并发模型被限制为单个进程；它可以在不同表和数据库之间运行，但不能无限制地并行扩展。
延迟期间，哪些功能仍值得期待
PostgreSQL 19 并不会因为撤回一批头条功能就变成一个没有价值的版本。当前仍值得关注的能力包括：
pg_plan_advice以及查询计划提示能力。ON CONFLICT DO SELECT，让 upsert 在冲突时返回已有行。- 窗口函数中的
IGNORE NULLS。 - 多项逻辑复制改进。
- 其他 bug 修复、性能优化和查询计划改进。
数据库版本的价值从来不只由发布说明中最醒目的几个功能决定。即使属性图、GROUP BY ALL 和分区合并/拆分被推迟，新的生产版本通常仍会在稳定性、执行器行为、维护工具和复制能力上前进一步。
现在如何为 PostgreSQL 19 做升级准备
在 PostgreSQL 19 最终版本和升级说明明确之前，不建议把 Beta 版本直接用于关键生产业务。可以在测试环境中建立一套可重复的验证流程，把应用兼容性、扩展和查询结果一起纳入测试。
下面是一个可以改造的 Bash 示例。它会检查本机客户端版本、连接到目标数据库，并列出已安装扩展。运行前请修改连接参数；示例假设系统已经安装了 PostgreSQL 客户端工具。
#!/usr/bin/env bash
set -euo pipefail
DB_URL="${DATABASE_URL:-postgresql://localhost:5432/appdb}"
psql --version
psql "$DB_URL" <<'SQL'
SELECT version();
SELECT extname, extversion
FROM pg_extension
ORDER BY extname;
SELECT current_setting('server_version_num') AS server_version_num;
SQL
如果要比较升级前后的查询计划，可以在测试库中保存关键 SQL 的执行计划。不要只比较耗时，也要检查行数估算、连接顺序和是否出现了意外的全表扫描：
EXPLAIN (ANALYZE, BUFFERS, VERBOSE)
SELECT o.id, o.created_at, sum(oi.quantity * oi.unit_price) AS total
FROM orders AS o
JOIN order_items AS oi ON oi.order_id = o.id
WHERE o.created_at >= DATE '2026-01-01'
GROUP BY o.id, o.created_at
ORDER BY o.created_at DESC;
对于 Beta 版本，还应重点验证以下内容：
- 所有生产扩展是否支持目标版本。
- 备份恢复、逻辑复制和故障切换流程是否正常。
- 关键查询是否出现结果变化，而不仅仅是性能变化。
- 分区表、窗口函数、JSON 和冲突处理等边界 SQL 是否覆盖。
- 应用是否依赖未正式承诺的 Beta 行为。
- 回滚方案是否经过实际演练。
AI 正在改变数据库测试的节奏
AI 也是 PostgreSQL 19 这轮延期的重要背景之一。越来越多开发者使用 AI 工具发现 bug，并生成可以稳定复现问题的测试用例。AI 可能快速扩大测试覆盖面，但它找到的问题往往需要较大的代码修复，未必能在当前发布周期内安全完成。
这对数据库项目尤其重要：一个看似局部的修改，可能影响解析器、优化器、执行器、复制协议、扩展 API 或不同存储引擎。AI 可以帮助提出反例，却不能替核心维护者完成设计取舍和发布责任判断。
摘要中还提到，2026 年 8 月 PostgreSQL 18 的补丁包含 28 个 CVE，而过去 PostgreSQL 每个版本平均只有几个 CVE。这说明 AI 辅助审查和更深入的安全分析，正在提高问题发现率，也会让维护者面临更多需要分类、验证和修复的事项。PostgreSQL 目前还没有正式的 AI 贡献政策，预计未来会进一步明确相关规则。
对使用者的实际建议
如果你正在规划 PostgreSQL 升级，可以按下面的策略执行：
- 关键生产系统继续把 PostgreSQL 18 作为稳妥目标。 不要因为 PostgreSQL 19 的新特性宣传就提前锁定升级日期。
- 把 PostgreSQL 19 当作测试项目，而不是承诺。 关注 Beta 更新、开放问题列表和 Hackers 邮件列表中的最终结论。
- 不要依赖已经撤回的功能。 属性图、
GROUP BY ALL、分区合并/拆分等能力应按 PostgreSQL 20 规划。 - 测试结果正确性。 对数据库升级而言，错误结果比性能下降更严重。
- 为延期预留窗口。 升级计划应包含新的 Beta、RC 和正式版本时间，而不是只按照惯例中的秋季发布日期安排。
PostgreSQL 19 的延期传达了一个并不时髦、但非常重要的信号：数据库可以慢一点发布，但不能把未经充分验证的语义和数据风险推给用户。在“快速交付”和“AI 加速”的环境中，能够撤回不成熟功能、公开讨论原因，并把质量放在发布时间之前，本身就是成熟工程流程的体现。