linkend="storage-toast">). You should do this even if the data are always
- too small to be compressed or stored externally because
- <productname>Postgres can save space on small data using
+ too small to be compressed or stored externally, because
+ <acronym>TOAST can save space on small data too, by reducing header
+ overhead.
To do this, the internal representation must follow the standard layout for
- variable-length data: the first four bytes must be an int32
- which is never accessed directly (customarily named vl_len_). You
+ variable-length data: the first four bytes must be a char[4]
+ field which is never accessed directly (customarily named
+ vl_len_). You
must use SET_VARSIZE() to store the size of the datum
in this field and VARSIZE() to retrieve it. The C
functions operating on the data type must always be careful to unpack any
to avoid some of the overhead of PG_DETOAST_DATUM. You can use
PG_DETOAST_DATUM_PACKED instead (customarily hidden by
defining a GETARG_DATATYPE_PP macro) and using the macros
- VARSIZE_ANY_EXHDR and VARDATA_ANY macros.
+ VARSIZE_ANY_EXHDR and VARDATA_ANY to access
+ a potentially-packed datum.
Again, the data returned by these macros is not aligned even if the data
type definition specifies an alignment. If the alignment is important you
must go through the regular PG_DETOAST_DATUM interface.
+
+ Older code frequently declares vl_len_ as an
+ int32 field instead of char[4]. This is OK as long as
+ the struct definition has other fields that have at least int32
+ alignment. But it is dangerous to use such a struct definition when
+ working with a potentially unaligned datum; the compiler may take it as
+ license to assume the datum actually is aligned, leading to core dumps on
+ architectures that are strict about alignment.
+
+
+
For further details see the description of the
command.
projects / postgresql.git / commitdiff