空间数据库升级不只是替换一个扩展包。PostGIS 的函数行为、几何解析、依赖库和 PostgreSQL 主版本会一起影响 GIS 服务、ETL 与分析脚本。PostGIS 3.7.0rc1 是候选版，适合团队把兼容性和回归制度跑一遍，而不是直接把生产库当测试场。
可核查事实
- PostGIS 团队于 2026 年 8 月 24 日发布 PostGIS 3.7.0rc1。
- 该候选版要求 PostgreSQL 14 至 19rc1、GEOS 3.10 或更高版本，以及 PROJ 6.1 或更高版本。
- 官方说明称，要使用全部功能需要 GEOS 3.15 以上；要使用全部 SFCGAL 功能需要 SFCGAL 2.3.0 以上。
- 该版本包含自 3.7.0beta2 以来的修复，也是一个含有自 3.6.4 以来修复和新功能的主版本候选版。
- 对 PostGIS 3 系列，官方升级说明要求在安装二进制包或执行 pg_upgrade 后运行
SELECT postgis_extensions_upgrade();。 - 修复项包括对非有限控制点的递归 NURBSCURVE 包围盒处理，以阻止可由 WKT 输入触发的后端 CPU 拒绝服务。
- 修复项还包括在输入结束前拒绝格式错误的 SRID 前缀，以及拒绝格式错误的 GSERIALIZED 多边形环。
核心机制
PostGIS 处在 PostgreSQL、GEOS、PROJ、可选 SFCGAL 与上层 GIS 服务之间。一个 SQL 函数结果或几何错误，常常不是单一扩展版本造成的，而是依赖组合、扩展目录和数据升级状态共同决定。候选版的意义是提前暴露这些组合问题。几何解析和曲线包围盒的修复尤其值得把不可信 WKT、导入数据和公共接口作为回归样本，因为输入边界往往比常规地图浏览更容易出问题。
GIS 场景与实施路径
先复制一份经过脱敏的生产数据或建立代表性样本库，记录 PostgreSQL、PostGIS、GEOS、PROJ、SFCGAL 版本和扩展清单。在隔离环境安装候选版后，按官方顺序执行扩展升级；随后重跑空间索引构建、矢量导入、常用 ST_ 查询、瓦片服务、批量拓扑校验和备份恢复。对公开 API 或上传链路，再加入过长、截断和错误 SRID 的几何样本，确认失败是可控的而非耗尽资源。
可执行建议
- 把 PostGIS、PostgreSQL、GEOS、PROJ 和 SFCGAL 写入同一份部署清单，避免只记录 PostGIS 版本。
- 候选版只在隔离环境验证；生产升级应等待团队接受的正式版本和变更窗口。
- 在升级前备份数据库、扩展定义与关键查询基线，并演练一次恢复。
- 将
postgis_extensions_upgrade()、扩展版本读取和关键 SQL 结果纳入自动化发布检查。 - 用来自真实导入链路的异常几何做负向测试，重点观察错误处理、CPU 和内存。
资料来源与数据口径
发布日期、依赖门槛、升级 SQL 与修复描述均来自 PostGIS 官方 3.7.0rc1 发布说明。候选版说明不等同于特定云托管服务已经提供该版本，也不保证所有第三方插件与其兼容。
风险边界
候选版可能继续变化，不应因“可安装”就作为生产基线。通过一组 SQL 样本也不能证明全部空间分析正确；坐标参考、数据质量、索引策略和业务规则仍需分别验证。面对不可信几何输入时，修复可降低已知风险，但应用层的大小限制、鉴权和限流仍然必要。
结论
PostGIS 升级的可靠性来自版本组合和可复跑验证，而不是单个版本号。把依赖、扩展升级、几何负例与恢复步骤一起纳入 GIS 工作流，团队才能在正式发布到来前获得足够证据。