Robert Haas <robertmhaas@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
