空间数据库升级的风险不只在新函数，而在旧默认语义的改变。PostGIS 3.7.0alpha1 同时调整拓扑 tolerance 解释、移除旧依赖支持，并修改装载器和空间处理能力。对承载地籍、管网和遥感数据的 GIS 团队，alpha 版本应是验证升级契约的环境，而非直接替换生产主库的理由。

官方发布中的关键事实

PostGIS 团队于 2026 年 7 月 5 日发布 PostGIS 3.7.0alpha1。该版本支持 PostgreSQL 14 至 19beta1，要求 GEOS 3.10+ 与 PROJ 6.1+；全部特性需要 GEOS 3.15+，全部 SFCGAL 特性需要 SFCGAL 2.3.0+。官方明确这是一项主版本 alpha，含 3.6.4 之后的修复和新功能，也提示存在影响升级或使用的破坏性变化。

拓扑构建函数将 tolerance 0 解释为真正的 0，-1 成为使用拓扑精度的新默认值。PostgreSQL 12、13 不再支持，address_standardizer 与 tiger_geocoder 也从核心包移至独立仓库。新版本中，shp2pgsql 可创建 UNLOGGED 表、选择要素 ID 列，且 -if-not-exists 可使创建动作幂等；ST_CoverageEdges、ST_MinimumSpanningTree 和 GDT_Float16 也被列为新增能力。

核心机制

升级验收应比较同一输入在旧版与候选版的行为，而非只确认数据库能启动。tolerance 默认值会改变拓扑贴合和清理结果；依赖变化会影响部署；装载器选项会改变表持久性、主键和重复执行方式。将这些变化拆成小型 SQL 用例，并保存结果、错误和执行计划，才能把升级风险变成可回放的证据。

GIS 应用场景与技术路径

地籍拓扑、管网网络、矢量瓦片、Shapefile 批量装载和栅格处理都应先在隔离实例验证。固定 PostgreSQL、GEOS、PROJ 和 SFCGAL 版本，备份扩展与关键模式；用脱敏真实样本分别跑旧版与候选版的建库、导入、查询、索引和导出；再比对行数、几何有效性、坐标参考、结果集合与执行时间。

对拓扑项目，分别验证 tolerance 0、-1 和既有阈值。对装载管道，检查 UNLOGGED 表是否符合恢复策略、要素 ID 是否兼容下游服务，以及重复运行 -if-not-exists 是否保持幂等。空间分析必须由具体用例的结果决定是否试点。

风险与局限

alpha 版本的接口和实现仍可能变化。发布说明中的功能清单不等同于所有业务数据安全迁移，尤其是旧 PostgreSQL、迁出的扩展、拓扑精度和栅格管线。性能也应基于本地实际负载，不应从单条发布说明外推整体收益。

检查清单

  1. 是否锁定候选依赖版本并记录扩展清单？
  2. 是否对 tolerance 0、-1 与既有阈值做了旧新版对照？
  3. 是否确认没有实例依赖 PostgreSQL 12/13 或已迁出的扩展？
  4. 是否测试 shp2pgsql 的 UNLOGGED、要素 ID 与幂等选项？
  5. 是否用真实样本验证覆盖边、最小生成树与 Float16 栅格兼容性？
  6. 是否保留可回退备份，并限制 alpha 在隔离试点运行？

数据口径与可核验事实

  1. PostGIS 团队于 2026 年 7 月 5 日发布 PostGIS 3.7.0alpha1。
  2. 该版本支持 PostgreSQL 14 至 19beta1，要求 GEOS 3.10+ 与 PROJ 6.1+。
  3. 使用全部特性需要 GEOS 3.15+，使用全部 SFCGAL 特性需要 SFCGAL 2.3.0+。
  4. 拓扑构建函数将 tolerance 0 解释为真正的 0，-1 成为使用拓扑精度的新默认值。
  5. 该版本移除对 PostgreSQL 12 和 13 的支持。
  6. address_standardizer 和 tiger_geocoder 扩展从核心包移出并迁至独立仓库。
  7. shp2pgsql 可创建 UNLOGGED 表、选择要素 ID 列，且 -if-not-exists 可使创建动作幂等。
  8. 新功能包括 ST_CoverageEdges、ST_MinimumSpanningTree 和 GDT_Float16 栅格像元类型支持。

结论

PostGIS 3.7.0alpha1 的价值是提前发现拓扑、依赖和导入流程的升级风险。把默认精度、装载语义、函数结果和回滚方案纳入同一条 GIS 验收链，才能把正式升级变成可验证的迁移。

参考来源