Re: Raising our compiler requirements for 9.6 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Raising our compiler requirements for 9.6
Date
Msg-id CA+Tgmobz1gh_y0BFE_yUpDkVQHhNAeTEAskX03dTgA8ayAVHMA@mail.gmail.com
Whole thread Raw
In response to Re: Raising our compiler requirements for 9.6  (Andres Freund <andres@anarazel.de>)
Responses Re: Raising our compiler requirements for 9.6  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Thu, Aug 6, 2015 at 11:34 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2015-08-06 12:29:15 -0300, Alvaro Herrera wrote:
>> Andres Freund wrote:
>>
>> > I had to split of three things: LOCKMASK, the individual lock levels and
>> > xl_standby_lock to be able to prohibit lock.h to be included by frontend
>> > code. lockdefs.h works for me, counter proposals?
>> >
>> > There weren't any places that needed additional lock.h includes.
>>
>> Ah, but that's because you cheated and didn't remove the include from
>> namespace.h ...
>
> Well, it's not included from frontend code, so I didn't see the need?
> Going through all the backend code and replacing lock.h by lockdefs.h
> and some other includes doesn't seem particularly beneficial to me.

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.

It turns out the fix is pretty simple: the code in question is
including namespace.h, but it doesn't need to.  So I can just remove
the include in this instance.  But I don't think it's always going to
be that simple.  A significant reduction in the number of headers that
can be compiled from frontend code WILL inconvenience extension
authors.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: 9.5 release notes
Next
From: Jesper Pedersen
Date:
Subject: Re: Reduce ProcArrayLock contention