Tom Lane napsal(a):
Bruce Momjian <[EMAIL PROTECTED]> 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

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.


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.


PS: Is there any reason to do not start to use inline functions instead of macros in some cases?

Sent via pgsql-patches mailing list (
To make changes to your subscription:

Reply via email to