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

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

相反地，伺服器和客戶端都必須小心，切勿傳送不完整的訊息。通常的做法是在開始傳送之前，在緩衝區中整理整個訊息。如果在傳送或接收訊息的過程中發生通訊故障，唯一合理的反應是放棄連線，因為幾乎沒有希望恢復訊息邊界同步。

在擴充查詢協定中，SQL 命令的執行分為多個步驟。步驟之間保留的狀態由兩種物件表示：預備語句和入口。預備語句表示剖析和語義分析文字查詢字串的結果。預備語句本身尚未準備好執行，因為它可能缺少參數的特定值。入口表示已準備好執行或已部分執行的語句，其中填入了任何遺失的參數值。（對於 SELECT 語句，入口相當於開啟的游標，但我們選擇使用不同的術語，因為游標不處理非 SELECT 語句。）

整體執行週期包含一個剖析步驟，該步驟從文字查詢字串建立預備語句；一個繫結步驟，該步驟給定一個預備語句和任何所需參數的值，建立一個入口；以及一個執行步驟，該步驟執行入口的查詢。在傳回列的查詢（SELECT、SHOW 等）的情況下，可以告知執行步驟僅提取有限數量的列，因此可能需要多個執行步驟才能完成操作。

後端可以追蹤多個預備語句和入口（但請注意，這些僅存在於會話中，並且永遠不會在會話之間共享）。現有的預備語句和入口由建立時指定的名稱引用。此外，存在一個「未命名」的預備語句和入口。雖然這些行為與命名物件大致相同，但對它們的操作針對僅執行一次查詢然後丟棄它的情況進行了最佳化，而對命名物件的操作則針對多次使用的預期進行了最佳化。

特定資料型態的資料可以使用幾種不同的格式來傳輸。從 PostgreSQL 7.4 開始，唯一支援的格式是“text” 和 “binary”，但協定預留了未來擴充的空間。任何數值的所需格式都由一個格式代碼指定。客戶端可以為每個傳輸的參數值和查詢結果的每個欄位指定一個格式代碼。文字格式的代碼為零，二進位格式的代碼為一，所有其他格式代碼都保留供未來定義。

數值的文字表示形式是特定資料類型之輸入/輸出轉換函式產生和接受的任何字串。在傳輸的表示形式中，沒有尾隨的空字元；前端必須向接收到的數值添加一個，如果它想將它們作為 C 字串處理。（順便說一句，文字格式不允許嵌入空字元。）

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