Re: [HACKERS] 64-bit hashjoins

Now that the XXXALIGN() macros are supposed to reflect reality instead
of arbitrary decisions ;-), I have revised memutils.h to eliminate all
that "#if defined(platform)" cruft.  Instead, the actual alignment values
being used by the compiler are discovered by the configure script.
This should make things considerably more robust on machines where the
alignment requirement of the basic C datatypes is not the same as their
size.  In particular, we should no longer see any problems with the
struct declarations in include/catalog/pg_*.h not matching the way that
the tuple access code lays out the tuples.

WARNING: if you are on a machine where this actually makes a difference,
you may have to do an initdb after your next CVS update, because the
padding in your tables may change.  I think this would be most likely
to affect tables containing float8 or int8 data --- some machines
require 8-byte alignment of doubles, but some don't, and the padding of
float data will now reflect that.

Right now the system is still making an assumption that I consider
crufty: it uses typalign = 'd' (ie, DOUBLE alignment) for int8 data
(long long int).  As things stand, this would only cause problems on
machines where long long actually has stronger alignment requirements
than double.  I've never heard of such a platform, but maybe they are
out there --- has anyone heard of one?  A more likely cause of trouble
is that if any int8 columns are ever added to system tables, the code
will risk failure unless int8 and double have exactly the same alignment
requirement (because the catalog structs could get laid out differently
than the tuple code would expect).

Is it worth adding a new typalign value specifically for int8, in order
to make the world safe for int8 columns in system tables?
        regards, tom lane