libpq管道模式允许应用程序发送查询，而无需读取先前发送的查询的结果。利用管道模式，客户端将减少对服务器的等待，因为可以在单个网络事务中发送/接收多个查询/结果。
虽然管道模式提供了显著的性能提升，但使用管道模式编写客户端更加复杂，因为它涉及管理待处理查询的队列并查找哪个结果对应于队列中的哪个查询。
虽然管道API是在PostgreSQL14 中引入的，但它是一个客户端功能，不需要特殊的服务器支持，并且可以在任何支持v3扩展查询协议的服务器上工作
传统的批处理模式操作
管道模式
尽管在PostgreSQL14中引入，管道模式适用于任何当前支持的postgres版本，因为是在客户端使用的LIBPQ中，而不是PostgreSQL服务器本身！
不过利用管道模式需要使用“C”或能够直接与LIBPQ交互的等效编程语言。不幸的是，目前还没有太多的ODBC开发方式提供必要的钩子来利用这个增强的特性。因此，需要使用上述编程语言来设计和编码客户端-应用程序会话。
管道模式的工作原理
1.客户端与PostgreSQL服务端创建连接
2.客户端必须将连接切换成管道模式
3.进入管道模式后，sql请求被发送到server端
4.请求达到服务端后，语句立即被执行，结果被返回给客户端。客户端和服务端不需要进行ack确认
5.因为每个sql是顺序发送的。应用逻辑可以使用状态机或FIFO队列来处理请求
6.一旦所有异步语句都已执行并返回，客户端应用程序显式终止管道模式并将连接返回到其默认设置。
由于每个 SQL 语句本质上都是幂等的，因此由客户端逻辑来理解结果。发送 SQL 语句并提取彼此无关的结果是一回事，但是当处理具有某种程度相互依赖的逻辑结果时，会变得更加复杂。
可以将异步SQL语句捆绑为单个事务。但与所有事务一样，这些异步发送的SQL语句中的任何一个失败都将导致所有SQL语句回滚。
当然，API确实在管道故障的情况下提供错误处理。在 FATAL情况下，当管道本身失败时，客户端连接会收到错误通知，从而将剩余的排队操作标记为丢失。此后恢复正常处理，就好像管道已被客户端明确关闭，并且客户端连接保持活动状态。
·管道模式专为异步模式而设计。因此，同步模式是不可能的，这有点违背了管道模式的目的。
·一次只能发送一个SQL命令，即不允许多个SQL命令。
·不允许copy。
·在发送事务COMMIT的情况下：客户端在收到相应结果之前不能假定事务已提交。