Andres Freund <and...@anarazel.de> writes:
> On 2015-08-07 14:32:35 -0400, Tom Lane wrote:
>> Eventually I think we're going to have to spend some effort on making a
>> clearer separation between "front end safe" and "not front end safe"
>> header files. Until we do that, though, adding these #error directives
>> may just do more harm than good. We don't know which backend headers
>> are being used by third-party code, but we can be 100% sure it's more
>> than what's used by the frontend code in the core distribution.
> Right now the #errors are in only in places that'd also break without
> them, but only on the old platforms without inline support and in a more
> subtle way.
Indeed, but the buildfarm results say that the set of such platforms is
nearly empty. It's very likely that a lot of third-party authors won't
ever care if their code doesn't build on such platforms; certainly not
nearly as much as they'll care if their code doesn't build *at all*,
and they have no recourse except to modify the PG headers because they
need some symbol that happens to be defined in a header that also has
some lock-related junk.
My point is simply that adding those #errors represents a large bet that
the separation between frontend and backend headers is clean enough.
I really doubt that it is, and I don't see anyone volunteering to put
adequate time into fixing that right now. I'm afraid we'll put in
ugly, hurried, piecemeal hacks in response to complaints.
> I'm ok with getting lock.h from the list of headers where that's the
> case, done by removing lwlock.h from it, which I proposed that
> upthread. But then you objected to that approach.
Well, we're still discussing what's the best compromise.
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
