Re: Raising our compiler requirements for 9.6

On Fri, Aug 14, 2015 at 2:40 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> To pick up on the general discussion and on the points you made here:
>
> I actually think the split came out to work far better than I'd
> anticipated. Having a slimmed-down version of lock.h for code that just
> needs to declare/pass lockmode parameters seems to improve our layering
> considerably. I got round to Alvaro's and Roberts position that
> removing lock.h from namespace.h and heapam.h would be a really nice
> improvemen on that front.
>
> Attached is a WIP patch to that end. After the further changes only few
> headers still have to include lock.h and they're pretty firmly in the
> backend-only territory. It also allows to remove the uglyness of passing
> around LOCKMODE as an int in parserOpenTable().

Yes, I like this.

> Imo lockdefs.h should be updated to describe that it contains the part
> of the lock infrastructure needed by indirect users of lock.h
> infrastructure, and that that currently unfortunately may include some
> frontend programs.

Sure.

> I *also* think that removing lwlock.h from lock.h would be a good
> idea. In my opinion it's a bad idea to pointlessly expose so much
> low-level things to the wider world, even if it's only needed by
> relatively low level things. Given that dependent macros are in
> lwlock.h, it seems pretty sane to move LockHash* there too.

Hmm. I dunno, lwlock.h is a pretty hideous layering violation as it
is. I'd like to find a way to make that better, not worse.

> We could additionally move all but LOCKMETHODID, LockTagType,
> LockAcquire*(), LockRelease() and probably one or two more to
> lock_internals.h (although I'd maybe rather name it lock_details?). I
> think it'd be an improvement, although possibly not a tremendous one
> given how many places it's likely going to be included from.

What benefit would we get out of this?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company