PostGIS 3.7.0alpha1 发布：升级前先看依赖边界

2026-07-05 32 预计阅读时间: 1 分钟
来源: postgr.es AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：7 分钟

PostGIS 3.7.0alpha1 已经发布。这是 3.7 这个大版本线的 alpha 版本，包含自 PostGIS 3.6.4 以来的 bug 修复和新功能。对生产团队来说，它最重要的信号不是“马上升级”，而是：PostgreSQL、GEOS、PROJ、SFCGAL 的版本边界已经明确，可以开始做兼容性盘点和测试环境验证了。

这次发布给出的版本坐标

PostGIS 3.7.0alpha1 支持 PostgreSQL 14 到 PostgreSQL 19 Beta1。也就是说，如果你的空间数据库还停在 PostgreSQL 13 或更早版本，这条 3.7 线已经不再是简单扩展升级，而会牵涉数据库主版本升级。

几个关键依赖也需要一起看：

  • GEOS 需要 3.10 或更高版本。
  • PROJ 需要 6.1 或更高版本。
  • 如果要使用完整特性，建议 GEOS 3.15 或更高版本。
  • 如果要使用完整 SFCGAL 能力，需要 SFCGAL 2.3.0 或更高版本。

这里的重点是“最低可运行”和“完整能力”不是一回事。你可以在 GEOS 3.10+ 上满足基础要求，但如果团队正好依赖几何运算的新行为或新能力，就应该把 GEOS 3.15+ 纳入测试矩阵。

Alpha 版本适合做什么，不适合做什么

alpha 版本通常适合三类工作：编译验证、扩展升级演练、业务 SQL 回归测试。它不适合作为生产环境的默认目标版本，尤其是空间查询密集、拓扑或栅格能力重的系统。

PostGIS 的升级风险常常不在“扩展能不能创建”，而在这些细节里：

  • 某些几何函数在边界输入上的结果是否变化。
  • 查询计划是否因为 PostgreSQL 主版本变化而改变。
  • GiST/SP-GiST 索引、统计信息和空间过滤条件是否仍然稳定。
  • 应用层是否隐含依赖某个函数的异常行为或精度表现。

所以看到 3.7.0alpha1，比较稳的动作是建一套隔离环境，把真实 schema、典型数据和核心查询跑一遍。

可以这样实践：先做依赖与扩展体检

下面这个脚本可以在现有 PostgreSQL/PostGIS 数据库里快速打印版本信息。把 DATABASE_URL 改成你的连接串即可运行。

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

: "${DATABASE_URL:?Set DATABASE_URL first, for example: export DATABASE_URL=postgres://user:pass@localhost:5432/db}"

psql "$DATABASE_URL" -v ON_ERROR_STOP=1 <<'SQL'
SELECT version() AS postgres_version;

SELECT
  postgis_full_version() AS postgis_full_version;

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

如果你的环境已经安装了候选版本的 PostGIS，可以再跑一组最小空间函数冒烟测试。这个测试不证明业务完全安全，但能尽早发现扩展未启用、SRID、GEOS 支持等基础问题。

CREATE EXTENSION IF NOT EXISTS postgis;

WITH sample AS (
  SELECT
    ST_GeomFromText('POINT(121.4737 31.2304)', 4326) AS shanghai,
    ST_GeomFromText('POINT(116.4074 39.9042)', 4326) AS beijing
)
SELECT
  ST_AsText(shanghai) AS geom_text,
  round((ST_DistanceSphere(shanghai, beijing) / 1000)::numeric, 2) AS distance_km,
  ST_SRID(shanghai) AS srid
FROM sample;

用于 CI 时，可以把它包装成一个简单的检查任务：

export DATABASE_URL="postgres://postgres:postgres@localhost:5432/postgres"
psql "$DATABASE_URL" -v ON_ERROR_STOP=1 -f smoke-postgis.sql

其中 smoke-postgis.sql 放上面的 SQL。等你把 3.7.0alpha1 编译进测试镜像或测试主机后，这个检查就能作为第一道门禁。

升级演练要盯住的几个点

如果你从 PostGIS 3.6.x 评估 3.7.0alpha1，可以按下面的顺序推进：

  1. 记录当前 postgis_full_version() 输出，尤其是 PostgreSQL、GEOS、PROJ、SFCGAL 信息。
  2. 在隔离环境恢复生产备份或抽样数据，不要直接在生产库试 alpha。
  3. 执行 ALTER EXTENSION postgis UPDATE; 前后各跑一次核心查询集。
  4. 对空间索引相关查询执行 EXPLAIN (ANALYZE, BUFFERS)，比较扫描方式和耗时。
  5. 对拓扑、栅格、SFCGAL 相关功能单独建测试用例，因为这些能力受底层库版本影响更明显。

示例升级命令如下，实际运行前请确认测试环境里已经安装目标 PostGIS 版本：

BEGIN;

ALTER EXTENSION postgis UPDATE;
ALTER EXTENSION postgis_raster UPDATE;
ALTER EXTENSION postgis_topology UPDATE;
-- 如果你使用 SFCGAL，再启用这一行：
-- ALTER EXTENSION postgis_sfcgal UPDATE;

SELECT postgis_full_version();

ROLLBACK;

这里故意用了 ROLLBACK，适合做一次非破坏性演练。真正升级时再改成 COMMIT，并配合备份、停写窗口和回滚方案。

采用建议：把它当成测试信号，而不是生产号令

PostGIS 3.7.0alpha1 的价值在于提前暴露依赖要求和兼容性问题。它适合进入开发机、CI 镜像、性能基准环境；不适合作为生产环境的匆忙升级目标。

一个务实的检查清单是：PostgreSQL 是否已经在 14 以上；GEOS 是否至少 3.10；PROJ 是否至少 6.1；是否需要 GEOS 3.15+ 或 SFCGAL 2.3.0+ 的完整能力；核心空间 SQL 是否有可重复的回归测试。把这些问题答清楚，再等后续 beta、rc 或正式版，升级会从“赌一次”变成“按证据推进”。

# PostgreSQL # 数据库

相关推荐