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
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?
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
