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