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

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 (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-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

pgsql-hackers by date

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

pgsql-committers by date

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

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