PostgreSQL 19 撤回 8 到 10 个功能、正式版定在 11 月 19 日：AI 审查是不是原因，核心开发者自己吵起来了

日程先挪了一个月

PostgreSQL 全球开发组 10 月 15 日发布 PostgreSQL 19 RC1。公告说，11 月 12 日的常规更新版会带来大量修复，发布团队决定先把这些修复并进 19，所以当天再出一个 RC2，正式版计划 11 月 19 日。此前多年 PostgreSQL 都按时在秋季发版，这一次晚了约一个月，起因是 beta 期间撤回了一批已提交的功能，SQL/PGQ 属性图查询、在线切换数据校验和、UPDATE/DELETE FOR PORTION OF 都在其列。

「四十来条缺陷报告」

提交者 Peter Eisentraut 10 月 9 日在个人博客撰文说，这次撤回了 8 到 10 个重要功能，以往大约一个周期一个。他列了几种原因，其中一条是：部分功能有难以在 beta 期修好的架构缺陷，此外还有一长串相对无害的边界情况。过去这类问题会在之后五年里陆续冒出来、慢慢修；有了 LLM 辅助代码审查，它们很快被找出来，「然后你面对的是四十来条缺陷报告」，就算平均每条只要三行，处理每条都有固定开销，时间就不够了。

他强调这些功能大多写于 AI 审查还不好用的时候，等于提交之后质量门槛被抬高了，「不是氛围编程导致的」；另一个因素是今年 4 月到 8 月大量资深开发者忙于安全修复，beta 期的常规审查少了。

逐条翻查之后的另一种说法

提交者 Tomas Vondra 10 月 1 日的文章反对把撤回归咎于「AI 找出了修不了的大 bug」。他翻查 5 月 20 日到 9 月 16 日 12 次撤回背后的邮件列表，结论是只有 4 次属于「AI」或「可能是 AI」，其余来自常规的人工审查。他按开发日统计了 PG14 以来的撤回次数，PG19 并不突出，变的是时间：往年撤回集中在功能冻结后不久，今年冻结后一度没有动静，9 月初才集中爆发。他认为 AI 的影响更多体现在安全队列上：去年约 5 个 CVE，今年已到 44 个，其中一些由 AI 协助报告，处理它们的正是负责审查功能的那批人。

Christophe Pettus 10 月 12 日在博客 The Build 中补充，唯一明确由 AI 引出的撤回是 CREATE SCHEMA 扩展：Noah Misch 用 Opus 5 审查，报告里多数是噪音，只有一条他认定为严重，最终撤回靠的是他自己的设计判断。

对在用 AI 审代码的团队

两边的分歧在归因，不在事实：AI 审查和 AI 安全报告确实让问题来得更快，瓶颈变成了有经验的人能分拣、修复多少。项目越老、组合情况越多，越需要提前给这股流量留出人手和时间。