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 re
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 sor
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 s
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 necess
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
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 negotia
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:
> 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
>
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
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 versions, and
maybe the server vers
10 matches
Mail list logo
