Re: [COMMITTERS] pgsql: Clean up the #include mess a little.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Greg Stark <stark(at)mit(dot)edu>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Clean up the #include mess a little.
Date: 2011-09-05 15:59:22
Message-ID: 8023.1315238362@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)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

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Bruce Momjian 2011-09-05 17:25:17 pgsql: Document that contrib/pgtrgm only processes ASCII alphanumeric
Previous Message Bruce Momjian 2011-09-05 15:56:03 Re: 'literal' for numbers

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2011-09-05 16:30:09 Re: WIP: Fast GiST index build
Previous Message Bruce Momjian 2011-09-05 15:56:34 Re: [GENERAL] pg_upgrade problem