Tom Lane napsal(a):
> 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.
Yeah, I see it now. BufferGetPageSize and BufferGetPage macros uses macros from
bufmgr. But I think, They should be moved to the bufmgr.h where is better and
more logic place for them.
<snip>
> 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.
Yes, agree. I need also fix problem with pgxlogreset and design how to track
history (multi version) of structures related to upgrade (e.g. page layout ...).
I will look on it.
Zdenek
PS: Is there any reason to do not start to use inline functions instead of
macros in some cases?