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.
Greetings,
Andres Freund
