PostgreSQL 19 Beta 4 发布：特性大砍
今天中秋，先祝大家节日快乐。
节日里说条不太团圆的新闻：PostgreSQL 19 Beta 4 昨天发布了。
这本来是好事，但还是有点令人悲伤。
老冯在 pgsql.cc 上维护着 PG 各个版本的中文文档，每出一个 Beta，都要跟上游对一遍 diff，把改动同步进译文。这次 diff 跑出来的结果是新增 618 行，删除 5,021 行。一个 Beta 更新删掉的内容是新增的八倍多。
原因很简单：PG 19 在最后一轮 Beta 里，一口气砍掉了五个大功能。
砍掉了什么
另外还回退了三处改动：CREATE SCHEMA 的两项扩展，以及在 postmaster 进程里强制把 LC_COLLATE 设成 C 的那个改动。
这些都不是边角料。SQL/PGQ 是 SQL:2023 标准里的属性图查询，能直接在关系表上跑图查询，本来是 PG 19 的杀手级特性。在线开关校验和，DBA 盼了多少年。分区合并拆分是 Oracle 用户迁过来第一批会问的运维操作。而且这已经是分区合并拆分第二次被撤了，PG 17 当年也合进去过一次，最后同样在发布前撤掉。
为什么砍
把 diff、提交记录和邮件列表连起来读会发现，五个功能撞上的是同一个问题：一个新功能光自己能跑通不算数，它得接进数据库原有的整套规则里。 而且对象被修改、事务并发、数据要恢复的时候，这些规则还得照样成立。
SQL/PGQ：建属性图要求底层表有主键。可图建完之后，你能把主键删掉，图照样在。Robert Haas 举的这个例子，连并发都不需要就能触发——创建时校验过的约束，建完就没人管了。有些行为连“应该是什么样”都还没共识，发布管理团队（RMT）决定先撤，免得以后背上向后兼容的包袱。
时态更新与删除：
FOR PORTION OF能只改有效期里的一段，比如一份全年合同只调第三季度的价格。可两个会话同时改同一份合同的不同时段时，业务上明明井水不犯河水，第二个会话却返回UPDATE 0，想改的没改上。到九月中旬，行为语义还没吵出结论，Peter Eisentraut 拍板撤回。注意，撤的只是这套 DML 语法，范围类型和时态约束都还在。分区合并与拆分：父表和分区的生成列表达式不一致时，合并完，已有记录的生成列值变了，逻辑解码里也只看得到插入，看不到删除。你以为自己调整的只是数据怎么放，结果连数据本身都变了，这是最不能忍的。
DDL 重建函数：生成一条
CREATE ROLE容易，完整重建一个角色难，因为角色、库、库级配置之间的依赖，全都甩回给了调用方。说白了，这是在服务端另写一套pg_dump，以后每加一个对象属性，都得维护两份实现。在线校验和：Beta 期间修了好几轮，社区还是不放心。校验和本来就是用来判断数据坏没坏的，要是连它自己处在什么状态都得打个问号，它就没有存在的意义了。离线的
pg_checksums工具还在。
老冯对这轮撤回是支持的。PG 最值钱的从来不是功能清单，是可依赖。 功能晚一个版本，问题不大。语义有问题的功能一旦进了正式版，用户就会围着它建应用、建数据、建运维流程，到时候再改，代价比晚一年大得多。
被撤也不等于判了死刑。时态主键（WITHOUT OVERLAPS）在 PG 17 被撤过一次，到 PG 18 就回来了，只是晚了一年团圆。当然反过来也一样，撤了不代表 PG 20 一定有，别往路线图里写。
PG 19 还剩什么
砍了五个，好在 DBA 最盼的几样还在：
REPACK和REPACK CONCURRENTLY都在。不过并发执行期间仍有需要拿强锁的阶段，别当成“全程无锁”去宣传。WAIT FOR LSN在，能帮应用在备库上实现“读己之写”，前提是遵守文档里关于事务和快照的要求。postgres_fdw导入远端统计信息 在，选项从restore_stats改名成了import_stats。- 下面这些也都还在：逻辑复制同步序列值、
wal_level = replica时按需启用逻辑解码、查询计划建议（pg_plan_advice）、autovacuum 评分机制，以及COPY FROM的 SIMD 优化。
Beta 4 自己也修了一堆东西，包括这几类：
REPACK的崩溃。WAIT FOR的死锁。- 从老版本往 v19 做逻辑复制时的初始表同步。
- 逻辑复制冲突检测。
- 访问并发分离未完成的分区时的崩溃。
按计划，10 月上旬出 RC，顺利的话 10 月正式发布。想在 PG 19 上做规划的朋友记住一条：Beta 里出现过的功能，不等于正式版里会有，一切以最终的发布说明为准。
砍了五个，也进了一个
Beta 4 也不全是删。9 月 23 日，老冯提交的 PostgreSQL 简体中文本地化消息翻译合进了上游，随 Beta 4 一起发布。
也就是说，现在装上 PostgreSQL 19，系统语言是 zh_CN 的话，你看到的报错和提示信息就是老冯翻译的版本了。欢迎大家尝鲜，觉得哪里译得不对、不顺，随时给我反馈。
目前进去的只有 PG 19 的简体中文。繁体中文 zh_TW 和 PG 14 到 18 的回补也都做好了，应该会在正式版本里进来。
顺便：pgsql.cc 把 28 年的手册补齐了
pgsql.cc 是 postgresql.org 官网的全站中文翻译。之前收录的是 PG 10 到 19（外加 devel）的完整中文手册。这次除了把 Beta 4 的文档改动同步进去，还专门给 6.3 到 13 这 24 个已停止维护的版本做了历史手册归档，在线版和 PDF 都有。
6.3 是 1998 年的版本。从 6.3 到 19，三十个大版本、横跨 28 年的 PostgreSQL 手册，现在都能在 pgsql.cc 上用中文读到。
为什么要翻这些“没人维护”的老版本？因为老冯最近在做一个 PG 知识图谱项目，要把每一个参数、消息、系统目录、函数的完整历史变化都理清楚，得有一份准确的中文文档打底。这个项目还没正式发布，还得再校一轮，敬请期待。
题外话：GLM 的下场
当然，干翻译，还有个更实在的原因：手头的 GLM 套餐得找个地方用掉。ZCode 上传仓库那件事之后，我就不再拿它干任何开发工作了。但 GLM 5.3 的水平确实还行，额度浪费了怪可惜，拿来翻译、核验、校对文档再合适不过。
我看到有人说 ZCode 新版本还在上传数据，确实不太老实。反正只要智谱不怕噎着，PG 文档给你吃得够够的。
所以这活儿主要是 ZCode / GLM 干的，Codex 负责最后把关。我让 Codex 当监工，在一台机器上 24 小时抽着 ZCode 干活，不停地审阅、校对 PG 中文文档，连着跑了一周（v1 套餐只有 5 小时限额，没有周限额）。每份文档差不多校了七八轮，一直校到几个 Agent 都没法再硬挑出毛病为止。