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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers