such as a path name to a file, or anything else that tells the call handler
    what to do in detail.
   </para>

   <para>
    Often, the same function is called many times per SQL statement.
    A call handler can avoid repeated lookups of information about the
    called function by using the
    <structfield>flinfo-&gt;fn_extra</structfield> field.  This will
    initially be <symbol>NULL</symbol>, but can be set by the call handler to point at
    information about the called function.  On subsequent calls, if
    <structfield>flinfo-&gt;fn_extra</structfield> is already non-<symbol>NULL</symbol>
    then it can be used and the information lookup step skipped.  The
    call handler must make sure that
    <structfield>flinfo-&gt;fn_extra</structfield> is made to point at
    memory that will live at least until the end of the current query,
    since an <structname>FmgrInfo</structname> data structure could be
    kept that long.  One way to do this is to allocate the extra data
    in the memory context specified by
    <structfield>flinfo-&gt;fn_mcxt</structfield>; such data will
    normally have the same lifespan as the
    <structname>FmgrInfo</structname> itself.  But the handler could
    also choose to use a longer-lived memory context so that it can cache
    function definition information across queries.
   </para>

   <para>
    When a procedural-language function is invoked as a trigger, no arguments
    are passed in the usual way, but the
    <structname>FunctionCallInfoBaseData</structname>'s
    <structfield>context</structfield> field points at a
    <structname>TriggerData</structname> structure, rather than being <symbol>NULL</symbol>
    as it is in a plain function call.  A language handler should
    provide mechanisms for procedural-language functions to get at the trigger
    information.
   </para>

   <para>
    A template for a procedural-language handler written as a C extension is
    provided in <literal>src/test/modules/plsample</literal>.  This is a
    working sample demonstrating one way to create a procedural-language
    handler, process parameters, and return a value.
   </para>

   <para>
    Although providing a call handler is sufficient to create a minimal
    procedural language, there are two other functions that can optionally
    be provided to make the language more convenient to use.  These
    are a <firstterm>validator</firstterm> and an
    <firstterm>inline handler</firstterm>.  A validator can be provided
    to allow language-specific checking to be done during
    <xref linkend="sql-createfunction"/>.
    An inline handler can be provided to allow the language to support
    anonymous code blocks executed via the <xref linkend="sql-do"/> command.
   </para>

   <para>
    If a validator is provided by a procedural language, it
    must be declared as a function taking a single parameter of type
    <type>oid</type>.  The validator's result is ignored, so it is customarily
    declared to return <type>void</type>.  The validator will be called at
    the end of a <command>CREATE FUNCTION</command> command that has created
    or updated a function written in the procedural language.
    The passed-in OID is the OID of the function's <classname>pg_proc</classname>
    row.  The validator must fetch this row in the usual way, and do
    whatever checking is appropriate.
    First, call <function>CheckFunctionValidatorAccess()</function> to diagnose
    explicit calls to the validator that the user could not achieve