# 48.1\. 概要 协议在启动和正常操作过程中有不同的阶段。 在启动阶段里，前端打开一个到服务器的连接并且认证自身以满足服务器。 这些可能包含一条消息，也可能包含多条消息，根据使用的认证方法而不同。 如果所有这些事情都运行平稳，那么服务器就发送状态信息给前端，并最后进入正常操作。 除了初始化的启动请求之外，这部分协议是服务器驱动的。 在正常操作中，前端发送查询和其它命令到后端，然后后端返回查询结果和其它响应。 有少数几种情况(比如 `NOTIFY`)是后端发送主动提供的消息，但绝大多数情况下会话都是由前端请求驱动的。 会话的终止通常是由前端来选择的，但是也可以在某些情况下由后端强制执行。 不管那种情况，如果后端关闭连接，那么他将在退出之前回滚(完成)所有打开的(未完成的)事务。 在正常操作中，SQL 命令可以通过两个子协议中的任何一个执行。 在"简单查询"协议中，前端只是发送一个文本查询串，然后后端马上解析并执行它。 在"扩展查询"协议中，查询的处理被分割为多个步骤：解析，参数值绑定，和执行。 这样就可以提供灵活性和性能的改进，代价是额外的复杂性。 正常操作有用于类似 `COPY` 这样的额外的子协议。 ## 48.1.1\. 消息概述 所有通讯都是通过一个消息流进行的。 消息的第一个字节标识消息类型，然后后面跟着的四个字节声明消息剩下部分的长度(这个长度包括长度域自身，但是不包括消息类型字节)。 剩下的消息内容由消息类型决定。由于历史原因，客户端发送的最早的消息(启动消息)没有初始的消息类型字节。 为了避免和消息流失去同步，服务器和客户端通常都是把整个消息读取到一个缓冲区里(使用字节计数)，然后才试图处理其内容。 这样在处理内容的过程中，如果发现错误，就比较容易恢复。 在非常罕见的情况下(比如说没有足够的内存用来缓冲消息)，接收端可以使用字节计数来判断它在重新读取消息之前需要忽略多少输入。 通常，服务器和客户端都需要注意决不发送一条不完整的消息。 这些通常是通过在发送消息之前，在一个缓冲区里整理整条消息。 如果在发送或者接受一条消息的中间发生了通讯错误，那么唯一合理的反应是放弃连接，因为能够恢复消息边界同步的可能性很小。 ## 48.1.2\. 扩展查询概述 在扩展查询协议中，SQL 命令的执行是被分割成多个步骤的。 步骤与步骤之间保存的状态是由两类的对象代表的：_预备语句_和_入口_。 一个预备语句代表一个文本查询字符串的经过语法分析，语意分析，以及规划之后的结果。 一个预备语句不一定就是可以执行的，因为它可能还缺乏_参数_的值。 一个入口代表一个已经可以执行的或者已经部分执行过的语句，所有参数都已经填充到位了。 (对于 `SELECT` 语句，入口等效于一个打开的游标，使用不同的术语是因为游标不能处理非 `SELECT` 语句)。 完整的执行周期包括一个_解析_步骤，它用一个文本的查询字符串创建一个预备语句； 一个_绑定_步骤，它用一个预备语句和任何所需要的参数值创建一个入口； 以及一个_执行_步骤，它运行一个入口的查询。 如果是一个返回数据行的查询(`SELECT`, `SHOW` 等)，可以告诉执行步骤只抓取有限的一些行，这样就可能需要多个执行步骤来完成操作。 后端可以跟踪多个预备语句和入口(但是要注意，这些只在一个会话内部存在，从来不能在会话之间共享)。 现存的预备语句和入口都是用创建它们的时候赋予的名字引用的。 另外，还存在一个"未命名"的预备语句和入口。 尽管它们的行为和命名对象大部分相同，但是它们是针对只执行一次然后就抛弃的查询进行优化过的，而在命名对象上的操作是针对多次使用优化的。 ## 48.1.3\. 格式和格式代码 特定数据类型的数据可以用几种不同的_格式_中的任意一种来传递。 到 PostgreSQL 7.4 的时候，只支持"文本"和"二进制"两种格式，但是协议为未来的扩展提供了的手段。 任意值要求的格式是用一个_格式代码_声明的。客户端可以为每个传输的参数值和查询结果的每个字段声明一个格式代码。 文本的格式代码是0，二进制的格式代码是1，所有其它的格式代码都保留给将来定义。 文本方式的数值是特定数据类型的输入/输出转换函数接受或者生成的数值的字符串形式。 在传输时的表现上，字符串末尾没有空字符；如果前端要想把收到的值当作 C 字符串处理，那么必须自己加上一个。 (另外，文本格式不允许嵌入的空。) 整数的二进制表现形式采用网络字节序(高位在前)。 对于其它数据类型，请参考文档或者源代码了解其二进制表现形式。 请注意，复杂的数据类型的二进制形式可能在不同服务器版本之间变化；文本格式通常是最具有移植性的选择。