Re: Moving of INT64_FORMAT to c.h

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Oct 22, 2014 at 4:12 PM, Steve Singer <steve(at)ssinger(dot)info> wrote:
>> So the header of c.h says "Note that the definitions here are not intended
>> to be exposed to clients"
>> but
>> postgres_fe.h says "This should be the first file included by PostgreSQL
>> client libraries and"
>>
>> Should client programs that live outside the postgres source tree be
>> including postgres_fe.h ? I have a feeling the answer is no. If the answer
>> is no, then why does a make install install postgres_fe.h ?

> I think the answer is yes.

Yeah. In particular, postgres_fe.h sees to it that FRONTEND is #define'd;
without that there is *not* a guarantee that c.h will work for non-backend
compiles. We would much rather you were including postgres_fe.h than c.h
directly. Having said that, there is not and never will be a guarantee
that everything that postgres_fe.h declares is immutable, and that
certainly applies to pg_config.h in particular. There's a reason why
libpq doesn't include that into its public headers ...

>> Slonik used to include postgre_fe.h but back in 2011 or so we stopped doing
>> so because it was causing issues (I think on win32 builds)

> That seems like something we ought to consider fixing, but obviously
> we'd need more details.

Indeed. But I suspect the core of it is going to be that clients of
postgres_fe.h are expected to be linking in libpgport.a ...

regards, tom lane