On 2015-08-07 20:16:20 -0400, Noah Misch wrote:
> I agree that lock.h offers little to frontend code. Headers that the
> lockdefs.h patch made usable in the frontend, particularly genam.h and hash.h,
> are no better.
It's not that simple. Those two, and tuptoaster.h, are actually somewhat
validly included by frontend code via the rmgr descriptor routines.
> The lock.h/lockdefs.h unprincipled split would do more harm
> than letting frontends continue to pull in lock.h.
Why? Consider what happens when lock.h/c gets more complicated and
e.g. grows some atomics. None of the frontend code should see that, and
it's not much effort to keep it that way. Allowing client code to see
LOCKMODE isn't something that's going to cause any harm.
> On another note, I'm perplexed by the high speed commits from this thread.
> Commit de6fd1c landed just 191 minutes after you posted the first version of
> its patch. Now lockdefs.h is committed, right in the middle of discussing it.
Hm. We'd essentially decided what we're going to do about the inline
stuff weeks ago, so I don't feel particularly bad pushing it quickly. A
lot of platform dependent stuff like this is going to have some
iterations to deal with compilers you don't have access to. The only
reason I committed the lockdefs.h split relatively quickly is that I
wanted to get the buildfarm green to see wether there are other problems
hiding behind the linker error. Which does, so far, not appear to be the
case.
Greetings,
Andres Freund