On 2015-08-07 14:32:35 -0400, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > Well, I just work here, but it seems silly to me to reorgnize the > > headers so that you can include fewer definitions where necessary, but > > then not revise the existing headers to use the slimmed-down versions > > where possible. Yeah, somebody might have to adjust their #includes > > and that is annoying, but I don't think the cost of your new #error > > directives is going to be zero. > > I'm a bit concerned about that too; what it means is that any addition > of new #includes in backend header files carries a nontrivial risk of > breaking frontend code that used to be fine (at least on most platforms). > As an example, the proximate cause of the pademelon breakage was that > pg_resetxlog needs to #include tuptoaster.h to get TOAST_MAX_CHUNK_SIZE. > That was perfectly safe up till commit 2ef085d0e6960f50, when somebody > semi-randomly decided that it'd be a good idea to declare a function > taking a LOCKMODE argument in that header. > > 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. 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. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers