Skip to content

Commit 3174d69

Browse files
hlinnakahlinnaka
committed
Remove server and libpq support for old FE/BE protocol version 2.
Protocol version 3 was introduced in PostgreSQL 7.4. There shouldn't be many clients or servers left out there without version 3 support. But as a courtesy, I kept just enough of the old protocol support that we can still send the "unsupported protocol version" error in v2 format, so that old clients can display the message properly. Likewise, libpq still understands v2 ErrorResponse messages when establishing a connection. The impetus to do this now is that I'm working on a patch to COPY FROM, to always prefetch some data. We cannot do that safely with the old protocol, because it requires parsing the input one byte at a time to detect the end-of-copy marker. Reviewed-by: Tom Lane, Alvaro Herrera, John Naylor Discussion: https://www.postgresql.org/message-id/9ec25819-0a8a-d51a-17dc-4150bb3cca3b%40iki.fi
1 parent 0a687c8 commit 3174d69

33 files changed

+303
-3114
lines changed

‎doc/src/sgml/libpq.sgml

+16-63
Original file line numberDiff line numberDiff line change
@@ -2274,20 +2274,6 @@ const char *PQparameterStatus(const PGconn *conn, const char *paramName);
22742274
cannot change after startup.
22752275
</para>
22762276

2277-
<para>
2278-
Pre-3.0-protocol servers do not report parameter settings, but
2279-
<application>libpq</application> includes logic to obtain values for
2280-
<varname>server_version</varname> and <varname>client_encoding</varname> anyway.
2281-
Applications are encouraged to use <xref linkend="libpq-PQparameterStatus"/>
2282-
rather than <foreignphrase>ad hoc</foreignphrase> code to determine these values.
2283-
(Beware however that on a pre-3.0 connection, changing
2284-
<varname>client_encoding</varname> via <command>SET</command> after connection
2285-
startup will not be reflected by <xref linkend="libpq-PQparameterStatus"/>.)
2286-
For <varname>server_version</varname>, see also
2287-
<xref linkend="libpq-PQserverVersion"/>, which returns the information in a
2288-
numeric form that is much easier to compare against.
2289-
</para>
2290-
22912277
<para>
22922278
If no value for <varname>standard_conforming_strings</varname> is reported,
22932279
applications can assume it is <literal>off</literal>, that is, backslashes
@@ -2314,15 +2300,12 @@ const char *PQparameterStatus(const PGconn *conn, const char *paramName);
23142300
int PQprotocolVersion(const PGconn *conn);
23152301
</synopsis>
23162302
Applications might wish to use this function to determine whether certain
2317-
features are supported. Currently, the possible values are 2 (2.0
2318-
protocol), 3 (3.0 protocol), or zero (connection bad). The
2319-
protocol version will
2303+
features are supported. Currently, the possible values are 3
2304+
(3.0 protocol), or zero (connection bad). The protocol version will
23202305
not change after connection startup is complete, but it could
2321-
theoretically change during a connection reset. The 3.0 protocol
2322-
will normally be used when communicating with
2323-
<productname>PostgreSQL</productname> 7.4 or later servers; pre-7.4 servers
2324-
support only protocol 2.0. (Protocol 1.0 is obsolete and not
2325-
supported by <application>libpq</application>.)
2306+
theoretically change during a connection reset. The 3.0 protocol is
2307+
supported by <productname>PostgreSQL</productname> server versions 7.4
2308+
and above.
23262309
</para>
23272310
</listitem>
23282311
</varlistentry>
@@ -2739,8 +2722,7 @@ PGresult *PQexecParams(PGconn *conn,
27392722
<xref linkend="libpq-PQexecParams"/> is like <xref linkend="libpq-PQexec"/>, but offers additional
27402723
functionality: parameter values can be specified separately from the command
27412724
string proper, and query results can be requested in either text or binary
2742-
format. <xref linkend="libpq-PQexecParams"/> is supported only in protocol 3.0 and later
2743-
connections; it will fail when using protocol 2.0.
2725+
format.
27442726
</para>
27452727

27462728
<para>
@@ -2917,8 +2899,6 @@ PGresult *PQprepare(PGconn *conn,
29172899
execution with <xref linkend="libpq-PQexecPrepared"/>. This feature allows
29182900
commands to be executed repeatedly without being parsed and
29192901
planned each time; see <xref linkend="sql-prepare"/> for details.
2920-
<xref linkend="libpq-PQprepare"/> is supported only in protocol 3.0 and later
2921-
connections; it will fail when using protocol 2.0.
29222902
</para>
29232903

29242904
<para>
@@ -2992,9 +2972,7 @@ PGresult *PQexecPrepared(PGconn *conn,
29922972
This feature allows commands that will be used repeatedly to be
29932973
parsed and planned just once, rather than each time they are
29942974
executed. The statement must have been prepared previously in
2995-
the current session. <xref linkend="libpq-PQexecPrepared"/> is supported
2996-
only in protocol 3.0 and later connections; it will fail when
2997-
using protocol 2.0.
2975+
the current session.
29982976
</para>
29992977

30002978
<para>
@@ -3021,8 +2999,6 @@ PGresult *PQdescribePrepared(PGconn *conn, const char *stmtName);
30212999
<para>
30223000
<xref linkend="libpq-PQdescribePrepared"/> allows an application to obtain
30233001
information about a previously prepared statement.
3024-
<xref linkend="libpq-PQdescribePrepared"/> is supported only in protocol 3.0
3025-
and later connections; it will fail when using protocol 2.0.
30263002
</para>
30273003

30283004
<para>
@@ -3059,8 +3035,6 @@ PGresult *PQdescribePortal(PGconn *conn, const char *portalName);
30593035
(<application>libpq</application> does not provide any direct access to
30603036
portals, but you can use this function to inspect the properties
30613037
of a cursor created with a <command>DECLARE CURSOR</command> SQL command.)
3062-
<xref linkend="libpq-PQdescribePortal"/> is supported only in protocol 3.0
3063-
and later connections; it will fail when using protocol 2.0.
30643038
</para>
30653039

30663040
<para>
@@ -3566,8 +3540,6 @@ char *PQresultErrorField(const PGresult *res, int fieldcode);
35663540
<para>
35673541
Errors generated internally by <application>libpq</application> will
35683542
have severity and primary message, but typically no other fields.
3569-
Errors returned by a pre-3.0-protocol server will include severity and
3570-
primary message, and sometimes a detail message, but no other fields.
35713543
</para>
35723544

35733545
<para>
@@ -3728,8 +3700,7 @@ Oid PQftable(const PGresult *res,
37283700

37293701
<para>
37303702
<literal>InvalidOid</literal> is returned if the column number is out of range,
3731-
or if the specified column is not a simple reference to a table column,
3732-
or when using pre-3.0 protocol.
3703+
or if the specified column is not a simple reference to a table column.
37333704
You can query the system table <literal>pg_class</literal> to determine
37343705
exactly which table is referenced.
37353706
</para>
@@ -3759,8 +3730,7 @@ int PQftablecol(const PGresult *res,
37593730

37603731
<para>
37613732
Zero is returned if the column number is out of range, or if the
3762-
specified column is not a simple reference to a table column, or
3763-
when using pre-3.0 protocol.
3733+
specified column is not a simple reference to a table column.
37643734
</para>
37653735
</listitem>
37663736
</varlistentry>
@@ -4593,8 +4563,8 @@ int PQsendQueryParams(PGconn *conn,
45934563
query parameters can be specified separately from the query string.
45944564
The function's parameters are handled identically to
45954565
<xref linkend="libpq-PQexecParams"/>. Like
4596-
<xref linkend="libpq-PQexecParams"/>, it will not work on 2.0-protocol
4597-
connections, and it allows only one command in the query string.
4566+
<xref linkend="libpq-PQexecParams"/>, it allows only one command in the
4567+
query string.
45984568
</para>
45994569
</listitem>
46004570
</varlistentry>
@@ -4619,9 +4589,7 @@ int PQsendPrepare(PGconn *conn,
46194589
After a successful call, call <xref linkend="libpq-PQgetResult"/> to
46204590
determine whether the server successfully created the prepared
46214591
statement. The function's parameters are handled identically to
4622-
<xref linkend="libpq-PQprepare"/>. Like
4623-
<xref linkend="libpq-PQprepare"/>, it will not work on 2.0-protocol
4624-
connections.
4592+
<xref linkend="libpq-PQprepare"/>.
46254593
</para>
46264594
</listitem>
46274595
</varlistentry>
@@ -4647,9 +4615,7 @@ int PQsendQueryPrepared(PGconn *conn,
46474615
the command to be executed is specified by naming a
46484616
previously-prepared statement, instead of giving a query string.
46494617
The function's parameters are handled identically to
4650-
<xref linkend="libpq-PQexecPrepared"/>. Like
4651-
<xref linkend="libpq-PQexecPrepared"/>, it will not work on
4652-
2.0-protocol connections.
4618+
<xref linkend="libpq-PQexecPrepared"/>.
46534619
</para>
46544620
</listitem>
46554621
</varlistentry>
@@ -4669,9 +4635,7 @@ int PQsendDescribePrepared(PGconn *conn, const char *stmtName);
46694635
it returns 1 if it was able to dispatch the request, and 0 if not.
46704636
After a successful call, call <xref linkend="libpq-PQgetResult"/> to
46714637
obtain the results. The function's parameters are handled
4672-
identically to <xref linkend="libpq-PQdescribePrepared"/>. Like
4673-
<xref linkend="libpq-PQdescribePrepared"/>, it will not work on
4674-
2.0-protocol connections.
4638+
identically to <xref linkend="libpq-PQdescribePrepared"/>.
46754639
</para>
46764640
</listitem>
46774641
</varlistentry>
@@ -4691,9 +4655,7 @@ int PQsendDescribePortal(PGconn *conn, const char *portalName);
46914655
it returns 1 if it was able to dispatch the request, and 0 if not.
46924656
After a successful call, call <xref linkend="libpq-PQgetResult"/> to
46934657
obtain the results. The function's parameters are handled
4694-
identically to <xref linkend="libpq-PQdescribePortal"/>. Like
4695-
<xref linkend="libpq-PQdescribePortal"/>, it will not work on
4696-
2.0-protocol connections.
4658+
identically to <xref linkend="libpq-PQdescribePortal"/>.
46974659
</para>
46984660
</listitem>
46994661
</varlistentry>
@@ -5460,13 +5422,6 @@ typedef struct pgNotify
54605422
</variablelist>
54615423
</para>
54625424

5463-
<note>
5464-
<para>
5465-
These additional data values are only available when using protocol
5466-
3.0. When using protocol 2.0, all these functions will return 0.
5467-
</para>
5468-
</note>
5469-
54705425
<sect2 id="libpq-copy-send">
54715426
<title>Functions for Sending <command>COPY</command> Data</title>
54725427

@@ -5531,9 +5486,7 @@ int PQputCopyEnd(PGconn *conn,
55315486
<parameter>errormsg</parameter> used as the error message. (One should not
55325487
assume that this exact error message will come back from the server,
55335488
however, as the server might have already failed the
5534-
<command>COPY</command> for its own reasons. Also note that the option
5535-
to force failure does not work when using pre-3.0-protocol
5536-
connections.)
5489+
<command>COPY</command> for its own reasons.)
55375490
</para>
55385491

55395492
<para>

0 commit comments

Comments
 (0)