Re: Raising our compiler requirements for 9.6

On 2015-08-07 14:48:43 -0400, Tom Lane wrote:
> Indeed, but the buildfarm results say that the set of such platforms is
> nearly empty.  It's very likely that a lot of third-party authors won't
> ever care if their code doesn't build on such platforms; certainly not
> nearly as much as they'll care if their code doesn't build *at all*,
> and they have no recourse except to modify the PG headers because they
> need some symbol that happens to be defined in a header that also has
> some lock-related junk.

I'm all for de-supporting platforms without working inlining support,
but if we do so, we should do it explicitly. Imo that's what it comes
down to.

It's imo more or less a happy optimization accident that apparently all
inlining supporting compilers never emit references from the contents of
static inline functions that aren't referenced.

There is one instance of code that tried to work around that:

#ifndef FRONTEND
#ifndef PG_USE_INLINE
extern MemoryContext MemoryContextSwitchTo(MemoryContext context);
#endif   /* !PG_USE_INLINE */
#if defined(PG_USE_INLINE) || defined(MCXT_INCLUDE_DEFINITIONS)
STATIC_IF_INLINE MemoryContext
MemoryContextSwitchTo(MemoryContext context)
{MemoryContext old = CurrentMemoryContext;
CurrentMemoryContext = context;return old;
}
#endif   /* PG_USE_INLINE || MCXT_INCLUDE_DEFINITIONS */
#endif   /* FRONTEND */

You re-added the #ifndef FRONTEND there in a9baeb361d635 referencing a
buildfarm failure. It seems to originally have been added in
7507b193bc54 referencing buildfarm member warthog which unfortunately
doesn't exist anymore...

> My point is simply that adding those #errors represents a large bet that
> the separation between frontend and backend headers is clean enough.
> I really doubt that it is, and I don't see anyone volunteering to put
> adequate time into fixing that right now.

I agree that there's a lot of work needed to make that separation
cleaner. I'm not so sure these files are relevantly often needed in
frontend cdoe.

> I'm afraid we'll put in ugly, hurried, piecemeal hacks in response to
> complaints.

I think we should leave them in for now. It's the beginning of the cycle
and imo the removal of lock.h from the headers where it was referenced
was a good step. We might find some more easy cases - the removal of
lock.h from tuptoaster.h and other headers included by frontend code imo
is a good thing.  If it proves to bothersome we can still take it out.

Andres