On Fri, Aug 14, 2015 at 2:40 PM, Andres Freund <and...@anarazel.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
