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 世纪的武术。