Re: PQ versions request message

Поиск
Список
Период
Сортировка
От James William Pye
Тема Re: PQ versions request message
Дата
Msg-id 1126208697.2425.263.camel@localhost
обсуждение исходный текст
Ответ на Re: PQ versions request message  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: PQ versions request message  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: pg_config/share_dir
Следующее
От: Thomas Hallgren
Дата:
Сообщение: Re: Attention PL authors: want to be listed in template table?