Re: Decoupling our alignment assumptions about int64 and double

I wrote:
> Attached a v3 of the main patch (now again numbered 0001), plus
> new work in 0002 that adds the two new alignment values to
> pg_control and insists on a match before pg_upgrade'ing.

I've gotten cold feet about this whole idea, and no longer think
we should pursue it.  Aside from the problems already raised,
consider this: what would extensions do with existing int64-based
data types?  We don't have any provision for altering the typalign
of an existing type, and if we did it would imply doing table
rewrites (at least for cases where the change wasn't effectively
a no-op).  Worse, if such a type is created using "LIKE int8"
which has always been best practice, then whether it shows up
with align 'l' or 'd' in a new installation will depend on whether
you pg_upgrade'd or installed the extension fresh.  So that looks
like a mess waiting to happen.  Combine that with extensions that
manually set alignment = double, and never bother to update because
they can't change it and don't care anyway, and the inevitable end
result is that the 'l' and 'd' cases will be so randomly assigned
that there's not a meaningful difference after all.  Perhaps we
could have got away with such a change in the pre-pg_upgrade era,
but I think we cannot now.

If we want to re-support AIX, I think we're stuck with going back
to the old way of calculating MAXALIGN, and then re-instituting that
regression test that checked for unsafely-aligned catalog columns.
Bleah.  Still, as long as the regression test is accurate, it seems
like that'd be an annoyance not a major headache.

			regards, tom lane