Re: Headers dependencies cleanup - Mailing list pgsql-patches

From Tom Lane
Subject Re: Headers dependencies cleanup
Date
Msg-id 13792.1207407921@sss.pgh.pa.us
Whole thread Raw
In response to Re: Headers dependencies cleanup  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Headers dependencies cleanup  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
List pgsql-patches
Bruce Momjian <bruce@momjian.us> writes:
> Zdenek Kotala wrote:
>> bufpage.h includes bufmgr.h, but bufpage.h does not require any definition from
>> bufmgr.h. I think this dependency is there for long time.

> My scripts should have found this issue, see
> src/tools/pginclude/pgrminclude.

Looking over the file more closely, I disagree with Zdenek's claim
anyway.  Even though the file could physically be scanned without
having included bufmgr.h first, many of the macros it defines can't
be used without bufmgr.h, and so that file really is a prerequisite.
If we removed the include here it would just have to pop up in
calling .c files.  Anyplace that that was solely because of calling
one of the macros defined by bufpage.h, rather than explicitly using
anything from bufmgr.h, I claim it'd be wrong.

This example makes me question using scripts for this type of
maintenance, though, as it's not clear that a does-it-compile test
would understand macro dependencies.

It's probably true that we've let the header inclusions in storage/
and access/ get a bit spaghetti-ish.  But I think that if we're going
to do something about it, focusing on one or two files is not the
way to start.  What we need is for someone to go through all those
files and propose a clear layering of them.  This will very likely
involve having to move some declarations around, when we realize
something got put in a poorly chosen place.

            regards, tom lane

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Headers dependencies cleanup
Next
From: Tom Lane
Date:
Subject: Re: Headers dependencies cleanup