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

From Andres Freund
Subject Re: Raising our compiler requirements for 9.6
Date
Msg-id 20150805120524.GB10262@awork2.anarazel.de
Whole thread Raw
In response to Re: Raising our compiler requirements for 9.6  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Raising our compiler requirements for 9.6  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 2015-08-04 16:55:12 -0400, Robert Haas wrote:
> On Tue, Aug 4, 2015 at 3:55 PM, Andres Freund <andres@anarazel.de> wrote:
> > On 2015-08-04 15:45:44 -0400, Tom Lane wrote:
> >> I'm not sure that there's any great urgency about changing the instances
> >> that exist now; the real point of this discussion is that we will allow
> >> new code to use static inlines in headers.
> >
> > I agree that we don't have to (and probably shouldn't) make the required
> > configure changes and change definitions.  But I do think some of the
> > current macro usage deserves to be cleaned up at some point. I,
> > somewhere during 9.4 or 9.5, redefined some of the larger macros into
> > static inlines and it both reduced the binary size and gave minor
> > performance benefits.
> 
> We typically recommend that people write their new code like the
> existing code.  If we say that the standards for new code are now
> different from old code in this one way, I don't think that's going to
> be very helpful to anyone.

I'm coming around to actually changing more code initially. While I
don't particularly buy the severity of the "make it look like existing
code" issue, I do think it'll be rather confusing to have code dependent
on PG_USE_INLINE when it's statically defined.

So unless somebody protests I'm going to prepare (and commit after
posting) a patch to rip out the bits of code that currently depend on
PG_USE_INLINE.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: more-helpful-izing a debug message
Next
From: Robert Haas
Date:
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive