Re: Decoupling our alignment assumptions about int64 and double

I wrote:
> I think this might be about ready to go, unless somebody has
> a better idea than 'l' for the catalog representation of
> TYPALIGN_INT64.

I realized that there is more to consider here than we'd thought.
In particular, while we've mainly worried about what happens with
system catalog row layout, the change I've proposed here very
likely changes row layout in user tables, if we are on a platform
where TYPALIGN_INT64 != TYPALIGN_DOUBLE. So this is a pg_upgrade
breaking change for such platforms.

Maybe this is another reason to decide that AIX isn't worth
re-supporting: if there are any AIX users out there who still care,
the prospect of a forced dump-and-reload might be enough to convince
them that they might as well migrate to a more modern platform while
they are at it. Not sure.

If we do want to go forward with this, it would make sense to
adjust pg_control to store MAXALIGN, TYPALIGN_DOUBLE, and
TYPALIGN_INT64 separately, instead of

/*
* This data is used to check for hardware-architecture compatibility of
* the database and the backend executable. We need not check endianness
* explicitly, since the pg_control version will surely look wrong to a
* machine of different endianness, but we do need to worry about MAXALIGN
* and floating-point format. (Note: storage layout nominally also
* depends on SHORTALIGN and INTALIGN, but in practice these are the same
* on all architectures of interest.)
*
* Testing just one double value is not a very bulletproof test for
* floating-point compatibility, but it will catch most cases.
*/
uint32 maxAlign; /* alignment requirement for tuples */
double floatFormat; /* constant 1234567.0 */
#define FLOATFORMAT_VALUE 1234567.0

(Given that we've now pretty much locked in on IEEE float format,
I suspect floatFormat isn't pulling its weight anymore, but
perhaps that's a separate discussion.)

regards, tom lane