Andres Freund <and...@anarazel.de> writes:
>> One approach is to avoid including lwlock.h/slot.h in frontend
>> code. That'll require some minor surgery and adding a couple includes,
>> but it doesn't look that bad.
> Patch doing that attached.
This seems kinda messy. Looking at the contents of lock.h, it seems like
getting rid of its dependency on lwlock.h is not really very appropriate,
because there is boatloads of other backend-only stuff in there. Why is
any frontend code including lock.h at all? If there is a valid reason,
should we refactor lock.h into two separate headers, one that is safe to
expose to frontends and one with the rest of the stuff?
Also, I think the reason for the #include is that lock.h has a couple
of macros that reference MainLWLockArray. The fact that you can omit
the #include lwlock.h is therefore only accidental: if we had done those
as static inline functions, this wouldn't work at all. So I think this
solution is not very future-proof either.
> As a consequence I think we should actually add a bunch of #ifdef
> FRONTEND #error checks in code we definitely do not want to included in
> frontend code. The attached patch so far adds a check to atomics.h,
> lwlock.h and s_lock.h.
I agree with that idea anyway.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
