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 AANLkTi==fc_Z4oxkswBKy3STxB17vbPGy6v6y2wehx0f@mail.gmail.com
Whole thread Raw
In response to Re: Libpq PGRES_COPY_BOTH - version compatibility  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Libpq PGRES_COPY_BOTH - version compatibility  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, Dec 29, 2010 at 16:12, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Tue, Dec 28, 2010 at 16:15, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Also, if you really do need to figure out which PG headers you're
>>> compiling against, looking at catversion.h is the accepted way to do it.
>>> There's no need for yet another symbol.
>
>> This file is, AFAIK, not included with client installs? It's
>> definitely not present in the libpq-dev package on debian. It's a
>> backend development file, no?
>
> [ shrug... ]  We can't be held responsible for stupid packaging
> decisions by distros.

Running "make install" in src/interfaces/libpq does not install
catversion.h. If it's required to know which version of the libpq
headers are in use, it should be, shouldn't it?

We can be held responsible for the packaging decisions if they use
*our* "make install" commands, imho.


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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Fixing pg_upgrade's check of available binaries
Next
From: "Kevin Grittner"
Date:
Subject: Re: SSI SLRU strategy choices