Tom Lane wrote: > Bruce Momjian <[email protected]> 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".
Agreed. > 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. OK. -- Bruce Momjian <[email protected]> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
