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 AANLkTimtnR525x_gz5s5EAyn2kTpuyjdGreBFgxY5Xcs@mail.gmail.com
Whole thread Raw
In response to Re: Libpq PGRES_COPY_BOTH - version compatibility  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Libpq PGRES_COPY_BOTH - version compatibility
List pgsql-hackers
On Tue, Dec 28, 2010 at 13:18, Robert Haas <robertmhaas@gmail.com> wrote:
> 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.

That's kind of what I was going for ;)

Since it's libpq-fe.h, I think it would have to be another one of
those edited by src/tools/version_stamp.pl that Tom doesn't like ;) I
don't see another way though - since we don't pull the configure
output files into libpq-fe.h (and shouldn't).


>> 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.

Phew, at least I'm not completely lost :-) Will you take care of it?


>> 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.

Well, assuming I run it in async mode, would the protocol be likely to
change even then?

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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Libpq PGRES_COPY_BOTH - version compatibility
Next
From: Magnus Hagander
Date:
Subject: Re: system views for walsender activity