Re: PQ versions request message - Mailing list pgsql-hackers

From James William Pye
Subject Re: PQ versions request message
Date
Msg-id 1126208697.2425.263.camel@localhost
Whole thread Raw
In response to Re: PQ versions request message  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PQ versions request message
List pgsql-hackers
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 speak the same protocol version anyway, so most
> of the time the extra probe would be useless.  I think you're trying to
> optimize the uncommon case at the expense of the common case.

The feature, being optional, does not always require any extra expense.
The expense is only incurred when the feature is used; those who use are
those who pay. For those users, I imagine this would normally be once
per host per process, and only if the user of the client does not
explicitly specify the PQ version in the first place.

AFA the likelihood of client and servers being of similar vintages, I
imagine that you are right here. Although, I would rather not play a
guessing game if I didn't have to, and the backend very well has the
ability to give me the information that I need to avoid any such thing.

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.
-- 
Regards, James William Pye


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: pg_config/share_dir
Next
From: Thomas Hallgren
Date:
Subject: Re: Attention PL authors: want to be listed in template table?