| From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
|---|---|
| To: | James William Pye <pgsql(at)jwp(dot)name> |
| Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: PQ versions request message |
| Date: | 2005-09-08 03:06:22 |
| Message-ID: | 431FAAAE.9090603@opencloud.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
James William Pye wrote:
> 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).
The JDBC driver does exactly the same (or you can explicitly specify a
protocol version to use) and is effectively loading code on demand
anyway, being Java -- but I've seen no problems with the current
approach. I think you're trying tho fix a problem that doesn't exist.
-O
| From | Date | Subject | |
|---|---|---|---|
| Next Message | James William Pye | 2005-09-08 04:27:31 | Re: PQ versions request message |
| Previous Message | Tom Lane | 2005-09-08 02:54:33 | Re: [COMMITTERS] pgsql: Update timezone data files to release 2005m of the zic database |