Re: Raising our compiler requirements for 9.6

On 2015-07-02 11:46:25 -0400, Robert Haas wrote:
> In the case of static inline, the main problem with the status quo
> AFAICS is that you have to do a little dance any time you'd otherwise
> use a static inline function (for those following along at home, "git
> grep INCLUDE_DEFINITIONS src/include" to see how this is done).
> Now,
> it is obviously the case that the first time somebody has to do this
> dance, they will be somewhat inconvenienced, but once you know how to
> do it, it's not incredibly complicated.

I obviously know the schema (having introduced it in pg), but I think
the costs are actually rather significant. It makes development more
complex, it makes things considerably harder to follow, and it's quite
annoying to test (manually redefine PG_USE_INLINE, recompile whole
tree).

Several times people also argued against using inlines with that trick
because it's slowing down older platforms.

> So, just to play the devil's advocate here, who really cares?

I consider our time one of the most scarce resources around.

> I'd consider an argument for adopting one of these features to be much
> stronger if were accompanied by arguments like:
>
> - If we require feature X, we can reduce the size of the generated
> code and improve performance.

Converting some of the bigger macros (I tested fastgetattr) to inliens,
actually does both.

See also http://archives.postgresql.org/message-id/4407.1435763473%40sss.pgh.pa.us

Now, all that is possible with the INCLUDE_DEFINITIONS stuff, but it
makes it considerably more expensive time/complexity wise.

> If everybody else here says "working around the lack of feature X is
> too much of a pain in the butt and we want to adopt it purely too make
> development easier", I'm not going to sit here and try to fight the
> tide. But I personally don't find such arguments all that exciting.

I find that an odd attitude.

> I think // comments are a not something we should adopt, because one
> style is better than two

I don't particularly care about // comments either. They do have the
advantage of allowing three more characters of actual content in one
line comments ...

Greetings,

Andres Freund