remainder of the
    value be returned. These macros provide more efficient access to
    parts of large values in the case where they have storage type
    <quote>external</quote>. (The storage type of a column can be specified using
    <literal>ALTER TABLE <replaceable>tablename</replaceable> ALTER
    COLUMN <replaceable>colname</replaceable> SET STORAGE
    <replaceable>storagetype</replaceable></literal>. <replaceable>storagetype</replaceable> is one of
    <literal>plain</literal>, <literal>external</literal>, <literal>extended</literal>,
     or <literal>main</literal>.)
    </para>

    <para>
     Finally, the version-1 function call conventions make it possible
     to return set results (<xref linkend="xfunc-c-return-set"/>) and
     implement trigger functions (<xref linkend="triggers"/>) and
     procedural-language call handlers (<xref
     linkend="plhandler"/>).  For more details
     see <filename>src/backend/utils/fmgr/README</filename> in the
     source distribution.
    </para>
   </sect2>

   <sect2 id="xfunc-c-code">
    <title>Writing Code</title>

    <para>
     Before we turn to the more advanced topics, we should discuss
     some coding rules for <productname>PostgreSQL</productname>
     C-language functions.  While it might be possible to load functions
     written in languages other than C into
     <productname>PostgreSQL</productname>, this is usually difficult
     (when it is possible at all) because other languages, such as
     C++, FORTRAN, or Pascal often do not follow the same calling
     convention as C.  That is, other languages do not pass argument
     and return values between functions in the same way.  For this
     reason, we will assume that your C-language functions are
     actually written in C.
    </para>

    <para>
     The basic rules for writing and building C functions are as follows:

     <itemizedlist>
      <listitem>
       <para>
        Use <literal>pg_config
        --includedir-server</literal><indexterm><primary>pg_config</primary><secondary>with user-defined C functions</secondary></indexterm>
        to find out where the <productname>PostgreSQL</productname> server header
        files are installed on your system (or the system that your
        users will be running on).
       </para>
      </listitem>

      <listitem>
       <para>
        Compiling and linking your code so that it can be dynamically
        loaded into <productname>PostgreSQL</productname> always
        requires special flags.  See <xref linkend="dfunc"/> for a
        detailed explanation of how to do it for your particular
        operating system.
       </para>
      </listitem>

      <listitem>
       <para>
        Remember to define a <quote>magic block</quote> for your shared library,
        as described in <xref linkend="xfunc-c-dynload"/>.
       </para>
      </listitem>

      <listitem>
       <para>
        When allocating memory, use the
        <productname>PostgreSQL</productname> functions
        <function>palloc</function><indexterm><primary>palloc</primary></indexterm> and <function>pfree</function><indexterm><primary>pfree</primary></indexterm>
        instead of the corresponding C library functions
        <function>malloc</function> and <function>free</function>.
        The memory allocated by <function>palloc</function> will be
        freed automatically at the end of each transaction, preventing
        memory leaks.
       </para>
      </listitem>

      <listitem>
       <para>
        Always zero the bytes of your structures using <function>memset</function>
        (or allocate them with <function>palloc0</function> in the first place).
        Even if you assign to each field of your structure, there might be
        alignment padding (holes in the structure) that contain
        garbage values.  Without this, it's difficult to
        support hash indexes or hash joins, as you must pick out only
        the significant bits of your data structure