James William Pye [EMAIL PROTECTED] writes:
Like I asked above, why does it have to be done in two connection
cycles? I'm assume by connection cycle you are referring to reopening
the socket, or...?
You're right, it wouldn't be necessary to tear down the socket --- but
it *would* be necessary
On Thu, 2005-09-08 at 09:17 -0400, Tom Lane wrote:
You're right, it wouldn't be necessary to tear down the socket --- but
it *would* be necessary to have two network round trips. And the point
remains that in most scenarios the client and server will be of similar
vintages and so wish to
James William Pye [EMAIL PROTECTED] writes:
The point is to give client authors the ability to authoritatively
resolve ambiguity that may exist in multiversion supporting clients and
to do so without any version specific code(or at a minimum wrt older
servers) or fingerprinting of any sort.
On Thu, 2005-09-08 at 16:27 -0400, Tom Lane wrote:
Had we had such a facility from the beginning, it would indeed have that
benefit. But unless you are going to start out by dropping client-side
support for all extant server versions, you will not get any such
benefit; you'll still need retry
James William Pye [EMAIL PROTECTED] writes:
I have been writing a PQ client and I have come to think that a
supported PQ versions request startup packet would be useful to client
authors.
Given that it'd be guaranteed not to work with any existing server
versions, I find the usefulness a bit
James William Pye wrote:
I have been writing a PQ client and I have come to think that a
supported PQ versions request startup packet would be useful to
client authors. That is, sending a StartupPacket(Version(0, 0))(or
whatever) would return a message containing a list of supported PQ
On Thu, 2005-09-08 at 03:48 +0200, Peter Eisentraut wrote:
This doesn't make sense to me, because a server does not have any
version requirements on the client (aside from the protocol versions,
which are negotiated automatically).
The use case primarily applies to custom clients(non-libpq,
James William Pye wrote:
The use case primarily applies to custom clients(non-libpq, atm) that
support multiple PQ versions that may be implemented in separate
modules/libraries. (Avoid loading client-2.0 code for a 3.0 connection,
and/or future versions.)
libpq automatically negotiates
On Wed, 2005-09-07 at 22:02 -0400, Tom Lane wrote:
Given that it'd be guaranteed not to work with any existing server
versions, I find the usefulness a bit debatable...
Indeed =(. However, older servers could be easily detected then if the
returned message type is 'E'. If 'E' is returned, it
