Re: Moving of INT64_FORMAT to c.h

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Moving of INT64_FORMAT to c.h
Дата
Msg-id 28434.1414009890@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Moving of INT64_FORMAT to c.h  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Oct 22, 2014 at 4:12 PM, Steve Singer <steve@ssinger.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Moving of INT64_FORMAT to c.h
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: delta relations in AFTER triggers