所有通訊都透過訊息流進行。訊息的第一個位元組標識訊息型別，接下來的四個位元組指定其餘訊息的長度（此長度計數包括其本身，但不包括訊息型別位元組）。訊息的其餘內容取決於訊息型別。出於歷史原因，客戶端傳送的第一個訊息（啟動訊息）沒有初始的訊息型別位元組。

為了避免與訊息流失去同步，伺服器和客戶端通常會在嘗試處理其內容之前，將整個訊息讀取到緩衝區中（使用位元組計數）。這使得在處理內容時檢測到錯誤時易於恢復。在極端情況下（例如記憶體不足以緩衝訊息），接收方可以使用位元組計數來確定在恢復讀取訊息之前要跳過多少輸入。

相反，伺服器和客戶端都必須小心，切勿傳送不完整訊息。這通常透過在開始傳送之前將整個訊息封存在緩衝區中來完成。如果在傳送或接收訊息的過程中發生通訊故障，唯一明智的響應是放棄連線，因為幾乎不可能恢復訊息邊界同步。

在擴充套件查詢協議中，SQL 命令的執行分為多個步驟。在步驟之間保留的狀態由兩種型別的物件表示：準備好的語句和門戶。準備好的語句表示對文字查詢字串進行解析和語義分析的結果。準備好的語句本身並不準備執行，因為它可能缺少引數的特定值。門戶表示一個已準備好執行或已部分執行的語句，任何缺失的引數值都已填補。（對於 SELECT 語句，門戶等同於一個開啟的遊標，但我們選擇使用不同的術語，因為遊標不處理非 SELECT 語句。）

整體執行週期包括一個解析步驟，該步驟從文字查詢字串建立準備好的語句；一個繫結步驟，該步驟根據準備好的語句和任何所需引數的值建立門戶；以及一個執行步驟，該步驟執行門戶的查詢。對於返回行的查詢（SELECT、SHOW 等），可以指示執行步驟僅獲取有限數量的行，因此可能需要多個執行步驟來完成操作。

後端可以跟蹤多個準備好的語句和門戶（但請注意，這些僅存在於會話中，並且從不跨會話共享）。現有的準備好的語句和門戶透過建立時分配的名稱來引用。此外，還存在一個“未命名”的準備好的語句和門戶。儘管它們在很大程度上與命名物件行為相同，但對它們的と操作針對的是僅執行一次然後丟棄查詢的情況進行了最佳化，而對命名物件的操作則針對的是期望多次使用的情況進行了最佳化。

特定資料型別的資料可能以幾種不同的格式傳輸。截至 PostgreSQL 7.4，唯一支援的格式是“文字”和“二進位制”，但協議為將來的擴充套件提供了規定。任何值的所需格式由格式程式碼指定。客戶端可以為每個傳輸的引數值和每個查詢結果列指定一個格式程式碼。文字的格式程式碼為零，二進位制的格式程式碼為一，所有其他格式程式碼均保留供將來定義。

值的文字表示就是特定資料型別的輸入/輸出轉換函式生成的字串。在傳輸的表示中，沒有尾隨的 null 字元；如果前端想將接收到的值作為 C 字串處理，它必須為其新增一個。（順便說一句，文字格式不允許嵌入 null。）

整數的二進位制表示使用網路位元組序（最高有效位元組在前）。對於其他資料型別，請查閱文件或原始碼以瞭解二進位制表示。請記住，複雜資料型別的二進位制表示可能會在伺服器版本之間發生變化；文字格式通常是更具可移植性的選擇。

當前最新的協議版本是 3.2。但是，為了向後相容不支援版本協商的舊伺服器版本和中介軟體，libpq 預設仍使用協議版本 3.0。

單個伺服器可以支援多個協議版本。初始的啟動請求訊息告知伺服器客戶端嘗試使用的協議版本。如果客戶端請求的主版本不受伺服器支援，連線將被拒絕（例如，如果客戶端請求協議版本 4.0，而此版本在撰寫本文時不存在，則會發生這種情況）。如果客戶端請求的次版本不受伺服器支援（例如，客戶端請求版本 3.2，但伺服器僅支援 3.0），伺服器可以拒絕連線，或者以 NegotiateProtocolVersion 訊息響應，其中包含其支援的最高次協議版本。然後，客戶端可以選擇繼續使用指定的協議版本進行連線，或中止連線。

協議協商已在 PostgreSQL 版本 9.3.21 中引入。早期版本如果客戶端請求的次版本不受伺服器支援，則會拒絕連線。

表 54.1 顯示了當前支援的協議版本。