Re: pgsql: Allow more include files to be compiled in their own by adding m
От | Tom Lane |
---|---|
Тема | Re: pgsql: Allow more include files to be compiled in their own by adding m |
Дата | |
Msg-id | 11646.1314846921@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: Allow more include files to be compiled in their own by adding m (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: pgsql: Allow more include files to be
compiled in their own by adding m
|
Список | pgsql-committers |
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
В списке pgsql-committers по дате отправления: