Alvaro Herrera <alvherre@commandprompt.com> writes:
> I am not sure it is really feasible to build a complete graph for all
> headers. We have too many of them and too many dependencies.
Yeah, it's the "too many dependencies" aspect that is bothering me.
The only concrete idea I've come up with so far is that it'd be a good
idea to isolate certain primitive datatypes into their own group of
headers. We have a number of headers that are meant to be this sort
of animal already, eg storage/block.h, storage/relfilenode.h. But
(1) there's no clear distinction between these headers and ones like,
say, storage/smgr.h or storage/proc.h.
(2) other things that have become widely-used primitive datatypes,
such as TimestampTz, are declared in places that ideally ought to be
near the top of the #include hierarchy not the bottom.
So I think we could make some forward progress by moving all these
simple datatype declarations into a separate set of headers in their
own subdirectory of src/include/, perhaps "datatype". There would
be a hard and fast rule that no header in this set could depend on
anything beyond postgres.h and other members of the same set, so
that these headers clearly form the bottom level of the #include
hierarchy. Probably some of the stuff now in postgres.h could migrate
to this group too.
Eventually I'd like to see some fairly clear layering rules at the
header-directory level, like "storage/ is lower-level than commands/
so nothing in the former directory should include anything in the
latter". But achieving that is a long way off.
Of course, the problem with all of this is that making much progress
would be a large amount of work with relatively small concrete payoff.
Still, I'm starting to feel that we've got such a spaghetti-like mess
that we need to do something.
regards, tom lane
