Alvaro Herrera <alvhe...@commandprompt.com> wrote: > I think that would also solve a concern that I had, which is that > we were starting to include relcache.h (and perhaps other headers > as well, but that's the one that triggered it for me) a bit too > liberally, so +1 from me. Unfortunately, what I proposed doesn't solve that for relcache.h, although it does eliminate lock.h from almost everywhere and htup.h from everywhere. (The latter seemed to be left over from an abandoned approach, and was no longer needed in predicate.h in any event.) Most of the functions in predicate.c take a Relation as a parameter. I could split out the function prototypes for those which *don't* use it to a separate .h file if you think it is worthwhile. The functions would be: void InitPredicateLocks(void); Size PredicateLockShmemSize(void); void RegisterSerializableTransaction(const Snapshot snapshot); void ReleasePredicateLocks(const bool isCommit); void PreCommit_CheckForSerializationFailure(void); The files where these are used are: src/backend/storage/ipc/ipci.c src/backend/utils/time/snapmgr.c src/backend/utils/resowner/resowner.c src/backend/access/transam/xact.c So any of these files which don't already include relcache.h could remain without it if we make this split. Is there an easy way to check which might already include it? Is it worth adding one more .h file to avoid including relcache.h and snapshot.h in these four files? Let me know -- I'm happy to arrange this any way people feel is most appropriate. I have a profound appreciation for the organization of this code, and want to maintain it, even if I don't possess the perspective to know how to best do so. The respect comes from developing this patch -- every time I gave my manager an estimate of how long it would take to do something, I found it actually took about one-third of that time -- and it was entirely due to the organization and documentation of the code. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers