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 по дате отправления: