PostgreSQL 14 中的新语法，尤其是使用 BEGIN ATOMIC … END 创建 SQL 函数，在某些情况下会破坏其官方的.NET 和 Java 数据库驱动。但只要不通过 Npgsql 或 PgJDBC 修改数据库模式，就不会出现问题。

对于 Java 的 JDBC 和.NET 的 ADO.NET 数据库驱动框架，它们存在一个共同点，那就是都支持使用 分号 实现 SQL 语句 批处理。 批处理 对提高性能是十分必要的。如果客户端一次只发送一个命令，那么每个命令就必须要付出通信延迟代价。但如果使用批处理一次执行一批语句，那么只需付出一次通信代价。

事实上， SQL Server 数据库 将批处理语句作为一个庞大的 SQL 字符串整体发送。但 PostgreSQL 的 wire 通信协议工作机制有别如此。虽然批处理语句依然整体发送，但客户端需将语句拆分为各条独立的命令。

原始实现可简单地假设每个分号标识一条语句的终止处。当然，分号也可能是一条语句字符串中的内容，而非一条语句的结尾。Npgsql 和 PgJDBC 解析器对此做了考虑。

这曾经工作得很好。但现在新建 SQL 函数体中可以定义多条语句，那么应如何处理？当然这也不是问题，因为函数体使用“

”标记做转义。在“

”标记对内的分号，与其它 字符串 文字的处理方式无异。

进而 PostgreSQL 14 添加了称为“SQL 标准语法”的“ BEGIN ATOMIC … END ”语句。对此发行说明中给出如下解释。

使用 SQL 标准语法编写的函数或过程能快速解析，并存储为解析树形式。这可更好地追踪函数的依赖关系，并具有更好的安全性。

由于分号可能并非出现在 引号 引起的字符串中，而是会出现在 BEGIN ATOMIC … END 语句块内的任何位置，如果解析器使用当前的方法，就无法确定批处理中语句的拆分位置。完全支持语句拆分或是要去更改 API，或是要去新建一个更复杂的解析器。

Npgsql 已关注当前解析器的开销问题，决定更改 API。在 Npgsql 的库中增加了一种称为“ 原始SQL（raw SQL mode） ”的模式。此模式没有使用命名参数，需要使用位置（positional）参数。

而 PgJDBC 团队尚未决定采用何种方法。其进展可关注软件缺陷报告“ 新的PG14 SQL标准函数破坏了PgJDBC解析器（New PG14 SQL-standard function bodies break our SQL parser） ”。

作者简介：

Jonathan Allen 在上世纪 90 年代后期为一家健康诊所实施 MIS 项目，实现从 Access 和 Excel 逐步升级为企业解决方案。在金融部门编写五年自动交易系统后，他成为多个项目的顾问，其中包括机器人仓库 UI、癌症研究软件中间层，以及解决一家大型房地产保险公司的大数据需求。在空闲时间，他喜欢研习 16 世纪的武术。