Re: PQ versions request message

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 21:27:58
Message-ID: 1126214878.2425.299.camel@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 code. So I still think this isn't
> really worth the trouble it would take to implement.

The benefit will come when extant server versions become antiquated. AFA
difficulty with the implementation is concerned, I wouldn't bother with
anything except the backend. libpq-fe can wait until said antiquation
occurs, and I imagine the backend work being 40 lines or so, no?

> Also, you keep referring to caching the result on the client side and
> re-using it across multiple connections --- but you can do that now,
> so why is that an argument in favor?

Not so much favor, but, rather, it was to target your complaint about
the two required round-trips involved in connection negotiation with a
version query. I was trying to ease that distaste by showing that if
such ambiguity existed where resolution were necessary, it would/should
only need to be done once(save various exceptions, of course).
--
Regards, James William Pye

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2005-09-08 22:51:58 Re: initdb profiles
Previous Message Martijn van Oosterhout 2005-09-08 20:54:17 Suggestion to simplify installation of external modules