开源数据库「PostgreSQL（Postgres）」的下一个主要版本 19 已被推迟发布。由于人工智能审查者在代码审查中发现的缺陷数量持续增加，超过了人类开发者处理和修复的能力，版本进度受到影响，新功能的合入与缺陷修复工作也被迫放缓。

PostgreSQL 全球开发组已推迟 PostgreSQL 19 的发布，并撤下了数量异常之多的功能。作为这款热门开源数据库的最新版本，PostgreSQL 19 原定 9 月底或 10 月初发布，现在预计约在 11 月 19 日正式可用。开发者还移除了 8 到 10 项重要功能。

对于为何出现这么多被撤回的功能——这些功能的发布现已推迟到明年的 PostgreSQL 20——EDB 副总裁 Peter Eisentraut 表示，原因至少在一定程度上可归咎于开发者使用的 LLM 代码审查。EDB 是一家 PostgreSQL 支持与咨询公司，Eisentraut 也是 PostgreSQL 的主要提交者。他在一篇博客文章中说，部分被撤回的功能存在严重的架构缺陷，很难“在 beta 期间快速”修复。

不过，LLM 辅助代码审查的引入还挖出了一长串“涉及各种边缘情况的相对无害问题”。在过去，开发者可能很晚才会注意到这些问题，大概率会在发布后的五年里陆续发布补丁。“有了 LLM 辅助代码审查，这类问题能更快被发现，然后你就会面对一份包含四十个缺陷报告的清单。即使平均每个问题只需三行代码来修复，处理每个问题都有固定开销，然后你的时间就不够了。”

据悉，在编写 PostgreSQL 19 的大更新时，LLM 辅助代码审查还不如现在有用；但在发布前的几个月里，这种 AI 支持审查被理解得更透彻，也更有效。“在功能写好并提交之后，实际的质量门槛被提高了。除非 LLM 辅助代码审查的能力继续以目前的速度提升，否则这种情况应该会在未来的开发周期中自行理顺，”Eisentraut 说。他还极力说明，这些撤回并不是开发中的“vibe coding”所致，因为在大多数新功能编写时，这种技术还不存在。

Postgres 最早由 Michael Stonebraker 在 1986 年提出。1994 年，Andrew Yu 和 Jolly Chen 用 SQL 取代了查询语言 POSTQUEL；1995 年，该数据库以更宽松的许可证免费开放并可修改，并更名为 PostgreSQL。此后，它成为专业开发者中最受欢迎的数据库，这既得益于三大超大规模云厂商基于它构建的服务，也得益于多种与它线路协议兼容的分布式系统。

在被从 PostgreSQL 19 中移除的功能里，包括对 SQL 属性图查询（SQL/PGQ）的支持。该特性在 2023 年成为 SQL 标准的一部分，提供用于探索由边连接的节点之间关系的语法。由于存在未解决的问题，PostgreSQL 的这一实现被移除。当时，PostgreSQL 贡献者 Tom Lane 就警告称：“到这一步，我愿意赌上一顿晚餐：如果我们在 v19 中发布它，发布后会发现一些直到 v20 才能修复的 bug。”

尽管推迟，Eisentraut 承诺 PostgreSQL 19 仍会是“一次出色的发布”，其中会包含 REPACK CONCURRENTLY，该操作可避免用于回收磁盘空间时锁表的 VACUUM FULL 操作。“经过所有这些额外审查之后，它会非常健壮，”他说。

从 PostgreSQL 19 撤回的功能很可能会进入 PostgreSQL 20。就在几个月前，开发者还预计 PostgreSQL 20 不会有新功能，只做 bug 修复。而现在，Eisentraut 说，PostgreSQL 20 很可能会收入前一版本遗留的新功能。

讨论整体偏务实：多数人接受 LLM 代码审查/测试把 PostgreSQL 既有缺陷大量暴露出来，因此把部分特性推迟到 PostgreSQL 20 是可以理解的，甚至是一种质量提升。真正分歧在于：这些被 AI 发现的缺陷是否都该阻塞发布、其中有多少是误报或无关痛痒的边界情况，以及这是否只是 EDB 的 AI 营销说辞；少数人则更悲观，认为 AI 编码会继承训练数据里的糟粕，形成不断修 bug 的循环。

认为 AI 审查/测试是值得投入的质量手段，能把既有缺陷挖出来

• 把 AI 用于找缺陷、代码审查或安全审计，被不少人视为比让 AI 直接写代码更靠谱：多一层自动审查、模糊测试或审计，能补人工回归测试的盲区，也为老代码补历史欠债。（较多人）
• 即便编码环节完全人工或已进入全自动模式，再叠加一层审查/测试循环仍被认为值得投入；AI 在问题定位后批量清理的能力尤其被看好。（较多人）
• 需要引用时，只用一句中文意译： > 在旧代码库上跑 AI 审查会翻出很多有意思的问题，AI 明显在抬高代码质量门槛，历史欠债也要回头补。（@stickfigure）

认为被发现的很多是既往就存在、现在才被看见，延期发布可以理解

• 争论不一定是“缺陷变多了”，也可能是 AI 让大家突然“知道”了更多本来没被测出来的缺陷；无论哪种，推迟部分特性到下一版都不算意外。（较多人）
• 工具把缺陷全面暴露后，开发者失去了“没发现”的借口，每个特性都要多花时间处理；短期看像变慢，长期看整体更健壮。（较多人）
• 需要引用时，只用一句中文意译： > 之前 LWN 也在争论：到底是缺陷真的变多了，还是因为 AI 我们才突然“知道”了更多缺陷；不论哪种，推迟发布的决定都算不上意外，也可以理解。（@MBCook）

认为不该为无限或边角的缺陷停下发布，软件本就是持续演进

• AI 能找出近乎无限的缺陷，其中很多可能永远不会影响真实场景、也根本不会被注意到，因此不必等全部修完再发。（少数人）
• 现有 PostgreSQL 大概本来就有人类修不完的缺陷，直接发布即可；多数被卡住的可能只是会白白拖慢开发的边角情况。（少数人）
• 也有人调侃：如果让 LLM 当评审，走向“零缺陷”只会更慢，除非连写代码也一起交给 LLM。（少数人）
• 需要引用时，只用一句中文意译： > 现有 Postgres 大概本来就有人类修不完的缺陷，直接发就行；其中很多可能只是会拖慢开发的愚蠢边界情况。（@asdff）

警惕 AI 找缺陷的误报与设计噪音，必须人工复核和判断

• AI 报告的问题并不等于都值得修或直接能修：很多牵涉历史决策、目标取舍和用户真实需求，需要人重新讨论，而不是让 LLM 一键修改。（较多人）
• 自动生成或直接转贴的 AI 缺陷报告噪音很高，已有 Linux 内核案例显示大量报告其实是已修复、版本差异或纯误报，必须先由人类筛一遍再交给开发者。（较多人）
• 需要引用时，只用一句中文意译： > 之前 Fable 处理 Linux 内核缺陷时，82 条报告里只有 6 到 8 条是真缺陷，其余要么已修、要么是误报甚至编造；在人类把这一堆报告筛完之前，都会保持怀疑。（@Ygg2）

质疑文章把回滚归因于 LLM 审查，可能是 EDB 的 AI 营销

• 有人指出 EDB 作为 AI 厂商有利益立场，所谓“LLM 审查导致回滚”可能只是营销叙事，而不是客观技术因果。（少数人）
• 需要引用时，只用一句中文意译： > 文章把回滚归因于 LLM 审查，但 EDB 本身就是卖“Postgres AI”的厂商；照这个逻辑，在 AI 出现之前，PostgreSQL 里好像什么都没正常工作过。（@qwkaHa15）

对 AI 编码质量悲观，认为它会继承训练数据里的糟粕并形成循环

• 训练数据里塞满捷径、缺陷、热修复和“用修补去补修补”的临时手段，规模化时根本没过滤掉糟粕；最讽刺的是，修复它的办法还是更多 AI，形成无止境的金钱循环。（少数人）
• 需要引用时，只用一句中文意译： > 训练数据里塞满了捷径、缺陷、热修复和补丁摞补丁的临时手段，规模化时根本没过滤掉糟粕；最讽刺的是，修复它的办法还是更多 AI，形成无止境的金钱循环。（@F7F7F7）

有价值的补充

• Postgres 原有回归测试主要防止旧功能回退，对边界条件覆盖很弱；有开发者用 AI 做确定性仿真测试、差分覆盖引导模糊测试、形式化验证，在 pgrust 相关工作中发现约 50 个核心缺陷，并已用 Lean 证明约 10.5% 的 Postgres/pgrust 代码行为一致，这类方法能抓到解析函数里“用 isspace() 还是只 trim ASCII 空白”这种极细微差异，远超传统回归测试和人工审查。（@malisper）
• 质量保障正在变成 AI 时代项目的瓶颈和真正价值所在：AI 能铺一层测试基础，也能在问题定位后批量清理，但在“该测什么”上并不比人更强；你可以用提示词生成一个数据库，却生成不出经过 Postgres 那样亿级计算机小时实战检验的系统，小团队反而更不愿自己承担这部分质量保障，SaaS 可能会更稳固。（@jerf）
• 有类比说，AI 让缺陷像强类型语言里的类型错误一样被静态分析全面暴露，开发者失去了“没发现”的借口；每个特性都要多花时间处理，整体更健壮，但观感上反而像变慢了。（@FranOntanaya）