documentation inconsistent re: alignment

Started by Chapman Flackover 6 years ago4 messages
#1Chapman Flack
chap@anastigmatix.net

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

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Chapman Flack (#1)
Re: documentation inconsistent re: alignment

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

#3Chapman Flack
chap@anastigmatix.net
In reply to: Tom Lane (#2)
Re: documentation inconsistent re: alignment

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

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Chapman Flack (#3)
Re: documentation inconsistent re: alignment

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