Re: Libpq PGRES_COPY_BOTH - version compatibility
От | Magnus Hagander |
---|---|
Тема | Re: Libpq PGRES_COPY_BOTH - version compatibility |
Дата | |
Msg-id | AANLkTi=rAy_8rvWG1O7ZkGKKaR6hvdj-AxN6YnCxjENT@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Libpq PGRES_COPY_BOTH - version compatibility (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Libpq PGRES_COPY_BOTH - version compatibility
|
Список | 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 по дате отправления: