On Fri, Aug 7, 2015 at 2:27 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2015-08-07 14:15:58 -0400, Robert Haas wrote:
>> 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.
>
> So first your argument was that it broke stuff and now you want to break
> more?
>
> I am not really against removing removing lock.h from a few more places,
> but normally you were the one arguing against breaking working code by
> reorganizing headers when there's no really clear win. Removing lock.h
> from namespace.h and removing lwlock.h from lock.h will have a
> noticeably higher cost than what I committed and in contrast to the
> benefit of separating frontend code from backend implementation details
> (which caused linker errors) the only benefit will be a bit less code
> included.
Well, we can wait and see if we get any more complaints before doing
anything, if you like. We've got a year before any of this is going
to be released, so there's no rush. My point, which I think is valid,
is that if the set of #includes you need to compile your stuff
changes, that's easy to fix. If one of the #includes you need to
compile your stuff starts doing #error, you're hosed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
