恢复工作将继续进行，直到士气提高为止

许多读者会意识到，在测试期开始后，PostgreSQL 19 分支恢复了异常多的功能。发生一些恢复并不罕见，也许每个周期都会发生一次恢复。但这一次，大约有 8 到 10 个重要功能（具体取决于您的统计方式）已被恢复，其中一些在测试阶段已经很晚了。作为其中一些功能的开发者或提交者，我一直是其中一些功能的接收端，并且收到了一些有关它的问题，所以我想花点时间思考一下这一点。我将尝试对我没有积极参与的类似受影响的工作进行一些推断，但这只是我目前的观点。那么发生了什么？我认为我们，即所有受影响的开发人员，没有足够的时间来充分反思这一切。但这里有一些想法。 It’s probably a combination of these, and a different combination in the case of each reverted feature.也许我们只是做得不够好。也许代码还不够好。我们将学习并改进。可能是其中的一些因素，我在这里提到它是为了不给人留下我要提到的只是其他因素的印象。这也可能是巧合。也许我们一直进展顺利，以至于我们试图解决几个功能，结果发现这些功能太难了，或者至少太难及时完成了。一些恢复的功能具有重大的架构缺陷，在测试期间很难快速修复。但也存在涉及各种边缘情况的一长串相对无害的问题。在过去，其中许多问题要等到很久以后才会出现，我们会在接下来的五年里一点一点地修复它们。但是，通过法学硕士辅助的代码审查，可以更快地发现此类问题，然后您就会盯着大约四十个缺陷报告的列表。即使每个问题平均只需要三行修复，处理每个问题都会有固定的开销，然后您就会耗尽时间。大多数（如果不是全部）受影响的恢复功能都是很久以前编写的，当时 LLM 辅助代码审查不像现在那么有用，这意味着在编写和提交功能之后，有效质量标准已经提高。除非法学硕士辅助代码审查的能力以当前的速度不断提高，否则这种情况应该会在未来的开发周期中自行解决。其推论是，至少在大多数情况下，据我所知，这种情况不是由于“氛围编码”造成的。这段代码是在这种可能性出现之前就写好的。由于 Vulnpocalypse，许多高级开发人员在 4 月（PostgreSQL 19 功能冻结的开始，也是 Vulnpocalypse 的开始）和 8 月（最新的 PostgreSQL 安全版本）之间忙于修复安全问题。因此，测试期间通常发生的额外审查和测试减少了，然后在 8 月份再次增加。这可能就是为什么很多新问题在测试期很晚才被发现，以及为什么如此多的恢复发生得这么晚，这就是为什么这一切如此引人注目。同样，有些问题更为根本，但也存在一长串较小的问题，我觉得如果有更多时间，比如两个月，这些问题本来可以得到解决（只要给予足够的关注，但请注意，漏洞灾难仍在继续）。但社区更愿意尝试遵守发布时间表，而不是推迟获得更多修复。（而且你永远不知道长尾到底有多长。）系统的复杂性使得某些功能变得非常复杂，而且代码中没有足够的脚手架来支持它。作为一个抽象示例，请考虑一些 SQL 级查询语言功能。它可以与域一起使用吗？复合类型上的域怎么样？其中一个字段也是一个域吗？并且域有非空约束？其中一列被删除并重新添加？这是已分离并以不同的列顺序重新附加的表分区的一部分？这是从触发器的安全定义器函数调用的视图的一部分？等等。没有人可以手动测试这一点，甚至无法枚举这些测试用例。但 LLM 辅助的模糊测试可以很快发现问题。所以这可能需要成为未来功能开发的一部分。但我们还应该考虑让内部界面更加健壮，这样每种不同的上下文组合就不会带来如此多新的交互可能性。我喜欢说，在 PostgreSQL 中，“万事皆可”。这是呼吁的一部分，你可以构建这样的案例并期望它们能够发挥作用。我根本不想放弃这一点。但它确实对每个人都需要意识到的功能开发造成了重大惩罚。最后一点