许多读者可能已经意识到，在PostgreSQL 19分支的beta阶段开始后，撤销了异常高数量的特性。出现一些撤销并不奇怪，可能每个周期预计会有一个。但这次大约有8到10个重要特性被撤销，具体取决于如何计算，有些是在beta阶段晚些时候才被撤销的。我作为一些特性的开发者或提交者，收到了关于这方面的一些问题，所以我想花一点时间来反思这个问题。我会尝试推断一下与此相关但我没有积极参与的工作，但这些只是我目前的个人观点。那么发生了什么？我认为我们，也就是所有受到影响的开发者，并没有足够的时间来充分反思这一切。但这里有一些想法。这可能是这些因素的结合，而每个撤销特性的情况也都有不同的组合。也许我们做得不够好。也许代码本身不够好。我们会学习并改进。可能是这些原因的一部分，我在这里提到它是为了不让人误认为只是其他因素导致了撤销。也可能只是巧合。也许我们之前的进展非常顺利，以至于尝试处理几个特性，结果发现这些特性太难，或者至少太难来得及完成。其中一些被撤销的特性具有明显的架构缺陷，这在beta阶段是很难快速修复的。但还有一系列相对无害的问题涉及各种边缘案例。过去，这些问题可能不会在很久之后才浮现出来，而我们将在接下来的五年中逐渐解决它们。但借助LLM辅助代码审查，这类问题可以更快被发现，然后你会看到一份像四十个缺陷报告那样的清单。即使每个缺陷平均只需三行修复，处理每个缺陷仍有固定的开销，然后你就会耗尽时间。大多数如果不是所有受到影响的撤销特性都是在很久以前编写的，当时LLM辅助代码审查没有现在这么有效，这意味着在特性编写和提交后的时间里，实际的质量标准已经提高。除非LLM辅助代码审查的能力以目前的速度不断提高，否则这种情况应该会在未来的开发周期中得到解决。一个推论是，至少在大多数情况下，据我所知，这种情况并不是由于“氛围编码”。这些代码是在这种可能性出现之前很久前就编写的。由于Vulnpocalypse，许多资深开发者在大约四月（PostgreSQL 19功能冻结的开始，也是Vulnpocalypse的开始）和八月（最近的PostgreSQL安全版本）之间忙于解决安全问题的修复。因此，beta阶段通常发生的额外审查和测试减少了，而在八月重新恢复。这可能就是为什么在beta阶段晚些时候发现了很多新问题，以及为什么如此多的撤销发生得如此晚，这使得这一切变得非常显著。再次强调，一些问题更为根本，但也有很多较小的问题，我感觉如果再给我们一些时间，比如两个月，可能会得到解决（考虑到合适的关注，不过注意到Vulnpocalypse仍在进行中）。但社区更倾向于坚持发布日程，而不是延迟以获得更多的修复。（而且你永远不知道一个长尾究竟有多长。）系统的复杂性使得某些类型的特性极其复杂，很难做到完美，而代码中也没有足够的支撑来支持这一点。考虑一个抽象的例子，比如某个SQL级的查询语言特性。它与域一起工作吗？与复合类型上的域怎么样？其中一个字段也是一个域？而该域有一个非空约束吗？并且其中一列被删除并重新添加？而这又是一个在不同列顺序下被分离和重新附加的表分区的一部分？而这又是一个由安全定义函数的触发器调用的视图的一部分？等等。没有人能手动测试这些，甚至列举出这些测试用例。但LLM辅助模糊测试可以快速发现其中的问题。因此，这可能需要成为未来特性开发的一部分。但我们也应该考虑让内部接口更加健壮，以便每种不同的上下文组合不会打开太多新的交互可能性。我喜欢说，在PostgreSQL中，“一切都可以与一切兼容”。这是其吸引力的一部分，你可以构造这样的案例并期待它们能够正常工作。我一点也不想放弃这一点。但这确实对特性开发施加了显著的影响，大家需要意识到这一点。作为最后一点...