PostgreSQL 核心提交者 Robert Haas 於 10 月 30 日發表一篇部落格文章，說明今年的大版本為何延後。過去十年，PostgreSQL 主版本都在 9 月中旬到 10 月中旬之間發布，而 PostgreSQL 19 大機率要等到 11 月，專案團隊也可能再往後延。他給出的原因只有一句話：
「The short answer is that LLMs happened.」（簡單說，就是 LLM 出現了。）
Haas 目前是 Databricks 的資深首席軟體工程師。這篇文章是他個人的判斷，他也沒有提出新的發布日期。
三項大功能在最後一個月被撤回
每年的功能凍結都在 4 月 8 日，凍結之後撤回功能並不罕見。今年不同的地方在於時間點與份量：8 月 27 日到 9 月 15 日之間，三項大功能陸續被回退。
UPDATE/DELETE FOR PORTION OF- SQL 屬性圖查詢（SQL/PGQ）
ALTER TABLE ... MERGE PARTITION / SPLIT PARTITION
依 Haas 的說法，往年也會撤回功能，但很少在這麼晚的時間點一口氣撤掉好幾項大功能。
提交數成長六成，提交者並沒有變得草率
他把統計區間固定在每年 4 月 8 日到 9 月 25 日，比較兩年的修復數量。去年進入 REL_18_STABLE 的提交有 724 個，今年進入 REL_19_STABLE 的有 1169 個，成長超過 60%。再看上一個穩定分支，去年 REL_17_STABLE 是 248 個，今年 REL_18_STABLE 是 433 個，成長超過 74%。
多出來的這些提交，Haas 並不認為是大家的程式碼寫得比較差。他判斷提交者的謹慎程度與往年差不多，改變的是發現問題的環節：很多人開始用 LLM 替 PostgreSQL 找錯誤，然後直接回報。
「What's different now is that it's become vastly easier to find those bugs.」（現在不同的是，找出這些錯誤變得容易太多了。）
這項歸因有個缺口：提交紀錄不會標註錯誤是誰、用什麼工具發現的，文章也沒有提供 LLM 回報所占的比例。上述成長幅度是實測數字，「主要因為 LLM」則是一位資深提交者的觀察。
卡住的是人工審查
延期的機制分成兩層。第一層，錯誤變多，修復自然更耗時間。LLM 能起草修補程式，但修補未必正確，也未必符合專案規範，最後仍得由提交者逐一審完才能合併。第二層比較隱微：原本該用來審查新版本內容的時間，被資安問題與舊分支的缺陷占去，因此判斷哪些功能該撤回的決定也被拖晚了。
這件事可以和前幾天 Epoch AI 的 Firefox 實驗放在一起看。Epoch 測的是攻擊端，利用 GLM 5.3 搶在修補程式公開後的空窗期撰寫攻擊程式，每個版本約花費 1000 美元的算力。Haas 談的是維護端：同樣的能力用在已有數十年歷史的專案上，回報量先增加，而能審查程式碼的人數不會跟著增加。兩邊共同的變數是發現漏洞的成本，它下降的速度比修復成本更快。
這對中國的團隊來說也不遙遠。不少雲端資料庫產品是以 PostgreSQL 為基礎二次開發，上游合併量成長六到七成，下游跟進修補程式的工作量也可能隨之變大。實際影響有多大，目前沒有廠商公布過數字。
四十年的存量才是長遠的壓力
Haas 對這次延期本身並不緊張，他說放到長週期來看並不算久，而且這來自專案對品質的堅持。他也強調，AI 找出這些問題，並沒有改變他對程式碼庫品質的評價。
讓他沒把握的是後面的事。專案累積了約四十年沒被人發現的錯誤，LLM 能挖出不少，他的原話是「how are we ever going to catch up」（我們要怎麼追得上）。往後每一項新功能都會被 AI 審過一遍，這既是壓力，也可能讓程式碼更紮實。他沒有提出解決方案，只說自己和許多人正在想辦法。
PostgreSQL 19 最終會在哪一天發布，要看發布團隊接下來的公告。
參考來源：Robert Haas 個人部落格；CocoLoop；Epoch AI 公開實驗報告；各分支提交統計以 Haas 文中提供的口徑為準，未另行重新計算。