许多读者已注意到，PostgreSQL 数据库（PostgreSQL）的 19 分支进入测试期后，被回退功能异常多。每个周期出现一次左右回退并不罕见，但这次约有 8 到 10 个重要功能被回退，有些还发生在测试期很晚时。作为其中一些功能的开发者或提交者，我也受影响，并收到一些问题，因此想花些时间反思；我也会稍微推及自己未直接参与的受影响工作，不过这些目前只是个人看法。

许多读者已经注意到，在 PostgreSQL 19 分支进入 beta 期之后，有异常多的功能被回退。有一些回退并不罕见，也许每个周期预期会出现一次。但这一次，按不同统计方式大约有 8 到 10 个重要功能被回退，而且其中一些直到 beta 期很晚才发生。作为其中一些功能的开发者或提交者，我也身处其中，并因此收到一些问题，所以想花点时间反思一下。我会尝试把结论推及一些我没有直接参与、但同样受影响的工作，不过这些只是我目前的看法。

那么，发生了什么？

我觉得，包括所有受影响开发者在内的我们，还没有足够时间全面反思这一切。但这里有一些想法：原因大概是以下几点的组合，而每个被回退的功能对应的组合又各不相同。

• 也许我们做得不够好，代码本身不够好。我们会吸取教训并改进。这确实是部分原因；我提到这一点，是为了不让人以为下面说的其他因素才是唯一原因。
• 也可能只是巧合。也许我们之前势头太顺，于是尝试攻克若干难度过高、或至少无法按时完成的功能。
• 部分被回退的功能存在重大架构缺陷，很难在 beta 期间快速修复。但同时也有一串相对无害的边缘情况问题。过去，这类问题很多要到很久以后才暴露，然后在随后五年里一点点修掉。可是有了 LLM 辅助代码审查，这类问题能被更快发现，于是你面前会摆着大约四十份缺陷报告。即便平均每份只需要三行代码修复，处理每一份都有固定开销，时间就这样耗尽了。受影响的功能即便不是全部，也大多是在 LLM 辅助代码审查还不如今日有用时写的，也就是说，在功能写好并提交之后，实际的质量门槛被提高了。除非 LLM 辅助代码审查的能力继续以当前速度提升，否则这种情况在未来的开发周期里应会自行缓解。
• 由此推论：至少在我看来，这种情况大体上并非“vibe coding”所致。这些代码早在那种做法成为可能之前就写好了。
• 由于 Vulnpocalypse，许多资深开发者在大约 4 月（PostgreSQL 19 功能冻结开始，也是 Vulnpocalypse 开始）到 8 月（最近一次 PostgreSQL 安全版本发布）之间忙于修复安全问题。因此，beta 期间通常会进行的额外审查和测试减少了，直到 8 月才重新捡起来。这可能就是为什么大量新问题在 beta 期很晚才被发现，以及为什么这么多回退发生得如此之晚，也正是这件事如此引人关注的原因。同样，有些问题更根本，但也有一串较小问题；我感觉如果有更多时间，比如两个月，这些问题本可以被处理掉（前提是投入足够精力，但要注意 Vulnpocalypse 仍在持续）。不过社区更倾向于尽量遵守发布日程，而不是为了纳入更多修复而延期。（而且你永远不知道一条长尾到底有多长。）
• 系统的复杂性使得某些功能极难做对，代码中也缺乏足够的支撑结构来应对。举一个抽象例子：某个 SQL 层面的查询语言功能。它能否用于域？用于基于复合类型的域呢？某个字段本身也是域？域带非空约束？某列被删除后又重新添加？这属于一个以不同列顺序 detach 又 attach 的表分区？它又属于一个视图，而该视图被 security-definer 函数从触发器中调用？如此等等。没人能手动测试，甚至无法枚举这些测试用例。但 LLM 辅助模糊测试能很快发现其中的问题。所以未来这很可能需要成为功能开发的一部分。我们还应考虑让内部接口更稳健，以免每种上下文组合都开启大量新的交互可能。

我常说，在 PostgreSQL 里，“everything works with everything”（一切都能与一切配合工作）。其吸引力正在于，你可以构造出上面这类情况，并预期它们能正常工作。我完全不想放弃这一点。但它确实给功能开发带来了显著代价，所有人都必须意识到。

• 最后一点：PostgreSQL 开发社区一段时间以来一直在考虑，以某种“experimental”（实验性）状态提交功能，然后在主树中逐步成熟。这也能应对上一点。对至少部分被回退的功能来说，这本来会是个有用的工具，但我们还没找到实现方式，而且部分工作就受累于与此有关的误解。这是一个值得推进的具体方向。

那么，接下来呢？

首先，从我个人的角度，感谢所有当面或在线上向我表达支持和鼓励的人。这最重要。我相信，许多被回退的功能不久后会回归。

PostgreSQL 19 仍会是一个出色的版本。仅举几个主要项目：REPACK CONCURRENTLY、序列的逻辑复制（logical replication of sequences，本身就是一个此前被回退过的功能），以及使用 pgplanadvice 的计划器提示（planner hinting），都会让这个版本非常有吸引力。而且经过所有这些额外审查，它会非常稳健。

现在很难预测。几个月前我说过，PostgreSQL 20 可能不会有新功能，只做 bug 修复。结果事情发展更快：如今 PostgreSQL 19 差不多只有当时预期的一半主要特性，但我们也已经为 PostgreSQL 20 排上了几个不错的、号称 80% 就绪（80%-ready）的功能，只差把剩下 80% 做完！

多数评论支持 Postgres 回退那些已进入测试版却无法在发布前达到可用状态的功能，认为对基础软件来说这是重视质量、倾听社区的正确做法。讨论中的分歧不在于回退本身是否该做，而在于少数人质疑 Postgres 是否早已“完成”、是否还有必要继续开发新版本；同时，多位评论者合力澄清标题只是点击诱饵，回退并非领导无能或“氛围编程”所致，真正原因更可能是 LLM 代码审查集中暴露了大量历史边缘情况。

支持回退功能，认为这是质量控制与倾听社区的表现

• 合并意见：进入测试版的功能若无法在发布前达到满意状态，回退虽然令人遗憾但正确；对 Postgres 这类基础项目来说，严格的回退说明质量控制认真，也好过让投入生态的社区失望、转向其他方案。团队承认问题并做纠正，值得肯定。（较多人） > 对 Postgres 这样基础的项目来说，回退得越多反而越好。（@swiftcoder）

认为标题是点击诱饵，回退与领导层无能、“氛围编程”无关

• 合并意见：标题中“将持续到士气改善”的说法原本是讽刺反应迟钝、无能领导层的惯用句式，用在这里并不公平；不了解注意力经济的人容易把标题当成文章观点，其实它只是点击诱饵。文章也已明确说明，这种情况不是“氛围编程”造成的，相关代码早在那种可能性出现之前就已写好，Hacker News 用户应读完再评论。（较多人） > “某事将持续到士气改善”通常是用来讽刺昏庸领导层的说法，用在这里并不公平。（@wodenokoto）

质疑 Postgres 是否还需要持续开发新版本

• 少数意见：有人提出，既然 Postgres 可能已经足够成熟，是否还有必要继续使用新版本并投入开发；这种“是不是已经做完了”的疑问只在讨论中零星出现。（少数人） > Postgres 是不是已经做完了，还有必要继续用新版本并持续开发吗？（@TZubiri）

有价值的补充

• 回退可能与 LLM 代码审查的引入有关：LLM 审查发现了大量以往要很多年才会暴露的边缘情况，待处理问题的数量超出了团队在发布前能完成修复的范围；相关代码并非人工智能生成，因此这与“氛围编程”无关。
• 有开发者结合自身经历补充：LLM 非常擅长指出人们可能几年都发现不了的边缘情况，这种体验虽令人沮丧，但确实能推动质量提升。
• 有评论建议，对许多项目来说或许到了做功能冻结的时候，应把 LLM 用于提升测试覆盖率、运行自动化代码审查，并让开发者摸索如何把 LLM 融入开发流程；同时提醒，对手已经在用被去除安全限制的 LLM 搜索漏洞，必须保持领先，这是一个安全向的冷知识。