Skip site navigation (1) Skip section navigation (2)

Re: pgsql: Allow more include files to be compiled in their own by adding m

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Allow more include files to be compiled in their own by adding m
Date: 2011-09-01 03:15:21
Message-ID: 11646.1314846921@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-committers
Bruce Momjian <bruce(at)momjian(dot)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

In response to

Responses

pgsql-committers by date

Next:From: Tom LaneDate: 2011-09-01 04:20:31
Subject: pgsql: Further repair of eqjoinsel ndistinct-clamping logic.
Previous:From: Bruce MomjianDate: 2011-09-01 02:08:24
Subject: Re: pgsql: Allow more include files to be compiled in their own by adding m

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group