From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Karl O(dot) Pinc" <kop(at)meme(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: psql, remove include of psqlscan.c |
Date: | 2012-09-27 19:37:00 |
Message-ID: | 1328.1348774620@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Karl O. Pinc" <kop(at)meme(dot)com> writes:
> On 09/27/2012 11:02:42 AM, Tom Lane wrote:
>> Rather, the problem is that the server might know about some newer
>> lexical feature, and so might the application, but if libpq is behind
>> the times then it's broken.
> If the application knows about the newer feature and wants
> to use it, is it unreasonable to ask the application
> be linked against a newer libpq?
Well, see the JDBC example: there is no newer driver with the desired
feature for applications to link against. Even if all client-side code
with such knowledge stays perfectly in sync as far as upstream sources
are concerned, there are any number of reasons why particular
installations might have copies of varying vintages. It's not really
a situation that I want to get into more than necessary.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-09-27 20:02:45 | Re: Oid registry |
Previous Message | Alvaro Herrera | 2012-09-27 19:35:27 | Re: pg_signal_backend() asymmetry |