https://peter.eisentraut.org/blog/2026/10/09/the-reverts-will-continue-until-morale-improves
回退会一直继续，直到士气好转
2026 年 10 月 9 日
许多读者会知道，在 beta 期开始后，PostgreSQL 19 分支回退了异常多的功能。有一些回退并不罕见，每个周期也许可以预期一个。但这一次，大约有 8 到 10 个重要功能被回退（取决于你怎么数），而且其中一些在 beta 期相当晚的时候才被回退。作为其中一些功能的开发者或提交者，我处在接收端，也收到了一些相关问题，所以我想花点时间反思一下。我会尝试稍微外推到一些我并未积极参与的、受类似影响的工作，但这些目前只是我的个人观点。
那么发生了什么？
我不认为我们------意思是所有受影响的开发者------有足够时间充分反思这一切。但这里有一些想法。可能是这些因素的组合，而对于每个被回退的功能，组合方式不同。
也许我们只是做得不够好。也许代码就是不够好。我们会学习并改进。可能有一部分是这个原因，我在这里提出来，是为了不给人一种印象，以为只是我要提到的其他因素。
这也可能是巧合。也许我们一直顺风顺水，以至于试图攻克几个后来证明太难、或者至少太难以按时完成的功能。
一些被回退的功能有重大的架构缺陷，很难在 beta 期间快速修复。但也有一长串相对无害的问题，涉及各种边缘情况。在过去，其中许多问题要到很久以后才会浮现，我们会在此后五年里一点一点修复它们。但有了 LLM 辅助代码审查，这类问题可以被更快发现，然后你就面对一份大约四十个缺陷报告的清单。即使每个平均只需要三行修复，处理每一个都有固定开销，然后你就没时间了。大多数（如果不是全部）受影响的被回退功能，都是在 LLM 辅助代码审查还没有现在这么有用的时候写的，这意味着有效质量标准在该功能编写和提交之后被提高了。除非 LLM 辅助代码审查的能力继续以当前速度提升，否则这种情况应该会在未来的开发周期中自行解决。
由此得出的一个推论是，至少在很大程度上，据我所知，这种情况不是由于"氛围编程"。这些代码早在那种可能性出现之前就写好了。
由于"漏洞末日"（Vulnpocalypse），许多资深开发者在大约 4 月（PostgreSQL 19 功能冻结开始，也是 Vulnpocalypse 开始）到 8 月（最近一次 PostgreSQL 安全发布）之间忙于处理安全问题的修复。因此，beta 期间通常额外的审查和测试减少了，然后在 8 月又恢复。这可能就是为什么很多新问题在 beta 期很晚才被发现，以及为什么这么多回退发生得这么晚，而这正是让这一切如此引人注目的原因。同样，有些问题更根本，但也有一长串较小问题，我觉得如果有更多时间，比如两个月，这些本可以解决（前提是有足够专注，但请注意 Vulnpocalypse 仍在进行中）。但社区倾向于尽量遵守发布日程，而不是延迟以纳入更多修复。（而且你永远不知道一条长尾到底有多长。）
系统的复杂性使得某些类型的功能极其难以做对，而代码中没有足够的脚手架来支持这一点。考虑一个抽象的例子，某个 SQL 级查询语言功能。它能与 domain 一起工作吗？那么基于复合类型的 domain 呢？其中一个字段也是 domain 呢？而且该 domain 有 not null 约束呢？而且其中一列被删除又重新添加了呢？而且这是一个表分区的一部分，该分区已被分离并以不同的列顺序重新附加了呢？而且这是一个视图的一部分，该视图从触发器中的 security-definer 函数被调用呢？等等。没有人能手动测试这些，甚至无法枚举这些测试用例。但 LLM 辅助模糊测试可以很快发现其中的问题。所以这可能需要成为未来功能开发的一部分。但我们也应该考虑让内部接口更健壮，这样每种不同的上下文组合就不会打开这么多新的交互可能性。
我喜欢说，在 PostgreSQL 中，"一切都与一切一起工作"。这是其吸引力的一部分：你可以构造这样的案例，并期望它们能工作。我完全不想放弃这一点。但它确实给功能开发施加了显著的惩罚，每个人都需要意识到这一点。
最后一点，PostgreSQL 开发社区已经考虑了一段时间，是否有可能以某种"实验性"状态提交功能，然后在主树中使其成熟。这也可能是解决前一点的一种办法。对于至少一些被回退的功能来说，这会是一个有用的工具，但我们还没有找到实现的方法，而且一些工作因与此相关的误解而受到影响。这是一个具体需要着手的点。
那么接下来呢？
首先，从我个人角度来看，感谢所有当面或在线表达支持和鼓励的人。这是最重要的事情。我相信许多被回退的功能不久就会回来。
PostgreSQL 19 仍将是一个出色的版本。REPACK CONCURRENTLY、序列的逻辑复制（本身就是一个之前被回退的功能），以及用 pg_plan_advice 进行规划器提示，仅举几个头条项目，就会让这个版本非常有吸引力。而且经过所有这些额外审查之后，它将会非常健壮。
现在很难预测事情。几个月前我说过，PostgreSQL 20 可能没有新功能，只有缺陷修复。结果事情发展得更快，PostgreSQL 19 现在某种程度上只有当时预期的一半重要功能，但现在我们也已经有一些很不错的、80% 就绪的功能排队等待 PostgreSQL 20，只差那剩下的 80% 要完成！