Andres Freund wrote:
> > 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.
>
> > With that, indirect frontend lock.h inclusion will work fine.
>
> But there seems little reason trying to support doing so. It's not very
> hard to imagine that lock.c and by extension lock.h get more complicated
> in the future as it's already a scalability bottleneck. that very well
> might require including atomics, spinlocks and the like in lock.h.
I don't disagree with any of your points, but nevertheless I think the
split suggested by Noah is a good one (it's more principled than the one
you suggest, at any rate) and perhaps it would be a good compromise to
do both things in a fell swoop.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
