PostgreSQL 19哪些功能被撤回？SQL/PGQ图查询未交付的原因

早期介绍里提到的PostgreSQL 19图查询、在线校验和切换、分区合并拆分，后来有一些又从测试版中移出。功能先进入公开测试，并不能保证最终正式版一定保留。

SQL/PGQ属性图查询在Beta 4被撤回，所以升级到19不能直接获得这项原生能力。后面是否重新加入、进入哪个版本，还要等待新的开发与发布安排。

一、到底撤回了哪些功能？

表中将用户常见功能归为六类，不能把这个数量等同于全部撤回提交。分区合并拆分、三个DDL函数都能按不同口径分别计数，Beta 4还撤回了涉及进程排序区域设置的一项内部改动。

二、SQL/PGQ 图查询是干什么的？

假设你要查“某个人的朋友，又认识了哪些人”，或者“一个设备出问题，会影响哪些关联设备”。这种查询关心的重点，是对象之间的联系，以及顺着联系还能找到谁。

用属性图来描述时，人、设备等对象是“点”，它们之间的联系是“边”，点和边还可以带上名称、时间、类型等属性。SQL/PGQ 的方向，就是让数据库用标准 SQL 表达这类图关系查询。

它吸引人的地方，是不一定要为了查关系，再把数据搬去另一套系统。但标准存在、演示能运行、最终版本能稳定交付，是三个不同的阶段，不能混为一谈。

三、都进入测试了，为什么还要拿掉？

测试版就是用来找问题的。一个功能在简单例子里表现正常，换成复杂权限、多层查询、大量数据或其他功能一起使用，可能才暴露出问题。

Beta 4 公告给出的整体解释是：可靠性要放在前面，同时还要尽量维持可预期的发布节奏。一些功能需要更多开发和审查时间，因此先从 19 移出，留给以后继续处理。

公告没有把 SQL/PGQ 撤回的完整原因归结成一句“性能太差”或“标准不好”。所以，不能把这些猜测写成确定结论。对准备升级的人来说，最有用的判断是：现在不要围绕这项新增功能安排生产交付。

四、已经按图查询做了方案，怎么办？

先别急着更换数据库，先把实际需求说清楚。如果只是查两三层固定关系，普通 JOIN 可能就能解决；如果是组织上下级、目录路径等层级查询，可以评估递归 CTE。

但这两种方法不等于完整替代 SQL/PGQ。关系层数很多、路径组合复杂，或者需要专门的图算法时，还要考虑数据规模和查询速度。此时可以单独测试图扩展或图数据库，把数据同步和日常维护的成本也算进去。

如果已经在早期 Beta 上写了原型，先找出相关查询和建库脚本，把它们与正式上线内容分开。不要为了保留一个原型功能，长期把生产库放在旧测试版上。

五、怎样避免再按过期清单做升级？

想采用一项新能力，先确认目标程序里是否仍有、要不要额外扩展，再用自己的业务例子运行一次。

还应继续看后续Beta和RC的变化。最初预告只能说明方向，实际安装版本的能力才决定交付范围。撤回某项功能不一定使整次升级失去意义，但升级理由必须重新核实。

若主要为了图查询升级，就需要改变原来的计划。若看中的是仍保留的表维护或查询优化能力，可以围绕这些真实收益继续测试，不必把所有功能的价值混在一起。