| From: | James William Pye <pgsql(at)jwp(dot)name> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: PQ versions request message |
| Date: | 2005-09-08 02:28:45 |
| Message-ID: | 1126146525.2425.125.camel@localhost |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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, 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 negotiates" the version using trial and error,
effectively(assume 3.0 by sending 'S', if 'E', fallback to 2.0, and
reestablish the connection, apparently).
> > and maybe the server version as well.
>
> That is already available automatically.
Yes, but, AFAIK, only after the protocol has been negotiated and
authentication is complete. Really, I'm not sure if such a feature
should include the server version as selecting feature implementations
based on it is probably a bad idea(TM).
--
Regards, James William Pye
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-09-08 02:54:33 | Re: [COMMITTERS] pgsql: Update timezone data files to release 2005m of the zic database |
| Previous Message | Andrew Dunstan | 2005-09-08 02:24:48 | Re: initdb profiles |