PostGIS 3.7.0rc1 发布：面向 PostgreSQL 19 的空间数据库候选版本

预计阅读时间：7 分钟

PostGIS 团队发布了 PostGIS 3.7.0rc1。这是 3.7 系列的首个候选版本，包含自 3.7.0beta2 以来的修复，也延续了相对于 PostGIS 3.6.4 的新功能。对于准备测试 PostgreSQL 19，或希望提前验证下一代空间数据库环境的团队，这个版本已经值得进入预发布验证流程。

版本组合与兼容范围

PostGIS 3.7.0rc1 面向 PostgreSQL 14 至 PostgreSQL 19rc1，要求以下基础组件：

PostgreSQL：14 至 19rc1
GEOS：3.10 或更高版本
PROJ：6.1 或更高版本
SFCGAL：如果使用相关功能，需要 2.3.0 或更高版本

版本要求和功能上限并不完全相同。GEOS 3.10 可以满足基础要求，但要使用 PostGIS 3.7.0rc1 的全部功能，需要 GEOS 3.15 或更高版本；同样，只有安装 SFCGAL 2.3.0 或更高版本，才能完整使用对应的 SFCGAL 功能。

官方推荐的测试组合包括 PostgreSQL 19 Beta 3、GEOS 3.15.0rc1、postgis_tiger_geocoder 2025.2 和 address_standardizer。这些组件适合构建完整的预发布验证环境，但不应直接等同于生产环境的稳定性承诺。

为什么候选版本值得单独测试

RC 版本的重点不是引入一套可以忽略兼容性的实验接口，而是让使用者在正式版发布前验证升级影响。空间数据库升级通常不只是替换一个扩展文件，还涉及 PostgreSQL 主版本、GEOS/PROJ 动态库、栅格和拓扑扩展，以及已有空间查询的结果一致性。

建议重点检查以下内容：

现有数据库能否顺利执行 ALTER EXTENSION postgis UPDATE。
依赖 GEOS 的缓冲区、相交、有效性修复等查询是否产生预期结果。
使用 PROJ 坐标转换的查询是否仍能正常执行。
栅格、拓扑、SFCGAL 和 Tiger Geocoder 是否按需安装并完成升级。
业务中的空间索引、数据导入和批量计算是否出现性能或结果变化。

PostGIS 3.7.0rc1 明确包含针对 3.6.4 之后问题的修复，以及新的主要版本特性，因此验证时不能只做“扩展能否加载”的冒烟测试。应当把真实的空间查询、迁移脚本和典型数据集纳入测试。

可以这样验证安装与升级

下面的命令假设目标数据库名为 gis_test，当前用户具备安装扩展和执行升级的权限。请先在临时环境中恢复一份生产数据副本，并根据发行版调整包名或动态库路径。

# 查看 PostgreSQL、PostGIS 和底层库版本
psql -d gis_test -c "SELECT version();"
psql -d gis_test -c "SELECT PostGIS_Full_Version();"

# 查看数据库中已安装的扩展版本
psql -d gis_test -c "SELECT extname, extversion FROM pg_extension WHERE extname LIKE 'postgis%';"

# 在备份完成后升级主 PostGIS 扩展
pg_dump -Fc -d gis_test -f gis_test-before-postgis-37.dump
psql -d gis_test -c "ALTER EXTENSION postgis UPDATE;"

# 按实际安装情况升级相关扩展
psql -d gis_test -c "ALTER EXTENSION postgis_raster UPDATE;"
psql -d gis_test -c "ALTER EXTENSION postgis_topology UPDATE;"
psql -d gis_test -c "ALTER EXTENSION postgis_sfcgal UPDATE;"

并非每个数据库都会安装这些扩展，因此相关 ALTER EXTENSION 命令可能提示扩展不存在。可以先用下面的查询确认当前数据库中的扩展：

SELECT extname, extversion
FROM pg_extension
WHERE extname IN (
  'postgis',
  'postgis_raster',
  'postgis_topology',
  'postgis_sfcgal',
  'postgis_tiger_geocoder',
  'address_standardizer'
)
ORDER BY extname;

在容器或 CI 环境中，可以把版本检查加入发布前验证：

#!/usr/bin/env bash
set -euo pipefail

DB_URL="${DATABASE_URL:?DATABASE_URL is required}"

psql "$DB_URL" -v ON_ERROR_STOP=1 <<'SQL'
SELECT PostGIS_Full_Version();
SELECT postgis_full_version();
SELECT ST_IsValid(ST_GeomFromText('POLYGON((0 0, 0 1, 1 1, 1 0, 0 0))', 4326));
SELECT ST_AsText(ST_Transform(
  ST_SetSRID(ST_Point(116.397, 39.908), 4326),
  3857
));
SQL

示例中的空间对象和坐标系只是最小验证样例。实际项目还应使用自身的 SRID、几何类型和代表性数据，尤其要覆盖无效几何、空几何、3D 几何以及大批量空间连接等边界情况。

升级时的边界与取舍

PostGIS 3.7.0rc1 仍然是候选版本。它适合开发环境、兼容性测试、扩展生态验证和升级演练；生产系统是否采用，应由团队根据正式支持策略、依赖包可用性和测试结果决定。

一个稳妥的落地顺序是：

固定 PostgreSQL、GEOS、PROJ 和可选 SFCGAL 的确切版本。
使用生产数据副本执行备份、扩展升级和回归测试。
对空间查询结果做基线对比，而不只比较 SQL 是否成功执行。
单独验证栅格、拓扑、Tiger Geocoder 和地址标准化功能。
记录升级耗时、索引状态、查询计划与异常日志，再决定是否进入灰度环境。

如果项目只依赖稳定的长期生产版本，继续等待正式版并保持当前版本也可能是更合适的选择。若团队需要提前适配 PostgreSQL 19，或需要确认 3.7 系列的新特性与现有空间数据管线是否兼容，那么现在正是建立可重复测试环境的时间点。

PostGIS 3.7.0rc1 发布：面向 PostgreSQL 19 的空间数据库候选版本

版本组合与兼容范围

为什么候选版本值得单独测试

可以这样验证安装与升级

升级时的边界与取舍

相关推荐

建议反馈