All communication is through a stream of messages. The first byte of a message identifies the message type, and the next four bytes specify the length of the rest of the message (this length count includes itself, but not the message-type byte). The remaining contents of the message are determined by the message type. For historical reasons, the very first message sent by the client (the startup message) has no initial message-type byte. すべての通信はメッセージストリームを介します。 メッセージの先頭バイトはメッセージ種類を識別するもの、次の４バイトはメッセージの残りの長さを指定するものです （この長さにはメッセージ種類バイトは含まれませんが、自身を含んで数えられます）。 残りのメッセージの内容は、メッセージ種類で決まります。 歴史的な理由のため、一番初めにクライアントから送信されるメッセージ（開始メッセージ）にはメッセージ種類バイトはありません。

To avoid losing synchronization with the message stream, both servers and clients typically read an entire message into a buffer (using the byte count) before attempting to process its contents. This allows easy recovery if an error is detected while processing the contents. In extreme situations (such as not having enough memory to buffer the message), the receiver can use the byte count to determine how much input to skip before it resumes reading messages. メッセージストリームの同期ずれを防ぐために、サーバとクライアントの両方は、通常、メッセージの内容を処理し始める前に、（バイト数を使用して）メッセージ全体をバッファ内に読み込みます。 これにより、その内容を処理する時にエラーが検出された場合に、簡単に復旧することができます。 （メッセージをバッファするために十分なメモリがない場合のような）極限状況では、受信側はメッセージの読み取りを再開する前にどれだけの量の入力を飛ばすかどうかを決定するために、バイト数を活用することができます。

Conversely, both servers and clients must take care never to send an incomplete message. This is commonly done by marshaling the entire message in a buffer before beginning to send it. If a communications failure occurs partway through sending or receiving a message, the only sensible response is to abandon the connection, since there is little hope of recovering message-boundary synchronization. 反対に、サーバとクライアントの両方は、不完全なメッセージを決して送信しないように注意しなければなりません。 これは通常、送信する前にバッファ内のメッセージ全体を整列させることで行われます。 メッセージの送受信の途中で通信エラーが発生した場合、メッセージ境界の同期を復旧できる望みはほとんどありませんので、実用的な唯一の応答は通信を中断することです。

In the extended-query protocol, execution of SQL commands is divided into multiple steps. The state retained between steps is represented by two types of objects: <firstterm>prepared statements</firstterm> and <firstterm>portals</firstterm>. A prepared statement represents the result of parsing and semantic analysis of a textual query string. A prepared statement is not in itself ready to execute, because it might lack specific values for <firstterm>parameters</firstterm>. A portal represents a ready-to-execute or already-partially-executed statement, with any missing parameter values filled in. (For <command>SELECT</command> statements, a portal is equivalent to an open cursor, but we choose to use a different term since cursors don't handle non-<command>SELECT</command> statements.) 拡張問い合わせプロトコルでは、SQLコマンドの実行は複数の段階に分割されます。 段階間で保持される状態は、プリペアド文とポータルの２種類のオブジェクトで表現されます。 プリペアド文は、テキスト問い合わせ文字列の解析、意味解析を表現します。 プリペアド文は実行準備が整ったことを示すものではありません。 パラメータの特定の値が欠落しているかもしれないからです。 ポータルは、すべてのパラメータ値が設定され、実行準備が整った、あるいは、既に一部実行された文を表現します。 （SELECT文では、ポータルは開いているカーソルと等価です。 しかし、カーソルはSELECT以外の文を扱いませんので、ここでは異なる用語を使用するよう選択しました。）

The overall execution cycle consists of a <firstterm>parse</firstterm> step, which creates a prepared statement from a textual query string; a <firstterm>bind</firstterm> step, which creates a portal given a prepared statement and values for any needed parameters; and an <firstterm>execute</firstterm> step that runs a portal's query. In the case of a query that returns rows (<command>SELECT</command>, <command>SHOW</command>, etc.), the execute step can be told to fetch only a limited number of rows, so that multiple execute steps might be needed to complete the operation. 実行サイクル全体は、テキストの問い合わせ文字列からプリペアド文を生成するparse段階、プリペアド文と必要なパラメータ値によりポータルを作成するbind段階、ポータルの問い合わせを実行するexecute段階からなります。 行を返す問い合わせ（SELECT、SHOWなど）の場合、操作を完了させるために複数の実行段階が必要とすることができるように、実行段階に限定された行数のみを取り出すよう指示することができます。

The backend can keep track of multiple prepared statements and portals (but note that these exist only within a session, and are never shared across sessions). Existing prepared statements and portals are referenced by names assigned when they were created. In addition, an <quote>unnamed</quote> prepared statement and portal exist. Although these behave largely the same as named objects, operations on them are optimized for the case of executing a query only once and then discarding it, whereas operations on named objects are optimized on the expectation of multiple uses. バックエンドは複数のプリペアド文とポータルの経過を追うことができます （しかし、1つのセッション内でのみ存在可能です。複数のセッションで共有することはできません）。 存在するプリペアド文とポータルは、作成時に割り当てられた名前で参照されます。 さらに、「無名の」プリペアド文とポータルも存在します。 これらは名前付きのオブジェクトとほとんど同じ動きをしますが、問い合わせを一回だけ実行し、その後に破棄する場合に備えて、これらに対する操作は最適化されています。 一方、名前付きオブジェクトの操作は複数回の使用を想定して最適化されています。

Data of a particular data type might be transmitted in any of several different <firstterm>formats</firstterm>. As of <productname>PostgreSQL</productname> 7.4 the only supported formats are <quote>text</quote> and <quote>binary</quote>, but the protocol makes provision for future extensions. The desired format for any value is specified by a <firstterm>format code</firstterm>. Clients can specify a format code for each transmitted parameter value and for each column of a query result. Text has format code zero, binary has format code one, and all other format codes are reserved for future definition. 特定のデータ型のデータはいくつかの異なる書式で転送することができます。 PostgreSQL 7.4の時点でサポートしている書式は「テキスト」と「バイナリ」のみですが、プロトコルは将来の拡張に備えて準備をしています。 任意の値の必要な書式は書式コードで指定されます。 クライアントは、転送されるパラメータ値それぞれに書式コードを指定することも、問い合わせ結果の列それぞれに書式コードを指定することもできます。 テキストは書式コード0、バイナリは書式コード1です。 他の書式コードは将来の定義用に予約されています。

The text representation of values is whatever strings are produced and accepted by the input/output conversion functions for the particular data type. In the transmitted representation, there is no trailing null character; the frontend must add one to received values if it wants to process them as C strings. (The text format does not allow embedded nulls, by the way.) 値のテキスト表現は、特定のデータ型の入出力変換関数で生成され、受け付けられる何らかの文字列です。 転送時の表現では、ヌル終端文字はありません。 フロントエンドでC言語文字列として処理したい場合は、必ず受信した値にヌル終端文字を追加しなければなりません。 （ついでですが、テキスト書式ではヌルを埋め込むことはできません。）

Binary representations for integers use network byte order (most significant byte first). For other data types consult the documentation or source code to learn about the binary representation. Keep in mind that binary representations for complex data types might change across server versions; the text format is usually the more portable choice. 整数用のバイナリ表現はネットワークバイト順（先頭に最上位バイト）を使用します。 他のデータ型のバイナリ表現については、文書もしくはソースコードを参照してください。 複雑なデータ型のバイナリ表現はサーバのバージョンによって異なる可能性があることに注意してください。 通常、テキスト書式がより移植性が高い選択肢です。