Re: Libpq PGRES_COPY_BOTH - version compatibility

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Libpq PGRES_COPY_BOTH - version compatibility
Date: 2010-12-28 12:22:05
Message-ID: AANLkTimtnR525x_gz5s5EAyn2kTpuyjdGreBFgxY5Xcs@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 28, 2010 at 13:18, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Dec 28, 2010 at 7:13 AM, Magnus Hagander <magnus(at)hagander(dot)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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2010-12-28 12:46:33 Re: system views for walsender activity
Previous Message Robert Haas 2010-12-28 12:18:57 Re: Libpq PGRES_COPY_BOTH - version compatibility