IvorySQL 5.4 发布之后，还在快速进化什么？

2026 年 6 月 17 日，IvorySQL 5.4 正式发布。

如果只看版本说明，这像是一次常规的小版本升级：底层从 PostgreSQL 18.3 更新到 PostgreSQL 18.4，修复一批安全和稳定性问题，再补充一些部署与生态能力。

但把 IvorySQL 5.4 的发布记录、标签提交、后续 PR 和 Issue 串起来看，结论并不一样。

IvorySQL 5.4 并不是一个阶段性收尾，而是下一轮演进的起点。

截至 2026 年 8 月 10 日，v5.4 发布后的 54 天里，IvorySQL 仓库新增了 112 个 PR、72 个 Issue，合并 42 个 PR，关闭 50 个 Issue。主线一边继续追踪 PostgreSQL 19 开发进度，一边补齐 Oracle 兼容能力，同时集中治理构建、测试和文档问题。

这篇文章分两条线介绍：

IvorySQL 5.4 本身更新了什么
从 5.4 发布到现在，项目又发生了哪些变化

01. IvorySQL 5.4 的版本基线

IvorySQL 5.4 的正式发布日期是 2026 年 6 月 17 日，这一版本基于 PostgreSQL 18.4 构建。

代码提交显示的总变更规模达到 2 万多行。

更重要的是，这批代码完成了四组核心回归测试：

check-world
oracle-check-world
oracle-pg-check
oracle-check

这四组测试的意义在于，IvorySQL 不能只验证 PostgreSQL 原生行为，也不能只验证 Oracle 兼容行为。两套解析和兼容路径必须同时成立。

这也是 IvorySQL 相比普通 PostgreSQL 分支更难维护的地方。

02. PostgreSQL 18.4 带来了哪些底层修复？

IvorySQL 5.4 的基础价值，首先来自 PostgreSQL 18.4。

这一轮上游更新不是功能堆叠，重点是安全性、边界检查和故障处理。对于生产数据库来说，这类升级往往比新增几个 SQL 函数更重要。

2.1. 阻止启动包处理中的无限递归

PostgreSQL 18.4 修复了启动连接阶段的递归问题。恶意客户端可以交替发送被拒绝的 SSL 和 GSS 加密请求，让后端不断递归处理，最终导致连接进程崩溃。

修复后，启动包处理不会再无限递归。数据库暴露在复杂网络环境中时，连接握手路径必须经得住异常输入。

2.2. 集中治理整数溢出

18.4 对多处内存分配和长度计算进行了加固，上游还增强了 palloc_array() 及相关接口，使数组分配能够在乘法溢出发生前拒绝请求。

这些修复看起来分散，实际上指向同一件事：数据库必须默认不信任长度、数量和尺寸计算。

2.3. 修复多个 SQL 注入风险点

本轮同步还修复了若干内部工具和扩展中的 SQL 注入问题，数据库系统内部工具同样可能受到 SQL 注入影响。用户输入不只来自业务 SQL，也可能来自订阅名称、对象名称、命令参数和扩展调用。

2.4. 防止路径穿越

pg_basebackup 和 pg_rewind 加入了路径穿越防护。备份与恢复工具经常拥有较高文件系统权限，一旦路径校验出现问题，风险不局限于数据库目录，还可能影响主机上的其他文件。

2.5. 修复 libpq 与大对象接口越界

18.4 将 PQfn() 明确标记为不安全接口，并修复前端大对象接口中的越界问题。官方文档也强化了警告：PQfn() 已经过时，调用方应优先使用预备语句和二进制参数传输替代。

2.6. 改进认证路径的时间安全比较

认证相关路径开始使用 timingsafe_bcmp()。普通字符串或内存比较可能因为提前退出产生时间差，理论上可被用于推测敏感数据。对数据库认证路径来说，这是必要的防御性改进。

03. IvorySQL 5.4 不只是一次内核升级

如果只把 IvorySQL 5.4 理解成“PostgreSQL 18.4 加 Oracle 兼容层”，会漏掉它在交付形态上的变化。

3.1. 增强 EXTRACT 语法兼容

PR #1222 扩展了 EXTRACT 函数对更多 SQL 语法变体的支持。

这类功能单看不大，但在 Oracle 应用迁移中很实用。迁移成本通常不是由一个大功能决定，而是由成百上千个细小语法差异累积出来的。一个日期函数不兼容，可能意味着几十个存储过程都需要人工修改。

3.2. 引入 IvorySQL Skills

5.4 发布说明明确加入了 IvorySQL Skills，目标是让 AI 助手具备 IvorySQL 专业知识。

数据库产品过去主要提供文档、命令行和图形化管理工具三类入口。AI 助手正在成为第四类入口。用户可能不再从目录里查找命令，而是直接询问 Oracle SQL 如何迁移、执行计划为何没有走索引、如何部署高可用集群。

这不等于 AI 可以替代 DBA。更准确的说法是：

AI 开始接管数据库知识检索和初步操作建议，最终判断仍然需要人。

3.3. 发布 IvorySQL Cloud 5.4

IvorySQL Cloud 5.4 被定义为可视化数据库生命周期管理平台，覆盖数据库订阅、部署编排、生命周期操作和周边生态服务。

IvorySQL 正在形成三层结构：

数据库内核
容器与高可用交付体系
可视化生命周期管理平台

如果只有第一层，它是一个数据库分支。三层逐步建立后，它才更接近完整的数据库产品。

3.4. 扩展 PostgreSQL 生态支持

5.4 发布说明列出了 24 个扩展和工具：

类别	代表组件
空间与图数据	PostGIS、pgRouting、AGE
向量与全文检索	pgvector、PGroonga、pg_bigm、pg_jieba、Zhparser、pg_textsearch
运维调度	pg_cron、pgagent、pg_partman
监控与执行计划	pg_stat_monitor、pg_show_plans、pg_hint_plan、system_stats
数据交换与集成	wal2json、redis_fdw、pgsql-http、pg_curl
连接与开发工具	PgBouncer、plpgsql_check、ddlx
AI 能力	pg_ai_query

IvorySQL 的路线并不是复制一套封闭生态，而是在保留 PostgreSQL 扩展能力的基础上增加 Oracle 兼容。这条路线很难，但上限也更高。

04. 主线开始持续跟进 PostgreSQL 19

IvorySQL 5.4 稳定版基于 PostgreSQL 18.4，但 master 分支没有停在 18.4。

发布之后，项目连续进行了多轮 PostgreSQL master 同步：

PR	同步范围	纳入提交
#1356	2026-01-15 至 2026-02-07	169
#1368	2026-02-07 至 2026-02-26	144
#1416	2026-02-26 至 2026-03-20	分段同步
#1511	2026-03-20 至 2026-04-16	457

其中 PR #1511 包含 445 个 PostgreSQL 上游直接提交和 12 个 IvorySQL 适配提交，总计 457 个提交。这批代码在 2026 年 8 月 6 日合并，并继续通过四组核心回归测试。

这说明 IvorySQL 在做两条并行维护：

稳定分支保持 PostgreSQL 18.4 基线
master 跟进 PostgreSQL 19 开发主线

这种策略的好处是，新一代 PostgreSQL 发布时，IvorySQL 不需要从头进行一次巨型合并。代价也很明显：Oracle 解析器、PL/iSQL、兼容 GUC、MERGE 行为和扩展脚本都要持续适配上游变化。

只要这种分段同步能持续，长期维护风险会显著低于集中式大版本合并。

05. Oracle 兼容继续从“语法”走向“会话语义”

发版后的重要变化，大多不是再增加一个关键字，而是在补会话状态、包状态和运行时行为。

5.1. 增加 STRAGG 聚合函数

PR #1352 解决 Issue #1096，新增 sys.stragg 聚合函数，支持文本拼接、NULL 处理和分组聚合，并覆盖相应回归测试。

STRAGG 是 Oracle 早期常见的字符串聚合实现，后来逐渐被 LISTAGG 替代。新系统未必主动使用 STRAGG，但历史应用里可能仍然存在。迁移工具真正需要处理的，恰恰是这类“已经不新，但删不掉”的功能。

5.2. 增加 DBMS_SESSION 子集

PR #1369 实现了 Oracle DBMS_SESSION 的部分能力：

SET_CONTEXT
CLEAR_CONTEXT
CLEAR_ALL_CONTEXT
LIST_CONTEXT

同时改进 SYS_CONTEXT 的取值逻辑，并确保 DISCARD ALL 或 DISCARD PACKAGES 后清理会话上下文，避免连接复用时出现状态泄漏。

数据库会话可能经过连接池重复利用。如果上一个业务请求留下的应用上下文没有清掉，下一个请求就可能读到错误状态。它既是兼容问题，也是隔离问题。

5.3. 实现 RESET_PACKAGE 语义

Issue #1376 提出，Oracle 的 DBMS_SESSION.RESET_PACKAGE 应当清理 PL/SQL 包状态和缓存游标，但不能误伤应用上下文。PR #1375 完成相关实现：

按 OID 重置单个 PL/iSQL 包
重置全部包并关闭包内缓存 refcursor
释放变量内存和可变全局变量
将包标记为未初始化
下一次访问时延迟执行初始化
重新计算动态默认值并执行包初始化块
不影响非包级会话上下文

这里最关键的是“延迟重新初始化”。假设包变量默认值依赖 SYSDATE、序列 NEXTVAL 或其他包函数，重置时不能简单恢复旧快照。正确行为是下次访问时重新计算。

5.4. 新增 PostgreSQL 方言白名单

PR #1364 解决 Issue #1310，为扩展控制文件增加 pg_dialect 配置。

很多 PostgreSQL 扩展的安装脚本依赖原生 PostgreSQL 语法，Oracle 模式的解析器不一定能直接解析。新机制允许扩展声明安装期间使用 PostgreSQL 解析器，并让扩展创建的函数绑定相应兼容模式。

IvorySQL 如果只兼容 Oracle SQL，却让 PostgreSQL 扩展在 Oracle 模式下安装失败，双生态优势就无法成立。pg_dialect 相当于在两套语法体系之间增加了一条明确边界。

5.5. psql 提示符显示 Oracle 模式

Issue #1354 提出，交互式 psql 中很难快速判断当前会话使用哪种兼容模式。PR #1383 增加 %o 提示符转义，Oracle 模式显示 [ORA]，PostgreSQL 模式显示空字符串，执行 SET ivorysql.compatible_mode 后还能实时更新。

[ORA]ivorysql=#

同一条 SQL 在两种模式下可能产生不同解析结果。把当前模式放进提示符，可以降低误操作和误判概率。

06. 从新增能力到迁移生态，功能面仍在扩展

6.1. 支持 COPY ON CONFLICT DO NOTHING

Issue #1508 与 PR #1509 增加了 COPY ON CONFLICT DO NOTHING 支持，用于兼容 AnalyticDB 风格的数据导入行为。

它把冲突忽略能力放到批量导入路径，适合数据回灌、重复数据容忍和迁移场景。功能本身并非 Oracle 专属，也说明 IvorySQL 的兼容边界正在向真实迁移来源扩展，而不是只围绕单一数据库。

6.2. 增加索引 UNUSABLE 语义

Issue #1457 与 PR #1456 推进 ALTER INDEX ... UNUSABLE 兼容能力。

Oracle 运维脚本和数据装载流程中经常会控制索引可用状态。支持相近语义，可以减少迁移后的脚本重写量。

6.3. 推进 DBMS_SCHEDULER

PR #1484 围绕 Oracle DBMS_SCHEDULER 展开工作。调度包不是单个函数，而是作业定义、时间计划、执行状态和管理接口的组合。

如果这条能力持续完善，IvorySQL 的 Oracle 兼容就会从 SQL 和存储过程进一步延伸到数据库内部作业系统。

6.4. 优化 Oracle 正则函数

Issue #1455 与 PR #1454 优化 ora_regexp_count，移除不必要的 text_to_cstring 和 strlen 路径，减少内存复制和重复扫描。

兼容函数最初解决“能不能运行”，后续优化解决“是否值得在生产负载中运行”。这是功能成熟度提升的典型过程。

07. 结语

IvorySQL 5.4 的表面变化，是从 PostgreSQL 18.3 升级到 18.4。

更深层的变化，是项目在同一时间处理四类工作：

跟进 PostgreSQL 19 主线
补齐 Oracle 会话与包语义
修复构建、测试和配置边界
扩展高可用、备份、连接池、CDC 和向量检索生态

从 Oracle 迁移到 IvorySQL 涉及大量长尾知识。仅靠传统手册，用户很难在短时间内定位差异。结构化文档加 AI Skills，可能把“查资料”变成“按场景获得操作建议”。但这条路线的前提是知识内容和版本保持一致。AI 如果引用过期参数或不存在的兼容能力，造成的误导会比普通搜索更强。

还有一到两个月，PostgreSQL 19 就要发布了，之后 IvorySQL 6 也将发布，到底最终会发布哪些新特性，还有哪些是你非常期待的，欢迎评论区聊聊。

版权申明：内容来源网络，版权归原创者所有，如有侵权请联系删除

想了解更多行业资讯

扫码关注👇

了解更多考试相关

扫码添加上智启元官方客服微信👇

17认证网