Обсуждение: documentation inconsistent re: alignment

Hi,

The documentation for CREATE TYPE has this to say about alignment:

"The alignment parameter specifies the storage alignment required for the
data type. The allowed values equate to alignment on 1, 2, 4, or 8 byte
boundaries."

... while the documentation for pg_type has:

    "c = char alignment, i.e., no alignment needed.
    s = short alignment (2 bytes on most machines).
    i = int alignment (4 bytes on most machines).
    d = double alignment (8 bytes on many machines, but by no means all)."

so, in 2019, are the alignments weaselly and variable, or are they 1,2,4,8?

Regards,
-Chap

Chapman Flack <chap@anastigmatix.net> writes:
> The documentation for CREATE TYPE has this to say about alignment:

> "The alignment parameter specifies the storage alignment required for the
> data type. The allowed values equate to alignment on 1, 2, 4, or 8 byte
> boundaries."

> ... while the documentation for pg_type has:

>     "c = char alignment, i.e., no alignment needed.
>     s = short alignment (2 bytes on most machines).
>     i = int alignment (4 bytes on most machines).
>     d = double alignment (8 bytes on many machines, but by no means all)."

> so, in 2019, are the alignments weaselly and variable, or are they 1,2,4,8?

Probably the statement in CREATE TYPE is too strong.  There are, I
believe, still machines in the buildfarm where maxalign is just 4.

            regards, tom lane

On 10/20/19 14:47, Tom Lane wrote:
> Chapman Flack <chap@anastigmatix.net> writes:
>> data type. The allowed values equate to alignment on 1, 2, 4, or 8 byte
>> boundaries."
>> ... while the documentation for pg_type has:
>>     "c = char alignment, i.e., no alignment needed.
>>     s = short alignment (2 bytes on most machines).
>>     i = int alignment (4 bytes on most machines).
>>     d = double alignment (8 bytes on many machines, but by no means all)."
> 
> Probably the statement in CREATE TYPE is too strong.  There are, I
> believe, still machines in the buildfarm where maxalign is just 4.

So just closing the circle on this, the low-down seems to be that
the alignments called s, i, and d (by pg_type), and int2, int4, and
double (by CREATE TYPE) refer to the machine values configure picks
for ALIGNOF_SHORT, ALIGNOF_INT, and ALIGNOF_DOUBLE, respectively.
And while configure also defines an ALIGNOF_LONG, and there are
LONGALIGN macros in c.h that use it, that one isn't a choice when
creating a type, presumably because it's never been usefully different
on any interesting platform?

Regards,
-Chap

Chapman Flack <chap@anastigmatix.net> writes:
> On 10/20/19 14:47, Tom Lane wrote:
>> Probably the statement in CREATE TYPE is too strong.  There are, I
>> believe, still machines in the buildfarm where maxalign is just 4.

> So just closing the circle on this, the low-down seems to be that
> the alignments called s, i, and d (by pg_type), and int2, int4, and
> double (by CREATE TYPE) refer to the machine values configure picks
> for ALIGNOF_SHORT, ALIGNOF_INT, and ALIGNOF_DOUBLE, respectively.

Right.

> And while configure also defines an ALIGNOF_LONG, and there are
> LONGALIGN macros in c.h that use it, that one isn't a choice when
> creating a type, presumably because it's never been usefully different
> on any interesting platform?

The problem with "long int" is that it's 32 bits on some platforms
and 64 bits on others, so it's not terribly useful as a basis for
a user-visible SQL type.  That's why it's not accounted for in the
typalign options.  I think ALIGNOF_LONG is just there for completeness'
sake --- it doesn't look to me like we actually use that, or LONGALIGN,
anyplace.

            regards, tom lane