返回
多御红包活动

PostgreSQL 14 会破坏其官方的.NET 和 Java 驱动

发布时间:2022-09-27 13:36:53 89
# 数据库# sql# 研究# 软件# 缺陷

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

特别声明:以上内容(图片及文字)均为互联网收集或者用户上传发布,本站仅提供信息存储服务!如有侵权或有涉及法律问题请联系我们。
举报
评论区(0)
按点赞数排序
用户头像
精选文章
thumb 中国研究员首次曝光美国国安局顶级后门—“方程式组织”
thumb 俄乌线上战争,网络攻击弥漫着数字硝烟
thumb 从网络安全角度了解俄罗斯入侵乌克兰的相关事件时间线