PostgreSQL 19延期至11月19日并新增RC2验证

PostgreSQL 19原定于10月29日发布，现推迟至11月19日，并将在11月12日增加RC2版本。RC1已于10月15日按计划推进。项目团队表示，近期多个维护分支加入了较多修复，需要先交由社区验证，以降低正式发布后的风险。

本次发布周期的另一变化，是约8至10项重要功能在Beta阶段后被撤回，部分决定甚至发生在较晚阶段。核心提交者Peter Eisentraut解释称，问题并非主要来自模型生成低质量代码，而是Claude、Codex等工具开始重新审查此前按传统流程完成的代码，将原本可能在未来数年逐渐暴露的边缘缺陷，在几天或几周内集中找出。

其中一些功能存在架构缺陷，难以在Beta后彻底修复；另一些问题只在复杂边界条件下触发。开发者一度需要处理约40份缺陷报告，即使每项平均只改动3行代码，逐项确认、测试和评估的固定成本仍会迅速累积。这意味着AI提高了软件质量，却可能暂时拖慢发布速度，并抬高实际质量门槛。

数据库尤其容易受到组合复杂度影响。SQL功能可能同时涉及domain、复合类型、分区表、视图、触发器和安全定义函数，还要处理列删除重建、分区重新挂载等组合，人类很难穷举测试。AI辅助模糊测试可以持续生成异常输入并扩展测试路径，因此未来可能需要在功能开发早期就引入，而不是等到Beta后期集中使用。

SQL/PGQ就是典型案例。该功能曾在feature freeze后经历17次修复，AI审查又发现并经人工确认了严重问题，最终未能进入PostgreSQL 19。社区估计，撤回的功能中不少有望修正后转入PostgreSQL 20。此前被认为可能以修Bug为主的PostgreSQL 20，如今反而获得了一批接近完成的新功能候选。

撤回并不完全由AI引起。部分代码本身存在设计和质量问题；今年4月至8月，许多资深开发者还集中处理安全问题，使Beta前期的额外评审和测试受到影响。同时，系统持续增长的复杂性也加剧了风险。PostgreSQL 19仍将包含REPACK CONCURRENTLY、序列逻辑复制，以及通过pg_plan_advice提供查询规划器提示等能力，团队预计它经过额外审查后会更稳健。

开发者社区的讨论焦点，正从“能否发现Bug”转向“如何分类和确认Bug”。有人认为模型能快速暴露多年技术债，也有人担心误报泛滥、导致系统过度设计。一个内部审查系统即使拥有代码仓库、Confluence和JIRA等上下文，最终被确认有效的报告约占八分之一；但也有案例显示，AI审查一个运行约10年的系统后发现39个问题，其中30个是真实缺陷。

对于复杂数据库，修复并非简单执行模型建议。某种行为在不同场景下可能分别是Bug、可接受的边界情况或架构取舍，最终应如何定义仍需维护者判断。随着AI持续扩大问题发现规模，开源项目需要建立更早的测试流程、分级机制和人工复核能力，否则软件质量提升可能反过来造成发布周期延长。