Re: Raising our compiler requirements for 9.6

On Fri, Aug 07, 2015 at 03:18:06PM +0200, Andres Freund wrote:
> On 2015-08-06 23:23:43 -0400, Noah Misch wrote:
> > On Thu, Aug 06, 2015 at 05:34:50PM +0200, Andres Freund wrote:
> > > On 2015-08-06 12:29:15 -0300, Alvaro Herrera wrote:
> > > > Andres Freund wrote:
> > > > > @@ -0,0 +1,56 @@
> > > > > +/*-------------------------------------------------------------------------
> > > > > + *
> > > > > + * lockdefs.h
> > > > > + * Frontend exposed parts of postgres' low level lock mechanism
> > > > > + *
> > > > > + * The split between lockdefs.h and lock.h is not very principled.
> > > >
> > > > No kidding!
> > >
> > > Do you have a good suggestion about the split? I wanted to expose the
> > > minimal amount necessary, and those were the ones.
> >
> > lock.h includes lwlock.h only for the benefit of the three LockHashPartition*
> > macros. Those macros are pieces of the lock.c implementation that cross into
> > proc.c, not pieces of the lock.c public API.
>
> I argued that way as well upthread. But I do think that Tom has a good
> point when he argues that frontend code really has no business including
> lock.h in total. The only reason we need it is because a few headers we
> need to include have LOCKMODE parameters and/or contain macros that
> refer to lock levels. So I do think that having a version that doesn't
> expose any unnecessary details is a good idea.

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. The lock.h/lockdefs.h unprincipled split would do more harm
than letting frontends continue to pull in lock.h. If we're going to do
something unprincipled, let's make it small, perhaps this:

--- a/src/include/storage/lock.h
+++ b/src/include/storage/lock.h
@@ -17,3 +17,5 @@
#include "storage/backendid.h"
+#ifndef FRONTEND
#include "storage/lwlock.h"
+#endif
#include "storage/shmem.h"

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.