PostgreSQL 14更新是否会损害其官方.NET与Java驱动兼容性？
- 内容介绍
- 文章标签
- 相关推荐
本文共计963个文字，预计阅读时间需要4分钟。
在PostgreSQL 14中，引入了一种新的语法，即使用`BEGIN ATOMIC ... END`来创建SQL函数。这种方法在特定情况下可能会破坏其官方的.NET和Java数据库驱动。不过，只要不通过Npgsql或PgJDBC等驱动修改数据库模式，就不会出现此类问题。
PostgreSQL 14 中的新语法，尤其是使用 BEGIN ATOMIC ... END 创建 SQL 函数，在某些情况下会破坏其官方的.NET 和 Java 数据库驱动。但只要不通过 Npgsql 或 PgJDBC 修改数据库模式，就不会出现问题。
对于 Java 的 JDBC 和.NET 的 ADO.NET 数据库驱动框架，它们存在一个共同点，那就是都支持使用分号实现 SQL 语句批处理。批处理对提高性能是十分必要的。如果客户端一次只发送一个命令，那么每个命令就必须要付出通信延迟代价。但如果使用批处理一次执行一批语句，那么只需付出一次通信代价。
事实上，SQL Server 等数据库将批处理语句作为一个庞大的 SQL 字符串整体发送。但 PostgreSQL 的 wire 通信协议工作机制有别如此。虽然批处理语句依然整体发送，但客户端需将语句拆分为各条独立的命令。
原始实现可简单地假设每个分号标识一条语句的终止处。当然，分号也可能是一条语句字符串中的内容，而非一条语句的结尾。Npgsql 和 PgJDBC 解析器对此做了考虑。
这曾经工作得很好。但现在新建 SQL 函数体中可以定义多条语句，那么应如何处理？当然这也不是问题，因为函数体使用“$...$”标记做转义。在“$...$”标记对内的分号，与其它字符串文字的处理方式无异。
本文共计963个文字，预计阅读时间需要4分钟。
在PostgreSQL 14中，引入了一种新的语法，即使用`BEGIN ATOMIC ... END`来创建SQL函数。这种方法在特定情况下可能会破坏其官方的.NET和Java数据库驱动。不过，只要不通过Npgsql或PgJDBC等驱动修改数据库模式，就不会出现此类问题。
PostgreSQL 14 中的新语法，尤其是使用 BEGIN ATOMIC ... END 创建 SQL 函数，在某些情况下会破坏其官方的.NET 和 Java 数据库驱动。但只要不通过 Npgsql 或 PgJDBC 修改数据库模式，就不会出现问题。
对于 Java 的 JDBC 和.NET 的 ADO.NET 数据库驱动框架，它们存在一个共同点，那就是都支持使用分号实现 SQL 语句批处理。批处理对提高性能是十分必要的。如果客户端一次只发送一个命令，那么每个命令就必须要付出通信延迟代价。但如果使用批处理一次执行一批语句，那么只需付出一次通信代价。
事实上，SQL Server 等数据库将批处理语句作为一个庞大的 SQL 字符串整体发送。但 PostgreSQL 的 wire 通信协议工作机制有别如此。虽然批处理语句依然整体发送，但客户端需将语句拆分为各条独立的命令。
原始实现可简单地假设每个分号标识一条语句的终止处。当然，分号也可能是一条语句字符串中的内容，而非一条语句的结尾。Npgsql 和 PgJDBC 解析器对此做了考虑。
这曾经工作得很好。但现在新建 SQL 函数体中可以定义多条语句，那么应如何处理？当然这也不是问题，因为函数体使用“$...$”标记做转义。在“$...$”标记对内的分号，与其它字符串文字的处理方式无异。