From: | James William Pye <pgsql(at)jwp(dot)name> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PQ versions request message |
Date: | 2005-09-08 19:44:57 |
Message-ID: | 1126208697.2425.263.camel@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Hallgren | 2005-09-08 19:45:53 | Re: Attention PL authors: want to be listed in template table? |
Previous Message | Peter Eisentraut | 2005-09-08 19:41:03 | Re: pg_config/share_dir |