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 to compute a hash.
        The planner also sometimes relies on comparing constants via
        bitwise equality, so you can get undesirable planning results if
        logically-equivalent values aren't bitwise equal.
       </para>
      </listitem>

      <listitem>
       <para>
        Most of the internal <productname>PostgreSQL</productname>
        types are declared in <filename>postgres.h</filename>, while
        the function manager interfaces
        (<symbol>PG_FUNCTION_ARGS</symbol>, etc.)  are in
        <filename>fmgr.h</filename>, so you will need to include at
        least these two files.  For portability reasons it's best to
        include <filename>postgres.h</filename> <emphasis>first</emphasis>,
        before any other system or user header files.  Including
        <filename>postgres.h</filename> will also include
        <filename>elog.h</filename> and <filename>palloc.h</filename>
        for you.
       </para>
      </listitem>

      <listitem>
       <para>
        Symbol names defined within object files must not conflict
        with each other or with symbols defined in the
        <productname>PostgreSQL</productname> server executable.  You
        will have to rename your functions or variables if you get
        error messages to this effect.
       </para>
      </listitem>
     </itemizedlist>
    </para>
   </sect2>

&dfunc;

   <sect2 id="xfunc-api-abi-stability-guidance">
    <title>Server API and ABI Stability Guidance</title>

    <para>
     This section contains guidance to authors of extensions and other server
     plugins about API and ABI stability in the
     <productname>PostgreSQL</productname> server.
    </para>

    <sect3 id="xfunc-guidance-general">
     <title>General</title>

     <para>
      The <productname>PostgreSQL</productname> server contains several
      well-demarcated APIs for server plugins, such as the function manager
      (<acronym>fmgr</acronym>, described in this chapter),
      <acronym>SPI</acronym> (<xref linkend="spi"/>), and various hooks
      specifically designed for extensions. These interfaces are carefully
      managed for long-term stability and compatibility. However, the entire
      set of global functions and variables in the server effectively
      constitutes the publicly usable API, and most of it was not designed
      with extensibility and long-term stability in mind.
     </para>

     <para>
      Therefore, while taking advantage of these interfaces is valid, the
      further one strays from the well-trodden path, the likelier it will be
      that one might encounter API or ABI compatibility issues at some point.
      Extension authors are encouraged to provide feedback about their
      requirements, so that over time, as new use patterns arise, certain
      interfaces can be considered more stabilized or new, better-designed
      interfaces can be added.
     </para>
    </sect3>

    <sect3 id="xfunc-guidance-api-compatibility">