Re: pgsql: Allow more include files to be compiled in their own by adding m
От | Bruce Momjian |
---|---|
Тема | Re: pgsql: Allow more include files to be compiled in their own by adding m |
Дата | |
Msg-id | 201109011121.p81BLC220991@momjian.us обсуждение исходный текст |
Ответ на | Re: pgsql: Allow more include files to be compiled in their own by adding m (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-committers |
Tom Lane wrote: > 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". 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-committers по дате отправления: