On 2015-08-07 14:32:35 -0400, Tom Lane wrote:
> 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.
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
