Re: Libpq PGRES_COPY_BOTH - version compatibility - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Libpq PGRES_COPY_BOTH - version compatibility
Date
Msg-id AANLkTi=rAy_8rvWG1O7ZkGKKaR6hvdj-AxN6YnCxjENT@mail.gmail.com
Whole thread Raw
In response to Re: Libpq PGRES_COPY_BOTH - version compatibility  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Libpq PGRES_COPY_BOTH - version compatibility  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Sun, Jan 2, 2011 at 15:07, Peter Eisentraut <peter_e@gmx.net> wrote:
> On tis, 2010-12-28 at 13:13 +0100, Magnus Hagander wrote:
>> My pg_streamrecv no longer works with 9.1, because it returns
>> PGRES_COPY_BOTH instead of PGRES_COPY_OUT when initating a copy.
>> That's fine.
>>
>> So I'd like to make it work on both. Specifically, I would like it to
>> check for PGRES_COPY_BOTH if the server is 9.1 and PGRES_COPY_OUT if
>> it's 9.0. Which can be done by checking the server version.
>
> 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.

That said, if we are going to incorporate pg_streamrecv in the backend
for 9.1, *my* problem goes away, as does the problem directly related
to the change of PGRES_COPY_OUT. But the basic principle of the
problem still remains...

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: "Brar Piening"
Date:
Subject: Re: Visual Studio 2010/Windows SDK 7.1 support
Next
From: Dmitry Koterov
Date:
Subject: Re: pg_dump --split patch