# 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 字符串處理，那么必須自己加上一個。 (另外，文本格式不允許嵌入的空。) 整數的二進制表現形式采用網絡字節序(高位在前)。 對于其它數據類型，請參考文檔或者源代碼了解其二進制表現形式。 請注意，復雜的數據類型的二進制形式可能在不同服務器版本之間變化；文本格式通常是最具有移植性的選擇。