<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>