PostgreSQL 19 为何在 beta 期大量回退功能：LLM 辅助代码审查推高门槛

许多读者会注意到，在 beta 期开始后，PostgreSQL 19 分支中回退的功能数量异常之多。出现一些回退并不罕见，也许每个周期预期会有一个。但这一次，大约有 8 到 10 个重要功能（取决于你怎么数）被回退，其中一些还是在 beta 期的很晚阶段。作为其中一些功能的开发者或提交者，我也身处受影响的一方，并收到了一些相关问题，所以我想花点时间反思一下。我会尝试稍微推及一些我并未积极参与、但同样受影响的工作，不过这些目前只是我的个人看法。

那么发生了什么？

我认为我们——指所有受影响的开发者——还没有足够的时间来充分反思这一切。但这里有一些想法。这可能是这些因素的组合，而对于每个被回退的功能，组合方式又各不相同。

也许我们就是做得不够好。也许代码就是不够好。我们会学习并改进。这很可能占一部分原因，我在这里提出来，是为了避免给人留下这样的印象：问题只出在我接下来要提到的其他因素上。
这也可能只是巧合。也许我们一直进展得太顺利，以至于试图攻克几个后来证明太难、或者至少难以按时完成的功能。
一些被回退的功能存在重大的架构缺陷，这些缺陷很难在 beta 期间快速修复。但也有一长串相对无害的问题，涉及各种边缘情况。在过去，其中许多问题要到很久以后才会浮现，我们会在此后五年里一点一点地修复。但有了 LLM 辅助代码审查，这类问题可以更快地被发现，然后你就面对着一份大约四十个缺陷报告的清单。即使平均每个只需要三行修复，处理每一个也都有固定开销，然后你就没时间了。大多数（如果不是全部）受影响的被回退功能，都是在很久以前编写的，当时 LLM 辅助代码审查还没有现在这么有用，这意味着在功能编写和提交之后，有效质量门槛被提高了。除非 LLM 辅助代码审查的能力继续以当前速度提升，否则这种情况在未来的开发周期中应该会自行解决。
由此得出的一个推论是，至少在很大程度上，据我所知，这种情况并非源于“氛围编程”。这些代码远在那成为可能之前就已编写。
因为 Vulnpocalypse，许多资深开发者从大约 4 月（PostgreSQL 19 功能冻结开始，也是 Vulnpocalypse 开始之时）到 8 月（最近一次 PostgreSQL 安全版本发布）之间，都忙于处理安全问题的修复。正因如此，beta 期间通常进行的额外审查和测试被减少了，直到 8 月才重新恢复。这可能就是为什么许多新问题在 beta 阶段很晚才被发现，以及为什么那么多回退发生得那么晚，也正是这一点让整件事如此引人注目。再次说明，有些问题更根本，但也有一长串较小的问题，我觉得如果有更多时间，比如两个月，这些问题本可以得到解决（前提是给予足够关注，但请注意 Vulnpocalypse 仍在持续）。然而社区更倾向于尽量遵守发布日程，而不是为了纳入更多修复而推迟。（而且你永远不知道长尾到底有多长。）
系统的复杂性使得某些类型的功能极难做对，而代码中没有足够的脚手架来支撑这一点。以一个抽象化的例子来说，考虑某个 SQL 层面的查询语言功能。它能与域（domain）一起工作吗？那基于复合类型的域呢？其中一个字段本身也是域呢？而且该域还有非空约束呢？其中一列被删除后又重新添加呢？而这又是某个表分区的一部分，该分区已被分离并以不同的列顺序重新附加呢？而这又是某个视图的一部分，该视图由触发器中的 security-definer 函数调用呢？如此等等。没有人能手动测试这些，甚至无法枚举这些测试用例。但 LLM 辅助的模糊测试可以很快发现其中的问题。所以这很可能需要成为未来功能开发的一部分。但我们也应该考虑让内部接口更加健壮，这样不同上下文组合就不会打开这么多新的交互可能性。

我喜欢在 PostgreSQL 中说的一句话是：“一切都能与一切协同工作”。这正是其吸引力的一部分：你可以构造这样的用例，并期望它们能正常工作。我完全不想放弃这一点。但它确实给功能开发带来了显著的代价，这一点所有人都需要意识到。
最后一点，PostgreSQL 开发社区已经考虑了一段时间：是否有可能以某种“实验性”状态提交功能，然后在主代码树中逐步成熟。这也是解决前一点的一种可能方式。对于至少部分被回退的功能来说，这本会是一个有用的工具，但我们还没有找到实现这一点的办法，而且有些工作还因此产生了误解。这是一个具体需要推进的点。

那么接下来呢？

首先，从我个人的角度，感谢每一位当面或在线表达支持与鼓励的人。这是最重要的事。我相信许多被回退的功能不久就会回归。

PostgreSQL 19 仍将是一个出色的版本。仅举几个头条项目：REPACK CONCURRENTLY、序列的逻辑复制（这本身就是一个此前被回退的功能），以及通过 pg_plan_advice 实现的计划器提示，都将使这个版本非常有吸引力。而且，在经历了所有这些额外审查之后，它将会非常健壮。

现在很难预测事情。几个月前我说过，PostgreSQL 20 可能没有新功能，只有错误修复。结果事情进展得更快，PostgreSQL 19 现在，某种程度上，主要功能只有当时预期的一半，但现在我们也已经为 PostgreSQL 20 排好了几个不错的 80% 就绪的功能，只需要完成剩下的 80% 就行了！