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. 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