be compiled before it is referenced
     in a <command>CREATE
     FUNCTION</command> command.  See <xref linkend="dfunc"/> for additional
     information.
    </para>
   </note>

   <indexterm zone="xfunc-c-dynload">
    <primary>magic block</primary>
   </indexterm>
   <indexterm zone="xfunc-c-dynload">
    <primary><literal>PG_MODULE_MAGIC</literal></primary>
   </indexterm>

   <para>
    To ensure that a dynamically loaded object file is not loaded into an
    incompatible server, <productname>PostgreSQL</productname> checks that the
    file contains a <quote>magic block</quote> with the appropriate contents.
    This allows the server to detect obvious incompatibilities, such as code
    compiled for a different major version of
    <productname>PostgreSQL</productname>. To include a magic block,
    write this in one (and only one) of the module source files, after having
    included the header <filename>fmgr.h</filename>:

<programlisting>
PG_MODULE_MAGIC;
</programlisting>
or
<programlisting>
PG_MODULE_MAGIC_EXT(<replaceable>parameters</replaceable>);
</programlisting>
   </para>

   <para>
    The <literal>PG_MODULE_MAGIC_EXT</literal> variant allows the specification
    of additional information about the module; currently, a name and/or a
    version string can be added.  (More fields might be allowed in future.)
    Write something like this:

<programlisting>
PG_MODULE_MAGIC_EXT(
    .name = "my_module_name",
    .version = "1.2.3"
);
</programlisting>

    Subsequently the name and version can be examined via
    the <function>pg_get_loaded_modules()</function> function.
    The meaning of the version string is not restricted
    by <productname>PostgreSQL</productname>, but use of semantic versioning
    rules is recommended.
   </para>

   <para>
    After it is used for the first time, a dynamically loaded object
    file is retained in memory.  Future calls in the same session to
    the function(s) in that file will only incur the small overhead of
    a symbol table lookup.  If you need to force a reload of an object
    file, for example after recompiling it, begin a fresh session.
   </para>

   <indexterm zone="xfunc-c-dynload">
    <primary>_PG_init</primary>
   </indexterm>
   <indexterm zone="xfunc-c-dynload">
    <primary>library initialization function</primary>
   </indexterm>

   <para>
    Optionally, a dynamically loaded file can contain an initialization
    function.  If the file includes a function named
    <function>_PG_init</function>, that function will be called immediately after
    loading the file.  The function receives no parameters and should
    return void.  There is presently no way to unload a dynamically loaded file.
   </para>

  </sect2>

   <sect2 id="xfunc-c-basetype">
    <title>Base Types in C-Language Functions</title>

    <indexterm zone="xfunc-c-basetype">
     <primary>data type</primary>
     <secondary>internal organization</secondary>
    </indexterm>

    <para>
     To know how to write C-language functions, you need to know how
     <productname>PostgreSQL</productname> internally represents base
     data types and how they can be passed to and from functions.
     Internally, <productname>PostgreSQL</productname> regards a base
     type as a <quote>blob of memory</quote>.  The user-defined
     functions that you define over a type in turn define the way that
     <productname>PostgreSQL</productname> can operate on it.  That
     is, <productname>PostgreSQL</productname> will only store and
     retrieve the data from disk and use your user-defined functions
     to input, process, and output the data.
    </para>

    <para>
     Base types can have one of three internal formats:

     <itemizedlist>
      <listitem>
       <para>
        pass by value, fixed-length
       </para>
      </listitem>
      <listitem>
       <para>
        pass by reference, fixed-length
       </para>
      </listitem>
      <listitem>
       <para>
        pass by reference,