Re: Libpq PGRES_COPY_BOTH - version compatibility

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Libpq PGRES_COPY_BOTH - version compatibility
Дата
Msg-id AANLkTikiAT7jJfsRZDxOp38cTrUgEYz-x=bDbkiOXH3c@mail.gmail.com
обсуждение исходный текст
Ответ на Libpq PGRES_COPY_BOTH - version compatibility  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: Libpq PGRES_COPY_BOTH - version compatibility  (Magnus Hagander <magnus@hagander.net>)
Re: Libpq PGRES_COPY_BOTH - version compatibility  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Dec 28, 2010 at 7:13 AM, Magnus Hagander <magnus@hagander.net> wrote:
> Part of this may be my C skills not being good enough - if so, please
> enlighten me :-)
>
> 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.
>
> However, when built against a libpq 9.0, it doesn't even have the
> symbol PGRES_COPY_BOTH. And I can't check for the presence of said
> symbol using #ifdef, since it's an enum. Nor is there a #define
> available to check the version of the header.
>
> Is there any way to check this at compile time (so I know if I can use
> the symbol or not), without using autoconf (I don't want to bring in
> such a huge dependency for a tiny program)?

Adding a #define to our headers that you can test for seems like the way to go.

> Also, I notice that PGRES_COPY_BOTH was inserted "in the middle" of
> the enum. Doesn't that mean we can get incorrect values for e.g.
> PGRES_FATAL_ERROR if the client is built against one version of libpq
> but executes against another? Shouldn't all such enum values always be
> added at the end?

I think you are right, and that we should fix this.

> Finaly, as long as I only use "the 9.0 style replication",
> PGRES_COPY_BOTH is actually unnecessary, right? It will work exactly
> the same way as PGRES_COPY_OUT?

So far, the protocol message is all we've changed.  I keep hoping some
update synchronous replication patches are going to show up, but so
far they haven't.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Libpq PGRES_COPY_BOTH - version compatibility
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: Libpq PGRES_COPY_BOTH - version compatibility