撤回功能與延期是兩件事
PostgreSQL 19 這一輪有兩則消息，原因並不相同。
第一，功能撤回。 PostgreSQL 主要 committer Peter Eisentraut 在 2026 年 10 月 9 日的部落格寫道，PostgreSQL 19 在 beta 期間開始後，撤回了約 8 到 10 項重要功能（看怎麼算），有些撤得相當晚；過去一個週期大概只會撤回一項。這些功能可能改在明年的 PostgreSQL 20 推出。
第二，正式版延期。 PostgreSQL 發布團隊的 Jonathan Katz 在 9 月 28 日的郵件中，原訂正式版（GA）為 10 月 29 日；10 月 10 日再通知改到 11 月 19 日。官方理由是舊版分支累積了大量修正，團隊想先在 11 月 12 日推出 RC2 納入這些修正，再正式發布。這封郵件沒有提到 AI，也沒有提到功能撤回。
The Register 在 10 月 16 日把兩件事放在同一篇報導裡，以下談的 AI 審查，是 Eisentraut 對「功能撤回」的部分解釋。
四十份缺陷報告修不完
Eisentraut（EDB 副總裁）在部落格列出好幾個可能原因，強調每項功能的情況不同，其中一個是開發者使用的 LLM 程式碼審查。
他指出，有些被撤回的功能確實有重大架構缺陷，很難在 beta 期間快速修好。但 LLM 輔助審查也挖出一長串「相對無害、涉及各種邊角情況」的問題。換作以前，這類問題可能要到很久以後才會被發現，大多會在發布後五年內陸續修正。
他描述得很生動：有了 LLM 輔助審查，這類問題被找到的速度快得多，「然後你就盯著一份四十份缺陷報告的清單。就算每個平均只需要三行修正，處理每一份都有固定的成本，最後時間就不夠了。」
不是 vibe coding 的錯
Eisentraut 特別強調，這次撤回不是 vibe coding 造成的，因為大部分新功能在撰寫時，這種做法還沒出現。
報導指出，PostgreSQL 19 的大型更新寫成時，LLM 輔助審查還沒有現在這麼有用；但在發布前幾個月，大家越來越懂得怎麼用，效果也越來越好。用 Eisentraut 的話來說，實際的品質門檻在功能寫好並提交之後被拉高了。他認為，除非 LLM 審查能力繼續以目前的速度進步，否則之後的開發週期應該會自行恢復正常。
他也提到另一個因素：因為 Vulnpocalypse，許多資深開發者從 4 月（PostgreSQL 19 功能凍結）到 8 月都忙著修安全問題，beta 期間通常會有的額外審查與測試因此減少，直到 8 月才恢復，這可能是許多問題到 beta 後期才被發現的原因。
SQL/PGQ 被撤下
被撤下的功能之一，是 SQL 屬性圖查詢（SQL/PGQ）。它在 2023 年成為 SQL 標準的一部分，提供用來探索節點與邊之間關係的語法。PostgreSQL 的實作因為有未解決的問題而被移除。
PostgreSQL 貢獻者 Tom Lane 當時警告，他願意賭一頓晚餐：如果 v19 就推出這項功能，發布後一定會發現要等到 v20 才能修的 bug。
撤回之後，Eisentraut 仍然保證 PostgreSQL 19 會是「很棒的版本」，其中包含 REPACK CONCURRENTLY，可以避免 VACUUM FULL 回收磁碟空間時鎖住整張表。他還說，經過這麼多額外審查，這個版本「會非常穩健」。另一個有趣的轉折是：Eisentraut 幾個月前曾說，PostgreSQL 20 可能只修 bug、沒有新功能；現在反而已經有幾項延後的功能排隊等著進 PostgreSQL 20。
用 AI 審碼前先排好時間
這則新聞聽起來有點黑色幽默：AI 審查太認真，認真到人類來不及在發布前修完，只好先把功能撤下。但對已經在用 AI 審查程式碼或文件的團隊來說，它也提醒了幾件事（以下為本站整理的建議，非報導內容）：
- 先分類再修：AI 一次丟出幾十個發現時，先分出會擋下發布的重大問題，以及可以排進後續版本的小問題。
- 預留修正時間：每個發現就算只要改幾行，處理也有固定成本，排程時要算進去。
- 越早審越好：在功能剛寫好時就跑 AI 審查，而不是等到發布前才一次面對整份清單。
