2 54.7. Message Formats #
4 This section describes the detailed format of each message. Each is
5 marked to indicate that it can be sent by a frontend (F), a backend
6 (B), or both (F & B). Notice that although each message includes a byte
7 count at the beginning, most messages are defined so that the message
8 end can be found without reference to the byte count. This is for
9 historical reasons, as the original, now-obsolete protocol version 2
10 did not have an explicit length field. It also aids validity checking
13 AuthenticationOk (B) #
16 Identifies the message as an authentication request.
19 Length of message contents in bytes, including self.
22 Specifies that the authentication was successful.
24 AuthenticationKerberosV5 (B) #
27 Identifies the message as an authentication request.
30 Length of message contents in bytes, including self.
33 Specifies that Kerberos V5 authentication is required.
35 AuthenticationCleartextPassword (B) #
38 Identifies the message as an authentication request.
41 Length of message contents in bytes, including self.
44 Specifies that a clear-text password is required.
46 AuthenticationMD5Password (B) #
49 Identifies the message as an authentication request.
52 Length of message contents in bytes, including self.
55 Specifies that an MD5-encrypted password is required.
58 The salt to use when encrypting the password.
60 AuthenticationGSS (B) #
63 Identifies the message as an authentication request.
66 Length of message contents in bytes, including self.
69 Specifies that GSSAPI authentication is required.
71 AuthenticationGSSContinue (B) #
74 Identifies the message as an authentication request.
77 Length of message contents in bytes, including self.
80 Specifies that this message contains GSSAPI or SSPI data.
83 GSSAPI or SSPI authentication data.
85 AuthenticationSSPI (B) #
88 Identifies the message as an authentication request.
91 Length of message contents in bytes, including self.
94 Specifies that SSPI authentication is required.
96 AuthenticationSASL (B) #
99 Identifies the message as an authentication request.
102 Length of message contents in bytes, including self.
105 Specifies that SASL authentication is required.
107 The message body is a list of SASL authentication mechanisms, in
108 the server's order of preference. A zero byte is required as
109 terminator after the last authentication mechanism name. For
110 each mechanism, there is the following:
113 Name of a SASL authentication mechanism.
115 AuthenticationSASLContinue (B) #
118 Identifies the message as an authentication request.
121 Length of message contents in bytes, including self.
124 Specifies that this message contains a SASL challenge.
127 SASL data, specific to the SASL mechanism being used.
129 AuthenticationSASLFinal (B) #
132 Identifies the message as an authentication request.
135 Length of message contents in bytes, including self.
138 Specifies that SASL authentication has completed.
141 SASL outcome "additional data", specific to the SASL
142 mechanism being used.
147 Identifies the message as cancellation key data. The
148 frontend must save these values if it wishes to be able to
149 issue CancelRequest messages later.
152 Length of message contents in bytes, including self.
155 The process ID of this backend.
158 The secret key of this backend. This field extends to the
159 end of the message, indicated by the length field.
161 The minimum and maximum key length are 4 and 256 bytes,
162 respectively. The PostgreSQL server only sends keys up to
163 32 bytes, but the larger maximum size allows for future
164 server versions, as well as connection poolers and other
165 middleware, to use longer keys. One possible use case is
166 augmenting the server's key with extra information.
167 Middleware is therefore also encouraged to not use up all
168 of the bytes, in case multiple middleware applications are
169 layered on top of each other, each of which may wrap the
172 Before protocol version 3.2, the secret key was always 4 bytes
178 Identifies the message as a Bind command.
181 Length of message contents in bytes, including self.
184 The name of the destination portal (an empty string
185 selects the unnamed portal).
188 The name of the source prepared statement (an empty string
189 selects the unnamed prepared statement).
192 The number of parameter format codes that follow (denoted
193 C below). This can be zero to indicate that there are no
194 parameters or that the parameters all use the default
195 format (text); or one, in which case the specified format
196 code is applied to all parameters; or it can equal the
197 actual number of parameters.
200 The parameter format codes. Each must presently be zero
201 (text) or one (binary).
204 The number of parameter values that follow (possibly
205 zero). This must match the number of parameters needed by
208 Next, the following pair of fields appear for each parameter:
211 The length of the parameter value, in bytes (this count
212 does not include itself). Can be zero. As a special case,
213 -1 indicates a NULL parameter value. No value bytes follow
217 The value of the parameter, in the format indicated by the
218 associated format code. n is the above length.
220 After the last parameter, the following fields appear:
223 The number of result-column format codes that follow
224 (denoted R below). This can be zero to indicate that there
225 are no result columns or that the result columns should
226 all use the default format (text); or one, in which case
227 the specified format code is applied to all result columns
228 (if any); or it can equal the actual number of result
229 columns of the query.
232 The result-column format codes. Each must presently be
233 zero (text) or one (binary).
238 Identifies the message as a Bind-complete indicator.
241 Length of message contents in bytes, including self.
246 Length of message contents in bytes, including self.
249 The cancel request code. The value is chosen to contain
250 1234 in the most significant 16 bits, and 5678 in the
251 least significant 16 bits. (To avoid confusion, this code
252 must not be the same as any protocol version number.)
255 The process ID of the target backend.
258 The secret key for the target backend. This field extends
259 to the end of the message, indicated by the length field.
260 The maximum key length is 256 bytes.
262 Before protocol version 3.2, the secret key was always 4 bytes
268 Identifies the message as a Close command.
271 Length of message contents in bytes, including self.
274 'S' to close a prepared statement; or 'P' to close a
278 The name of the prepared statement or portal to close (an
279 empty string selects the unnamed prepared statement or
285 Identifies the message as a Close-complete indicator.
288 Length of message contents in bytes, including self.
290 CommandComplete (B) #
293 Identifies the message as a command-completed response.
296 Length of message contents in bytes, including self.
299 The command tag. This is usually a single word that
300 identifies which SQL command was completed.
302 For an INSERT command, the tag is INSERT oid rows, where
303 rows is the number of rows inserted. oid used to be the
304 object ID of the inserted row if rows was 1 and the target
305 table had OIDs, but OIDs system columns are not supported
306 anymore; therefore oid is always 0.
308 For a DELETE command, the tag is DELETE rows where rows is
309 the number of rows deleted.
311 For an UPDATE command, the tag is UPDATE rows where rows
312 is the number of rows updated.
314 For a MERGE command, the tag is MERGE rows where rows is
315 the number of rows inserted, updated, or deleted.
317 For a SELECT or CREATE TABLE AS command, the tag is SELECT
318 rows where rows is the number of rows retrieved.
320 For a MOVE command, the tag is MOVE rows where rows is the
321 number of rows the cursor's position has been changed by.
323 For a FETCH command, the tag is FETCH rows where rows is
324 the number of rows that have been retrieved from the
327 For a COPY command, the tag is COPY rows where rows is the
328 number of rows copied. (Note: the row count appears only
329 in PostgreSQL 8.2 and later.)
334 Identifies the message as COPY data.
337 Length of message contents in bytes, including self.
340 Data that forms part of a COPY data stream. Messages sent
341 from the backend will always correspond to single data
342 rows, but messages sent by frontends might divide the data
348 Identifies the message as a COPY-complete indicator.
351 Length of message contents in bytes, including self.
356 Identifies the message as a COPY-failure indicator.
359 Length of message contents in bytes, including self.
362 An error message to report as the cause of failure.
367 Identifies the message as a Start Copy In response. The
368 frontend must now send copy-in data (if not prepared to do
369 so, send a CopyFail message).
372 Length of message contents in bytes, including self.
375 0 indicates the overall COPY format is textual (rows
376 separated by newlines, columns separated by separator
377 characters, etc.). 1 indicates the overall copy format is
378 binary (similar to DataRow format). See COPY for more
382 The number of columns in the data to be copied (denoted N
386 The format codes to be used for each column. Each must
387 presently be zero (text) or one (binary). All must be zero
388 if the overall copy format is textual.
390 CopyOutResponse (B) #
393 Identifies the message as a Start Copy Out response. This
394 message will be followed by copy-out data.
397 Length of message contents in bytes, including self.
400 0 indicates the overall COPY format is textual (rows
401 separated by newlines, columns separated by separator
402 characters, etc.). 1 indicates the overall copy format is
403 binary (similar to DataRow format). See COPY for more
407 The number of columns in the data to be copied (denoted N
411 The format codes to be used for each column. Each must
412 presently be zero (text) or one (binary). All must be zero
413 if the overall copy format is textual.
415 CopyBothResponse (B) #
418 Identifies the message as a Start Copy Both response. This
419 message is used only for Streaming Replication.
422 Length of message contents in bytes, including self.
425 0 indicates the overall COPY format is textual (rows
426 separated by newlines, columns separated by separator
427 characters, etc.). 1 indicates the overall copy format is
428 binary (similar to DataRow format). See COPY for more
432 The number of columns in the data to be copied (denoted N
436 The format codes to be used for each column. Each must
437 presently be zero (text) or one (binary). All must be zero
438 if the overall copy format is textual.
443 Identifies the message as a data row.
446 Length of message contents in bytes, including self.
449 The number of column values that follow (possibly zero).
451 Next, the following pair of fields appear for each column:
454 The length of the column value, in bytes (this count does
455 not include itself). Can be zero. As a special case, -1
456 indicates a NULL column value. No value bytes follow in
460 The value of the column, in the format indicated by the
461 associated format code. n is the above length.
466 Identifies the message as a Describe command.
469 Length of message contents in bytes, including self.
472 'S' to describe a prepared statement; or 'P' to describe a
476 The name of the prepared statement or portal to describe
477 (an empty string selects the unnamed prepared statement or
480 EmptyQueryResponse (B) #
483 Identifies the message as a response to an empty query
484 string. (This substitutes for CommandComplete.)
487 Length of message contents in bytes, including self.
492 Identifies the message as an error.
495 Length of message contents in bytes, including self.
497 The message body consists of one or more identified fields,
498 followed by a zero byte as a terminator. Fields can appear in
499 any order. For each field there is the following:
502 A code identifying the field type; if zero, this is the
503 message terminator and no string follows. The presently
504 defined field types are listed in Section 54.8. Since more
505 field types might be added in future, frontends should
506 silently ignore fields of unrecognized type.
514 Identifies the message as an Execute command.
517 Length of message contents in bytes, including self.
520 The name of the portal to execute (an empty string selects
524 Maximum number of rows to return, if portal contains a
525 query that returns rows (ignored otherwise). Zero denotes
531 Identifies the message as a Flush command.
534 Length of message contents in bytes, including self.
539 Identifies the message as a function call.
542 Length of message contents in bytes, including self.
545 Specifies the object ID of the function to call.
548 The number of argument format codes that follow (denoted C
549 below). This can be zero to indicate that there are no
550 arguments or that the arguments all use the default format
551 (text); or one, in which case the specified format code is
552 applied to all arguments; or it can equal the actual
556 The argument format codes. Each must presently be zero
557 (text) or one (binary).
560 Specifies the number of arguments being supplied to the
563 Next, the following pair of fields appear for each argument:
566 The length of the argument value, in bytes (this count
567 does not include itself). Can be zero. As a special case,
568 -1 indicates a NULL argument value. No value bytes follow
572 The value of the argument, in the format indicated by the
573 associated format code. n is the above length.
575 After the last argument, the following field appears:
578 The format code for the function result. Must presently be
579 zero (text) or one (binary).
581 FunctionCallResponse (B) #
584 Identifies the message as a function call result.
587 Length of message contents in bytes, including self.
590 The length of the function result value, in bytes (this
591 count does not include itself). Can be zero. As a special
592 case, -1 indicates a NULL function result. No value bytes
593 follow in the NULL case.
596 The value of the function result, in the format indicated
597 by the associated format code. n is the above length.
602 Length of message contents in bytes, including self.
605 The GSSAPI Encryption request code. The value is chosen to
606 contain 1234 in the most significant 16 bits, and 5680 in
607 the least significant 16 bits. (To avoid confusion, this
608 code must not be the same as any protocol version number.)
613 Identifies the message as a GSSAPI or SSPI response. Note
614 that this is also used for SASL and password response
615 messages. The exact message type can be deduced from the
619 Length of message contents in bytes, including self.
622 GSSAPI/SSPI specific message data.
624 NegotiateProtocolVersion (B) #
627 Identifies the message as a protocol version negotiation
631 Length of message contents in bytes, including self.
634 Newest minor protocol version supported by the server for
635 the major protocol version requested by the client.
638 Number of protocol options not recognized by the server.
640 Then, for protocol option not recognized by the server, there is
649 Identifies the message as a no-data indicator.
652 Length of message contents in bytes, including self.
657 Identifies the message as a notice.
660 Length of message contents in bytes, including self.
662 The message body consists of one or more identified fields,
663 followed by a zero byte as a terminator. Fields can appear in
664 any order. For each field there is the following:
667 A code identifying the field type; if zero, this is the
668 message terminator and no string follows. The presently
669 defined field types are listed in Section 54.8. Since more
670 field types might be added in future, frontends should
671 silently ignore fields of unrecognized type.
676 NotificationResponse (B) #
679 Identifies the message as a notification response.
682 Length of message contents in bytes, including self.
685 The process ID of the notifying backend process.
688 The name of the channel that the notify has been raised
692 The “payload” string passed from the notifying process.
694 ParameterDescription (B) #
697 Identifies the message as a parameter description.
700 Length of message contents in bytes, including self.
703 The number of parameters used by the statement (can be
706 Then, for each parameter, there is the following:
709 Specifies the object ID of the parameter data type.
711 ParameterStatus (B) #
714 Identifies the message as a run-time parameter status
718 Length of message contents in bytes, including self.
721 The name of the run-time parameter being reported.
724 The current value of the parameter.
729 Identifies the message as a Parse command.
732 Length of message contents in bytes, including self.
735 The name of the destination prepared statement (an empty
736 string selects the unnamed prepared statement).
739 The query string to be parsed.
742 The number of parameter data types specified (can be
743 zero). Note that this is not an indication of the number
744 of parameters that might appear in the query string, only
745 the number that the frontend wants to prespecify types
748 Then, for each parameter, there is the following:
751 Specifies the object ID of the parameter data type.
752 Placing a zero here is equivalent to leaving the type
758 Identifies the message as a Parse-complete indicator.
761 Length of message contents in bytes, including self.
763 PasswordMessage (F) #
766 Identifies the message as a password response. Note that
767 this is also used for GSSAPI, SSPI and SASL response
768 messages. The exact message type can be deduced from the
772 Length of message contents in bytes, including self.
775 The password (encrypted, if requested).
777 PortalSuspended (B) #
780 Identifies the message as a portal-suspended indicator.
781 Note this only appears if an Execute message's row-count
785 Length of message contents in bytes, including self.
790 Identifies the message as a simple query.
793 Length of message contents in bytes, including self.
796 The query string itself.
801 Identifies the message type. ReadyForQuery is sent
802 whenever the backend is ready for a new query cycle.
805 Length of message contents in bytes, including self.
808 Current backend transaction status indicator. Possible
809 values are 'I' if idle (not in a transaction block); 'T'
810 if in a transaction block; or 'E' if in a failed
811 transaction block (queries will be rejected until block is
817 Identifies the message as a row description.
820 Length of message contents in bytes, including self.
823 Specifies the number of fields in a row (can be zero).
825 Then, for each field, there is the following:
831 If the field can be identified as a column of a specific
832 table, the object ID of the table; otherwise zero.
835 If the field can be identified as a column of a specific
836 table, the attribute number of the column; otherwise zero.
839 The object ID of the field's data type.
842 The data type size (see pg_type.typlen). Note that
843 negative values denote variable-width types.
846 The type modifier (see pg_attribute.atttypmod). The
847 meaning of the modifier is type-specific.
850 The format code being used for the field. Currently will
851 be zero (text) or one (binary). In a RowDescription
852 returned from the statement variant of Describe, the
853 format code is not yet known and will always be zero.
855 SASLInitialResponse (F) #
858 Identifies the message as an initial SASL response. Note
859 that this is also used for GSSAPI, SSPI and password
860 response messages. The exact message type is deduced from
864 Length of message contents in bytes, including self.
867 Name of the SASL authentication mechanism that the client
871 Length of SASL mechanism specific "Initial Client
872 Response" that follows, or -1 if there is no Initial
876 SASL mechanism specific "Initial Response".
881 Identifies the message as a SASL response. Note that this
882 is also used for GSSAPI, SSPI and password response
883 messages. The exact message type can be deduced from the
887 Length of message contents in bytes, including self.
890 SASL mechanism specific message data.
895 Length of message contents in bytes, including self.
898 The SSL request code. The value is chosen to contain 1234
899 in the most significant 16 bits, and 5679 in the least
900 significant 16 bits. (To avoid confusion, this code must
901 not be the same as any protocol version number.)
906 Length of message contents in bytes, including self.
909 The protocol version number. The most significant 16 bits
910 are the major version number (3 for the protocol described
911 here). The least significant 16 bits are the minor version
912 number (2 for the protocol described here).
914 The protocol version number is followed by one or more pairs of
915 parameter name and value strings. A zero byte is required as a
916 terminator after the last name/value pair. Parameters can appear
917 in any order. user is required, others are optional. Each
918 parameter is specified as:
921 The parameter name. Currently recognized names are:
924 The database user name to connect as. Required;
928 The database to connect to. Defaults to the user
932 Command-line arguments for the backend. (This is
933 deprecated in favor of setting individual run-time
934 parameters.) Spaces within this string are
935 considered to separate arguments, unless escaped
936 with a backslash (\); write \\ to represent a
940 Used to connect in streaming replication mode, where
941 a small set of replication commands can be issued
942 instead of SQL statements. Value can be true, false,
943 or database, and the default is false. See
944 Section 54.4 for details.
946 In addition to the above, other parameters may be listed.
947 Parameter names beginning with _pq_. are reserved for use
948 as protocol extensions, while others are treated as
949 run-time parameters to be set at backend start time. Such
950 settings will be applied during backend start (after
951 parsing the command-line arguments if any) and will act as
960 Identifies the message as a Sync command.
963 Length of message contents in bytes, including self.
968 Identifies the message as a termination.
971 Length of message contents in bytes, including self.