<filename>contrib/hstore/hstore_subs.c</filename>.
Additional information appears in
<xref linkend="sql-createtype-array"/> below.
</para>
<para>
While the details of the new type's internal representation are only
known to the I/O functions and other functions you create to work with
the type, there are several properties of the internal representation
that must be declared to <productname>PostgreSQL</productname>.
Foremost of these is
<replaceable class="parameter">internallength</replaceable>.
Base data types can be fixed-length, in which case
<replaceable class="parameter">internallength</replaceable> is a
positive integer, or variable-length, indicated by setting
<replaceable class="parameter">internallength</replaceable>
to <literal>VARIABLE</literal>. (Internally, this is represented
by setting <literal>typlen</literal> to -1.) The internal representation of all
variable-length types must start with a 4-byte integer giving the total
length of this value of the type. (Note that the length field is often
encoded, as described in <xref linkend="storage-toast"/>; it's unwise
to access it directly.)
</para>
<para>
The optional flag <literal>PASSEDBYVALUE</literal> indicates that
values of this data type are passed by value, rather than by
reference. Types passed by value must be fixed-length, and their internal
representation cannot be larger than the size of the <type>Datum</type> type
(4 bytes on some machines, 8 bytes on others).
</para>
<para>
The <replaceable class="parameter">alignment</replaceable> parameter
specifies the storage alignment required for the data type. The
allowed values equate to alignment on 1, 2, 4, or 8 byte boundaries.
Note that variable-length types must have an alignment of at least
4, since they necessarily contain an <type>int4</type> as their first component.
</para>
<para>
The <replaceable class="parameter">storage</replaceable> parameter
allows selection of storage strategies for variable-length data
types. (Only <literal>plain</literal> is allowed for fixed-length
types.) <literal>plain</literal> specifies that data of the type
will always be stored in-line and not compressed.
<literal>extended</literal> specifies that the system will first
try to compress a long data value, and will move the value out of
the main table row if it's still too long.
<literal>external</literal> allows the value to be moved out of the
main table, but the system will not try to compress it.
<literal>main</literal> allows compression, but discourages moving
the value out of the main table. (Data items with this storage
strategy might still be moved out of the main table if there is no
other way to make a row fit, but they will be kept in the main
table preferentially over <literal>extended</literal> and
<literal>external</literal> items.)
</para>
<para>
All <replaceable class="parameter">storage</replaceable> values other
than <literal>plain</literal> imply that the functions of the data type
can handle values that have been <firstterm>toasted</firstterm>, as described
in <xref linkend="storage-toast"/> and <xref linkend="xtypes-toast"/>.
The specific other value given merely determines the default TOAST
storage strategy for columns of a toastable data type; users can pick
other strategies for individual columns using <literal>ALTER TABLE
SET STORAGE</literal>.
</para>
<para>
The <replaceable class="parameter">like_type</replaceable> parameter
provides an alternative method for specifying the basic representation
properties of a data type: copy them from some existing type. The values of
<replaceable class="parameter">internallength</replaceable>,
<replaceable class="parameter">passedbyvalue</replaceable>,
<replaceable class="parameter">alignment</replaceable>, and
<replaceable class="parameter">storage</replaceable>