Hi,
On 2018-06-19 14:19:56 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2018-06-19 14:09:15 -0400, Tom Lane wrote:
> >> Hm. You could imagine adding something like
> >>
> >> #ifdef some-relevant-macro
> >> #error include ordering problem, c.h must come before system headers
> >> #endif
> >>
> >> near the head of c.h. But I'm not sure how we'd get full coverage.
> >> The case presumably would only occur for off-the-beaten-path headers
> >> (this particular mistake was <sys/stat.h>), and there are lots of those.
>
> > If we were ok with doing this in a very platform specific manner, we
> > probably could make the dependency fairly generic. I.e. glibc IIRC will
> > pretty much always end up including features.h, so we could check for
> > that (#ifdef _FEATURES_H). I'd suspect other C libraries have similar
> > things.
>
> It'd probably be good enough if the error detection worked with glibc's
> headers. Even if nobody noticed before a particular patch went in,
> the buildfarm would surely find it.
Then the _FEATURES_H check would work - just tested it locally, and it
triggers appropriately. Does tie us a bit to specific glibc versions,
but... Obvoiusly would need some comments explaining it
Are there arguments for doing this in postgres.h rather than c.h? I
can't immediately think of a case where it'd be ok for postgres_fe.h or
such to be included later. libpq-fe would be different, but that
doesn't include backend headers.
I think we shouldn't do this for v11, as it seems likely that some
extensions would be broken. While not hard to fix, that seems
unnecessary after beta1? Seems unlikely we'll introduce further cases
before new features are merged.
Greetings,
Andres Freund