PostgreSQL 19 要迟到了，大概率拖到 11 月才发。过去十年它的发布节奏准得像钟表——不早于 9 月中，不晚于 10 月中——今年破了例。
更反常的是今年在测试阶段后期，一些相当重要的功能被撤销：UPDATE/DELETE FOR PORTION OF、SQL Property Graph Queries（SQL/PGQ）、ALTER TABLE … MERGE/SPLIT PARTITION，全部在 8 月 27 日到 9 月 15 日之间被回滚。特性冻结在每年 4 月 8 日，冻结后马上撤特性不算罕见，但在这么晚的阶段连着撤掉好几个大功能，很不正常。
Robert Haas 在 Databricks 做高级工程师，是 PostgreSQL 的主要贡献者和 committer。他的解释只有一句话：LLM 出现了。
他给了数据。2025 年 4 月 8 日到 9 月 25 日，master 分支 1037 个提交，REL_18_STABLE 724 个；2026 年同期，master 1443 个，REL_19_STABLE 1169 个。也就是说 master 上的提交数其实还略降了，涨的是回补到稳定分支的提交。
再往前的版本更明显：2025 年同期 REL_17_STABLE 收到 248 个提交，2026 年 REL_18_STABLE 收到 433 个，一年涨了 74%。
Haas 的判断很克制也很关键：不能排除今年 committer 犯的错确实更多，但"真正在项目里干活的人大概没谁会认为是这个原因"。他倾向于另一种解释——2026 年 committer 的谨慎程度和往年差不多，只是他们犯的错被 LLM 更快地找出来了。
两端一挤，时间就没了。
一头是修不完的 bug。LLM 能起草修复，但那些修复不一定正确、也不一定符合 PostgreSQL 的规范，还是得人来审、人来提交——"而这些人 2025 到 2026 之间并没有变聪明"。
另一头是本来该用来审这次发布内容的时间，被挪去处理回补分支上的安全问题和 bug 了。结果就是：到底哪些东西需要在发 v19 之前撤掉，反而更晚才弄清楚。
Haas 对这次延期本身不太担心——"从大局看这不是很长的延迟，而且它直接来自项目对质量的在意"。
他真正不安的是长期问题。原话大意是：我们手上有四十年份的 bug，人类找不到、LLM 很擅长找，这个坑要怎么填上？PostgreSQL 以后还怎么创新？他坦承现在没答案，只知道很多人正在努力找。
有一段值得单独抄下来，因为说这话的人有资格：
我成为 PostgreSQL 开发者，部分原因是它的代码库是我有幸共事过的最干净、质量最高的代码之一。AI 最近在这份代码库里找 bug 的成功，并没有改变我对它的高评价。它不完美——没有软件是完美的——但如果它的缺陷多到人眼都能看见，LLM 找到的东西只会更多。
最后那句像是给所有开发者写的："从现在到职业生涯结束，我们写的每一个特性都会被 AI 审视，那些在过去年代里可能永远不会被发现的错误，现在也许几小时内就会被找出来。这既是挑战，也是机会。"
参考来源