Re: Raising our compiler requirements for 9.6

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Raising our compiler requirements for 9.6
Date: 2015-08-15 03:08:52
Message-ID: CA+TgmobhpxKMki=Hfk8_Mo+1StN2A3qjkph4CXH0=gefb8Sg4g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-08-15 03:55:30 Re: [RFC] allow 'semester' in functions EXTRACT, DATE_PART, TO_CHAR and so on.
Previous Message Robert Haas 2015-08-15 03:04:43 Re: [RFC] allow 'semester' in functions EXTRACT, DATE_PART, TO_CHAR and so on.