Robert Haas <robertmh...@gmail.com> writes: > On Wed, Oct 22, 2014 at 4:12 PM, Steve Singer <st...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers