1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Overview</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:pgsql-docs@postgresql.org"><LINK
REL="HOME"
TITLE="PostgreSQL 9.1.15 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="Frontend/Backend Protocol"
HREF="protocol.html"><LINK
REL="PREVIOUS"
TITLE="Frontend/Backend Protocol"
HREF="protocol.html"><LINK
REL="NEXT"
TITLE="Message Flow"
HREF="protocol-flow.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"><META
NAME="creation"
CONTENT="2015-02-02T21:03:01"></HEAD
><BODY
CLASS="SECT1"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="5"
ALIGN="center"
VALIGN="bottom"
><A
HREF="index.html"
>PostgreSQL 9.1.15 Documentation</A
></TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
TITLE="Frontend/Backend Protocol"
HREF="protocol.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="protocol.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
>Chapter 46. Frontend/Backend Protocol</TD
><TD
WIDTH="20%"
ALIGN="right"
VALIGN="top"
><A
TITLE="Message Flow"
HREF="protocol-flow.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="PROTOCOL-OVERVIEW"
>46.1. Overview</A
></H1
><P
> The protocol has separate phases for startup and normal operation.
In the startup phase, the frontend opens a connection to the server
and authenticates itself to the satisfaction of the server. (This might
involve a single message, or multiple messages depending on the
authentication method being used.) If all goes well, the server then sends
status information to the frontend, and finally enters normal operation.
Except for the initial startup-request message, this part of the
protocol is driven by the server.
</P
><P
> During normal operation, the frontend sends queries and
other commands to the backend, and the backend sends back query results
and other responses. There are a few cases (such as <TT
CLASS="COMMAND"
>NOTIFY</TT
>)
wherein the
backend will send unsolicited messages, but for the most part this portion
of a session is driven by frontend requests.
</P
><P
> Termination of the session is normally by frontend choice, but can be
forced by the backend in certain cases. In any case, when the backend
closes the connection, it will roll back any open (incomplete) transaction
before exiting.
</P
><P
> Within normal operation, SQL commands can be executed through either of
two sub-protocols. In the <SPAN
CLASS="QUOTE"
>"simple query"</SPAN
> protocol, the frontend
just sends a textual query string, which is parsed and immediately
executed by the backend. In the <SPAN
CLASS="QUOTE"
>"extended query"</SPAN
> protocol,
processing of queries is separated into multiple steps: parsing,
binding of parameter values, and execution. This offers flexibility
and performance benefits, at the cost of extra complexity.
</P
><P
> Normal operation has additional sub-protocols for special operations
such as <TT
CLASS="COMMAND"
>COPY</TT
>.
</P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PROTOCOL-MESSAGE-CONCEPTS"
>46.1.1. Messaging Overview</A
></H2
><P
> 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.
</P
><P
> 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.
</P
><P
> 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.
</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PROTOCOL-QUERY-CONCEPTS"
>46.1.2. Extended Query Overview</A
></H2
><P
> 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: <I
CLASS="FIRSTTERM"
>prepared statements</I
> and
<I
CLASS="FIRSTTERM"
>portals</I
>. A prepared statement represents the result of
parsing, semantic analysis, and (optionally) planning of a textual query
string.
A prepared statement is not necessarily ready to execute, because it might
lack specific values for <I
CLASS="FIRSTTERM"
>parameters</I
>. A portal represents
a ready-to-execute or already-partially-executed statement, with any
missing parameter values filled in. (For <TT
CLASS="COMMAND"
>SELECT</TT
> statements,
a portal is equivalent to an open cursor, but we choose to use a different
term since cursors don't handle non-<TT
CLASS="COMMAND"
>SELECT</TT
> statements.)
</P
><P
> The overall execution cycle consists of a <I
CLASS="FIRSTTERM"
>parse</I
> step,
which creates a prepared statement from a textual query string; a
<I
CLASS="FIRSTTERM"
>bind</I
> step, which creates a portal given a prepared
statement and values for any needed parameters; and an
<I
CLASS="FIRSTTERM"
>execute</I
> step that runs a portal's query. In the case of
a query that returns rows (<TT
CLASS="COMMAND"
>SELECT</TT
>, <TT
CLASS="COMMAND"
>SHOW</TT
>, 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.
</P
><P
> 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 <SPAN
CLASS="QUOTE"
>"unnamed"</SPAN
> 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.
</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PROTOCOL-FORMAT-CODES"
>46.1.3. Formats and Format Codes</A
></H2
><P
> Data of a particular data type might be transmitted in any of several
different <I
CLASS="FIRSTTERM"
>formats</I
>. As of <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> 7.4
the only supported formats are <SPAN
CLASS="QUOTE"
>"text"</SPAN
> and <SPAN
CLASS="QUOTE"
>"binary"</SPAN
>,
but the protocol makes provision for future extensions. The desired
format for any value is specified by a <I
CLASS="FIRSTTERM"
>format code</I
>.
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.
</P
><P
> 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.)
</P
><P
> 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.
</P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="protocol.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="protocol-flow.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Frontend/Backend Protocol</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="protocol.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Message Flow</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
|
