介绍PostgreSQL 19的内容看起来互相矛盾，有时只是用了不同阶段的资料。依据Beta 1写的预告当时可能正确，但忽略后面的撤回公告，再用它决定升级范围，就会出错。

核实新功能时，先确定消息针对的版本，再追踪后续改动。曾在测试版出现过，并不代表正式安装后就能使用。

一、这六类功能不能继续当作 19 的交付内容

早期列表中需要剔除的包括SQL/PGQ、在线切换校验和、FOR PORTION OF时间区间修改、分区合并拆分、三个生成对象DDL的函数，以及GROUP BY ALL。

GROUP BY ALL 在 Beta 3 被撤回，另外几类在 Beta 4 被撤回或移除。“六项”按功能类别计算：分区合并与拆分算一类，三个 DDL 函数算一类。它不是对全部撤回提交数量的统计。

看到介绍这些语法的文章时，不必立即认定作者编造。先看内容是不是停留在早期 Beta；但无论消息为什么过期，项目都不能继续把这些功能列入 PostgreSQL 19 升级收益。

二、三种常见的误传方式

把预告当成正式发布说明

功能预告通常在测试初期集中介绍亮点，后续撤回则出现在另一篇更新公告中。读者只看到前一篇，就会以为功能清单一直没有变化。判断时要沿版本顺序往后看，而不是停在搜索排名靠前的旧内容。

把扩展能力写成内置能力

某个扩展能实现类似需求，不代表安装 PostgreSQL 19 就能直接使用相同语法。阅读教程时，应分清内置命令、随版本提供但仍需安装的扩展，以及独立维护的第三方项目。

例如原生 REPACK 命令与已有的 pg_repack 扩展，不应只凭名字相近就混用安装和操作步骤。两者的部署条件、命令入口及使用限制要分别验证。

把演示结果写成性能承诺

“某类查询快了”“特定测试接近两倍”，都不能转写成“升级后所有业务快一倍”。数据分布、缓存、并发、索引和参数不同，结果可能完全不同。不知道别人用了什么机器、多少数据和什么查询，就不能按这个数字决定自己的服务器配置。

三、遇到新特性消息，按四步核对

1. 确认运行版本。连接目标数据库查看服务端文字版本，分清 Beta、RC、开发版和正式版。
2. 找到该主版本的发布说明。不要把 devel 文档中的下一代功能，套到 PostgreSQL 19 身上。
3. 检查后续 Beta/RC 的变更。出现 revert 或 remove，应重新确认这项能力是否仍存在。
4. 在单独的测试库里试一次，除了能不能运行，还要测试权限、空数据、重复数据和大数据量等情况。

仅执行 psql --version只能看到本机客户端版本；客户端是 19，远端服务器仍可能是 17 或 18。这种混淆也会造成“官方说支持，实际却报语法错误”的误判。

四、如何给团队维护一份可靠的功能清单？

不要只维护“支持/不支持”两列。建议增加：目标小版本、是否需要扩展、权限要求、验证日期、实际验证结果，以及撤回后替代方案。

判断功能是否好用时，要写清楚你到底想做到什么。例如，“需要按关系查找三层关联对象，并在指定延迟内返回”，比“需要使用新图查询”更有用。前者允许比较多种实现，后者容易把项目绑到尚未交付的语法上。

五、已经把过期消息写进升级方案，怎么补救？

先搜索业务程序和迁移脚本中的撤回语法。可换实现的及时改写，可以后做的另排时间；核心交付受影响时，就重新讨论方案，别留到切换当天才排查。

不要为了一项原型功能，让生产库长期停在旧Beta。正式业务采用受支持的稳定版，仍需探索的功能放在隔离测试环境中继续验证。

消息能否用于项目，最终取决于目标版本有无该能力、实际业务是否跑通，以及用不了时的处理办法。确认这些问题，比只收集功能汇总更实用。