+++ /dev/null
-Date: Wed, 18 Feb 1998 19:44:52 +0000
-From: Phil Thompson <phil@river-bank.demon.co.uk>
-To: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
-Subject: [DOCS] Re: [HACKERS] Frontend/Backend Protocol
-
-1. Introduction
-
-This document describes V1.0 of the protocol used between PostgreSQL frontends
-and backends. It is a message based protocol running over TCP. V6.3 of
-PostgreSQL introduced version numbers into the protocol. This was done in such
-a way as to still allow connections from earlier versions of frontends, but
-this document does not cover the protocol used by those earlier versions.
-
-This document does not cover how different frontend interfaces may use the
-protocol to implement certain features, eg. the way in which libpq passes
-certain environment variables after the connection is established.
-
-
-2. Overview
-
-The three major components are the frontend (running on the client) and the
-postmaster and backend (running on the server). The postmaster and backend
-have different roles but may be implemented by the same executable.
-
-A frontend sends a startup packet to the postmaster. This includes the names
-of the user and the database the user wants to connect to. The postmaster then
-uses this, and the information in the pg_hba.conf(5) file to determine what
-further authentication information it requires the frontend to send (if any)
-and responds to the frontend accordingly.
-
-The frontend then sends any required authentication information. Once the
-postmaster validates this it responds to the frontend that it is authenticated
-and hands over to a backend.
-
-Subsequent communications are query and result packets exchanged between the
-frontend and the backend. The postmaster takes no further part in the
-communication.
-
-When the frontend wishes to disconnect it sends an appropriate packet and
-closes the connection without waiting for a response for the backend.
-
-Packets are sent as a data stream. The first byte determines what should be
-expected in the rest of the packet. The exception is packets send from a
-frontend to the postmaster, which comprise a packet length then the packet
-itself. The difference is historical.
-
-
-3. Protocol
-
-This section describes the message flow. There are four different types of
-flows depending on the state of the connection.
-
-3.1 Authentication
-
-The frontend sends a StartupPacket. The postmaster uses this and the contents
-of the pg_hba.conf(5) file to determine what authentication method the frontend
-must use. The postmaster then responds with one of the following messages.
-
- ErrorResponse
- The postmaster then immediately closes the connection.
-
- AuthenticationOk
- The postmaster then hands over to the backend. The postmaster
- takes no further part in the communication.
-
- AuthenticationKerberosV4
- The frontend must then take part in a Kerberos V4
- authentication dialog (not described here) with the postmaster.
- If this is succesful, the postmaster responds with an
- AuthenticationOk, otherwise it responds with an ErrorResponse.
-
- AuthenticationKerberosV5
- The frontend must then take part in a Kerberos V5
- authentication dialog (not described here) with the postmaster.
- If this is succesful, the postmaster responds with an
- AuthenticationOk, otherwise it responds with an ErrorResponse.
-
- AuthenticationUnencryptedPassword
- The frontend must then send an UnencryptedPasswordPacket.
- If this is the correct password, the postmaster responds with
- an AuthenticationOk, otherwise it responds with an
- ErrorResponse.
-
- AuthenticationEncryptedPassword
- The frontend must then send an EncryptedPasswordPacket.
- If this is the correct password, the postmaster responds with
- an AuthenticationOk, otherwise it responds with an
- ErrorResponse.
-
-If the frontend does not support the authentication method requested by the
-postmaster, then it should immediately close the connection.
-
-3.2 Query
-
-The frontend sends a Query message to the backend. The response sent by the
-backend depends on the contents of the query. The possible responses are as
-follows.
-
- CompletedResponse
- The query completed normally.
-
- CopyInResponse
- The backend is ready to copy data from the frontend to a
- relation. The frontend should then send a CopyDataRows
- message. The backend will then respond with a
- CompletedResponse message with a tag of "COPY".
-
- CopyOutResponse
- The backend is ready to copy data from a relation to the
- frontend. It then sends a CopyDataRows message, and then a
- CompletedResponse message with a tag of "COPY".
-
- CursorResponse
- The query was either an insert(l), delete(l), update(l),
- fetch(l) or a select(l) command. If the transaction has been
- aborted then the backend sends a CompletedResponse message with
- a tag of "*ABORT STATE*". Otherwise the following responses
- are sent.
-
- For an insert(l) command, the backend then sends a
- CompletedResponse message with a tag of "INSERT <oid> <rows>"
- where <rows> is the number of rows inserted, and <oid> is the
- object ID of the inserted row if <rows> is 1, otherwise <oid>
- is 0.
-
- For a delete(l) command, the backend then sends a
- CompletedResponse message with a tag of "DELETE <rows>" where
- <rows> is the number of rows deleted.
-
- For an update(l) command, the backend then sends a
- CompletedResponse message with a tag of "UPDATE <rows>" where
- <rows> is the number of rows deleted.
-
- For a fetch(l) or select(l) command, the backend sends a
- RowDescription message. This is then followed by an AsciiRow
- or BinaryRow message (depending on if a binary cursor was
- specified) for each row being returned to the frontend.
- Finally, the backend sends a CompletedResponse message with a
- tag of "SELECT".
-
- EmptyQueryResponse
- The query was empty.
-
- ErrorResponse
- An error has occured.
-
- NoticeResponse
- A warning message has been issued in relation to the query.
- Notices are in addition to other responses, ie. the backend
- will send another response message immediately afterwards.
-
- NotificationResponse
- A notify(l) command has been executed for a relation for
- which a previous listen(l) command was executed. Notifications
- are in addition to other responses, ie. the backend will send
- another response message immediately afterwards.
-
-A frontend must be prepared to accept ErrorResponse and NoticeResponse
-messages whenever it is expecting any other type of message.
-
-3.3 Function Call
-
-The frontend sends a FunctionCall message to the backend. The response sent by
-the backend depends on the result of the function call. The possible responses
-are as follows.
-
- ErrorResponse
- An error has occured.
-
- FunctionResultResponse
- The function call was executed and returned a result.
-
- FunctionVoidResponse
- The function call was executed and returned no result.
-
- NoticeResponse
- A warning message has been issued in relation to the function
- call. Notices are in addition to other responses, ie. the
- backend will send another response message immediately
- afterwards.
-
-A frontend must be prepared to accept ErrorResponse and NoticeResponse
-messages whenever it is expecting any other type of message.
-
-3.4 Termination
-
-The frontend sends a Terminate message and immediately closes the connection.
-On receipt of the message, the backend immediately closes the connection and
-terminates.
-
-
-4. Message Data Types
-
-This section describes the base data types used in messages.
-
- Int<n>(i)
- An <n> bit integer in network byte order. If i is specified it
- is the literal value. Eg. Int16, Int32(42).
-
- LimString<n>(s)
- A character array of exactly <n> bytes interpreted as a '\0'
- terminated string. The '\0' is omitted if there is
- insufficient room. If s is specified it is the literal value.
- Eg. LimString32, LimString64("user").
-
- String(s)
- A conventional C '\0' terminated string with no length
- limitation. A frontend should always read the full string
- even though it may have to discard characters if it's buffers
- aren't big enough. If s is specified it is the literal value.
- Eg. String, String("user").
-
- Byte<n>(c)
- Exactly <n> bytes. If c is specified it is the literal
- value. Eg. Byte, Byte1('\n').
-
-
-5. Messages Formats
-
-This section describes the detailed format of each message. Each can be sent
-by either a frontend (F), a postmaster/backend (B), or both (F & B).
-
-AsciiRow (B)
- Byte1('D')
- Identifies the message, in the context in which it is sent (see
- CopyInResponse), as an ASCII row.
- Byte<n>
- A bit map with one bit for each field in the row. The 1st
- field corresponds to bit 7 of the 1st byte, the 2nd field
- corresponds to bit 6 of the 1st byte, the 8th field corresponds
- to bit 0 of the 1st byte, the 9th field corresponds to bit 8 of
- the 2nd byte, and so on. The bit is set if the value of the
- corresponding field is not NULL.
-
- Then, for each field, there is the following.
- Int32
- Specifies the size of the value of the field, including
- this size.
- Byte<n>
- Specifies the value of the field itself in ASCII
- characters. <n> is the above size minus 4.
-
-AuthenticationOk (B)
- Byte1('R')
- Identifies the message as an authentication request.
- Int32(0)
- Specifies that the authentication was succesful.
-
-AuthenticationKerberosV4 (B)
- Byte1('R')
- Identifies the message as an authentication request.
- Int32(1)
- Specifies that Kerberos V4 authentication is required.
-
-AuthenticationKerberosV5 (B)
- Byte1('R')
- Identifies the message as an authentication request.
- Int32(2)
- Specifies that Kerberos V5 authentication is required.
-
-AuthenticationUnencryptedPassword (B)
- Byte1('R')
- Identifies the message as an authentication request.
- Int32(3)
- Specifies that an unencrypted password is required.
-
-AuthenticationEncryptedPassword (B)
- Byte1('R')
- Identifies the message as an authentication request.
- Int32(4)
- Specifies that an encrypted password is required.
- Byte2
- The salt to use when encrypting the password.
-
-BinaryRow (B)
- Byte1('B')
- Identifies the message, in the context in which it is sent (see
- CopyOutResponse), as a binary row.
- Byte<n>
- A bit map with one bit for each field in the row. The 1st
- field corresponds to bit 7 of the 1st byte, the 2nd field
- corresponds to bit 6 of the 1st byte, the 8th field corresponds
- to bit 0 of the 1st byte, the 9th field corresponds to bit 8 of
- the 2nd byte, and so on. The bit is set if the value of the
- corresponding field is not NULL.
-
- Then, for each field, there is the following.
- Int32
- Specifies the size of the value of the field, excluding
- this size.
- Byte<n>
- Specifies the value of the field itself in binary
- format. <n> is the above size.
-
-CompletedResponse (B)
- Byte1('C')
- Identifies the message as a completed response.
- String
- The command tag. This is usually (but not always) a single
- word that identifies which SQL command was completed.
-
-CopyDataRows (B & F)
- This is a stream of rows where each row is terminated by a Char1('\n').
- This is then followed by the sequence Char1('\\'), Char1('.'),
- Char1('\n').
-
-CopyInResponse (B)
- Byte1('D')
- Identifies the message, in the context in which it is sent (see
- AsciiRow), as a copy in started response.
-
-CopyOutResponse (B)
- Byte1('B')
- Identifies the message, in the context in which it is sent (see
- BinaryRow), as a copy out started response.
-
-CursorResponse (B)
- Byte1('P')
- Identifies the message as a cursor response.
- String
- The name of the cursor. This will be "blank" if the cursor is
- implicit.
-
-EmptyQueryResponse (B)
- Byte1('I')
- Identifies the message as an empty query response.
- String("")
- Unused.
-
-EncryptedPasswordPacket (F)
- Int32
- The size of the packet in bytes.
- String
- The encrypted (using crypt()) password.
-
-ErrorResponse (B)
- Byte1('E')
- Identifies the message as an error.
- String
- The error message itself.
-
-FunctionCall (F)
- Byte1('F')
- Identifies the message as a function call.
- String("")
- Unused.
- Int32
- Specifies the object ID of the function to call.
- Int32
- Specifies the number of arguments being supplied to the
- function.
-
- Then, for each argument, there is the following.
- Int32
- Specifies the size of the value of the argument,
- excluding this size.
- Byte<n>
- Specifies the value of the field itself in binary
- format. <n> is the above size.
-
-FunctionResultResponse (B)
- Byte1('V')
- Identifies the message as a function call result.
- Byte1('G')
- Specifies that an actual result was returned.
- Int32
- Specifies the size of the value of the result, excluding this
- size.
- Byte<n>
- Specifies the value of the result itself in binary format.
- <n> is the above size.
- Byte1('0')
- Unused. (Strictly speaking, FunctionResultResponse and
- FunctionVoidResponse are the same thing but with some optional
- parts to the message.)
-
-FunctionVoidResponse (B)
- Byte1('V')
- Identifies the message as a function call result.
- Byte1('0')
- Specifies that no actual result was returned.
-
-NoticeResponse (B)
- Byte1('N')
- Identifies the message as a notice.
- String
- The notice message itself.
-
-NotificationResponse (B)
- Byte1('A')
- Identifies the message as a notification response.
- Int32
- The process ID of the backend process.
- String
- The name of the relation that the notify has been raised on.
-
-Query (F)
- Byte1('Q')
- Identifies the message as query.
- String
- The query itself.
-
-RowDescription (B)
- Byte1('T')
- Identifies the message as a row description.
- Int16
- Specifies the number of fields in a row (and may be zero).
-
- Then, for each field, there is the following.
- String
- Specifies the field name.
- Int32
- Specifies the object ID of the field type.
- Int16
- Specifies the type size.
-
-StartupPacket (F)
- Int32(296)
- The size of the packet in bytes.
- Int32
- The protocol version number. The most significant 16 bits are
- the major version number. The least 16 significant bits are
- the minor version number.
- LimString64
- The database name, defaults to the user name if omitted.
- LimString32
- The user name.
- LimString64
- Any additional command line arguments to be passed to the
- backend by the postmaster.
- LimString64
- Unused.
- LimString64
- The optional tty the backend should use for debugging messages.
-
-Terminate (F)
- Byte1('X')
- Identifies the message as a termination.
-
-UnencryptedPasswordPacket (F)
- Int32
- The size of the packet in bytes.
- String
- The unencrypted password.
-
---------------1B9BA35856C95E22453E911A--
projects / postgresql / commitdiff