Re: Libpq PGRES_COPY_BOTH - version compatibility

On Sun, Mar 27, 2011 at 9:09 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Sun, Mar 27, 2011 at 04:02, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> On Sun, Mar 27, 2011 at 4:09 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> On Mon, Jan 3, 2011 at 6:55 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>>>> ISTM that the correct fix is to increment to protocol version number to
>>>>> 3.1 and send PGRES_COPY_OUT if the client requests version 3.0.  That's
>>>>> what the version numbers are for, no?
>>>>
>>>> In a way - yes. I assume we didn't do that because it's considered "internal".
>>>>
>>>> It still won't help in my situation though - I need to know what
>>>> version of the libpq headers I have in order to even be able to
>>>> *compile* the program. At runtime, I could check against the server
>>>> version, and get around it.
>>>
>>> This is listed on the open items list as "raise protocol version
>>> number", but the above discussion suggests both that this might be
>>> unnecessary and that it might not solve Magnus's problem anyway.
>>>
>>> What do we want to do here?
>>
>> We add an option as to how the protocol behaves, with default as 3.0.
>> Older clients will not know about the new option and so will not
>> request it.
>>
>> Magnus gets his new functionality, nothing breaks.
>
> No he doesn't. Not yet - it needs the version check that's added to
> 9.1 - but it would have been needed for 9.0. So in a similar situation
> at the next release it would be fixed, but not here.
>
> That doesn't mean we shouldn't do this (haven't reconsidered the whole
> thread) - but it doesn't solve the issue I originally raised.

Test the release number? >= 9.0
What's wrong with that?

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services