pg_acm 的维护者发布了一批新代码。她此前已记录了约二十个待修复的问题,也收到了新增功能的请求,并计划调整一些概念设计。代码已经开放供大家试用和反馈,但文档更新尚未完成。对准备跟进的团队来说,现在适合在测试环境验证,不宜只凭旧文档推断新版本的行为。
这次更新值得关注什么
这不是一次仅改几个缺陷的例行维护。维护者同时提到了已知问题、用户提出的新功能,以及概念层面的调整。不过,现有信息没有逐项列出已修复的问题或新函数的签名,不能据此认定所有待修复问题都已解决。
尤其要留意概念调整:即使现有调用仍能执行,边界条件或推荐用法也可能需要重新确认。准确的变更范围应以代码、版本记录和实际测试结果为准。
在测试库里核对安装状态
如果你通过 PostgreSQL 扩展机制使用 pg_acm,可以先运行下面的只读检查。将 DATABASE_URL 改为测试库的连接串;命令需要本机已安装 psql。它不会安装或升级扩展。
export DATABASE_URL='postgresql://user:password@localhost:5432/testdb'
: "${DATABASE_URL:?Set DATABASE_URL to a test database}"
psql "$DATABASE_URL" -v ON_ERROR_STOP=1 <<'SQL'
SELECT name, default_version, installed_version
FROM pg_available_extensions
WHERE name = 'pg_acm';
SELECT p.oid::regprocedure AS function_signature
FROM pg_extension AS e
JOIN pg_depend AS d
ON d.refclassid = 'pg_extension'::regclass
AND d.refobjid = e.oid
AND d.classid = 'pg_proc'::regclass
AND d.deptype = 'e'
JOIN pg_proc AS p ON p.oid = d.objid
WHERE e.extname = 'pg_acm'
ORDER BY 1;
SQL
第一条查询显示服务器是否提供该扩展,以及当前数据库是否已安装;第二条列出当前数据库中归属于该扩展的函数签名。没有结果不等于更新失败:可能尚未安装,也可能你使用的代码并非以 PostgreSQL 扩展形式部署。安装和升级步骤应按项目当前说明执行,不要从这段检查命令反推升级方法。
文档未齐时,怎样给出有用反馈
在隔离测试库中复现你依赖的调用,再记录旧版本与新代码的输入、输出和错误信息。报告问题时附上 PostgreSQL 版本、pg_acm 的具体代码版本、最小复现步骤及预期结果;涉及新函数时,先确认实际签名,避免把猜测写成 API 约定。
这批代码已经发布,维护者也明确希望收到缺陷报告和问题。文档补齐之前,把升级视为一次需要验证的变更:先盘点现有调用,再做针对性回归测试,最后决定是否进入生产环境。