Обсуждение: Move MAXIMUM_ALIGNOF definition to c.h

As suggested at [0], we can move the computation of MAXIMUM_ALIGNOF from 
configure.ac and meson.build to c.h.  This eliminates code duplication. 
(For example, the AIX patch contemplates some changes, so it would be 
good to make those in only one place.)  Also, it used to be more 
complicated, but now it's not really a computation anymore, it's just a 
#define and two static assertions, so it's just much easier and natural 
this way.  (For example, doing a symbol lookup on MAXIMUM_ALIGNOF will 
take you to a place with useful context, instead of to pg_config.h.)

The only trick is that the there are some ordering problems in c.h. 
MAXIMUM_ALIGNOF is used in the definition of the int128, which comes 
very early, before the alignment handling.  I moved the int128 stuff to 
later in the file, near other types with alignment dependencies.  (If 
you look closer, you will find other opportunities for a more 
comprehensive reshuffling in c.h, but maybe that should be a separate 
project.)

[0]: 
https://www.postgresql.org/message-id/CA%2BhUKGLQUivg-NC7dHdbRAPmG0Hapg1gGnygM5KgDfDM2a_TMg%40mail.gmail.com

Peter Eisentraut <peter@eisentraut.org> writes:
> As suggested at [0], we can move the computation of MAXIMUM_ALIGNOF from 
> configure.ac and meson.build to c.h.  This eliminates code duplication. 
> (For example, the AIX patch contemplates some changes, so it would be 
> good to make those in only one place.)

I looked at this but am pretty underwhelmed.  Yes, it replaces two
copies of that logic with one, but said logic is so trivial that
that's not a big win.  Moreover, I'm finding it hard to believe
that we'll ever need to change that logic again --- the plain
max-of-two-alignment-measurements logic is the way it had been
for a long time and will be again after the AIX patch lands.  I can't
foresee a future platform where it'd need to be any different.

In exchange for that simplification, we are taking a computation
that currently is done once per configure/meson-setup step, and
instead computing it during each .c file build.  I imagine that
at least the autoconf implementation is more expensive than
what the C compiler would need to do, but repeating it over and
over again will surely end up costing more.

So this doesn't seem like a good change to me.

            regards, tom lane