On Fri, Aug 7, 2015 at 1:11 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2015-08-07 12:30:04 -0400, Robert Haas wrote:
>> It may not be included from any IN CORE frontend code, but that is not
>> the same thing as saying it's not included from any frontend code at
>> all. For example, EDB has code that includes namespace.h in frontend
>> code. That compiled before this commit; now it doesn't.
>
> Nothing in namespace.h seems to be of any possible use for frontend
> code. If there were possible use-cases I'd be inclined to agree, but you
> obvoiusly can't use any of the functions, the structs and the guc make
> no sense either. So I really don't why we should cater for that?
>
> I think the likelihood of actually breaking correct working extension
> code that uses namespace.h that'd be broken if we removed lock.h from
> namespace.h is an order of magnitude bigger than the possible impact on
> frontend code.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company