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 through
    <command>CREATE FUNCTION</command>.  Typical checks then include verifying
    that the function's argument and result types are supported by the
    language, and that the function's body is syntactically correct
    in the language.  If the 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