Bruce Momjian <bruce@momjian.us> writes:
> Andrew Dunstan wrote:
>> I'm not sure I understand the point of it anyway.
> The idea is that include files should include all needed includes so
> they don't spill dependencies into files that use them.
I think that's an unwarranted expansion of the charter of what you're
doing. There are places where we intentionally do not pull in include
files that will be required if (and only if) one attempts to make use of
macros provided by a given header file. The first one that comes to
mind is in postgres_ext.h:
#define OID_MAX UINT_MAX
/* you will need to include <limits.h> to use the above #define */
but I believe there are others, and I don't want some mechanical process
second-guessing those decisions. I think the rule of "should compile on
its own" is okay, but I don't want that expanded to "every macro
provided by the file must be expandable with no further includes".
In the end, the point of what you are doing is to ensure that header
files can be included in any order. It is not to ensure some sort of
unclearly-defined closure rule about how many headers need be included
to make use of a particular facility.
regards, tom lane
