validator finds the function to be okay,
    it should just return.  If it finds an error, it should report that
    via the normal <function>ereport()</function> error reporting mechanism.
    Throwing an error will force a transaction rollback and thus prevent
    the incorrect function definition from being committed.
   </para>

   <para>
    Validator functions should typically honor the <xref
    linkend="guc-check-function-bodies"/> parameter: if it is turned off then
    any expensive or context-sensitive checking should be skipped.  If the
    language provides for code execution at compilation time, the validator
    must suppress checks that would induce such execution.  In particular,
    this parameter is turned off by <application>pg_dump</application> so that it can
    load procedural language functions without worrying about side effects or
    dependencies of the function bodies on other database objects.
    (Because of this requirement, the call handler should avoid
    assuming that the validator has fully checked the function.  The point
    of having a validator is not to let the call handler omit checks, but
    to notify the user immediately if there are obvious errors in a
    <command>CREATE FUNCTION</command> command.)
    While the choice of exactly what to check is mostly left to the
    discretion of the validator function, note that the core
    <command>CREATE FUNCTION</command> code only executes <literal>SET</literal> clauses
    attached to a function when <varname>check_function_bodies</varname> is on.
    Therefore, checks whose results might be affected by GUC parameters
    definitely should be skipped when <varname>check_function_bodies</varname> is
    off, to avoid false failures when restoring a dump.
   </para>

   <para>
    If an inline handler is provided by a procedural language, it
    must be declared as a function taking a single parameter of type
    <type>internal</type>.  The inline handler's result is ignored, so it is
    customarily declared to return <type>void</type>.  The inline handler
    will be called when a <command>DO</command> statement is executed specifying
    the procedural language.  The parameter actually passed is a pointer
    to an <structname>InlineCodeBlock</structname> struct, which contains information
    about the <command>DO</command> statement's parameters, in particular the
    text of the anonymous code block to be executed.  The inline handler
    should execute this code and return.
   </para>

   <para>
    It's recommended that you wrap all these function declarations,
    as well as the <command>CREATE LANGUAGE</command> command itself, into
    an <firstterm>extension</firstterm> so that a simple <command>CREATE EXTENSION</command>
    command is sufficient to install the language.  See
    <xref linkend="extend-extensions"/> for information about writing
    extensions.
   </para>

   <para>
    The procedural languages included in the standard distribution
    are good references when trying to write your own language handler.
    Look into the <filename>src/pl</filename> subdirectory of the source tree.
    The <xref linkend="sql-createlanguage"/>
    reference page also has some useful details.
   </para>

 </chapter>