block
       (<link linkend="sql-do"><command>DO</command></link> command)
       in this language.
       If no <replaceable class="parameter">inline_handler</replaceable>
       function is specified, the language does not support anonymous code
       blocks.
       The handler function must take one argument of
       type <type>internal</type>, which will be the <command>DO</command> command's
       internal representation, and it will typically return
       <type>void</type>.  The return value of the handler is ignored.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>VALIDATOR</literal> <replaceable class="parameter">valfunction</replaceable></term>

     <listitem>
      <para><replaceable class="parameter">valfunction</replaceable> is the
       name of a previously registered function that will be called
       when a new function in the language is created, to validate the
       new function.
       If no
       validator function is specified, then a new function will not
       be checked when it is created.
       The validator function must take one argument of
       type <type>oid</type>, which will be the OID of the
       to-be-created function, and will typically return <type>void</type>.
      </para>

      <para>
       A validator function would typically inspect the function body
       for syntactical correctness, but it can also look at other
       properties of the function, for example if the language cannot
       handle certain argument types.  To signal an error, the
       validator function should use the <function>ereport()</function>
       function.  The return value of the function is ignored.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
 </refsect1>

 <refsect1 id="sql-createlanguage-notes">
  <title>Notes</title>

  <para>
   Use <link linkend="sql-droplanguage"><command>DROP LANGUAGE</command></link> to drop procedural languages.
  </para>

  <para>
   The system catalog <classname>pg_language</classname> (see <xref
   linkend="catalog-pg-language"/>) records information about the
   currently installed languages.  Also, the <application>psql</application>
   command <command>\dL</command> lists the installed languages.
  </para>

  <para>
   To create functions in a procedural language, a user must have the
   <literal>USAGE</literal> privilege for the language.  By default,
   <literal>USAGE</literal> is granted to <literal>PUBLIC</literal> (i.e., everyone)
   for trusted languages.  This can be revoked if desired.
  </para>

  <para>
   Procedural languages are local to individual databases.
   However, a language can be installed into the <literal>template1</literal>
   database, which will cause it to be available automatically in
   all subsequently-created databases.
  </para>
 </refsect1>

 <refsect1 id="sql-createlanguage-examples">
  <title>Examples</title>

  <para>
   A minimal sequence for creating a new procedural language is:
<programlisting>
CREATE FUNCTION plsample_call_handler() RETURNS language_handler
    AS '$libdir/plsample'
    LANGUAGE C;
CREATE LANGUAGE plsample
    HANDLER plsample_call_handler;
</programlisting>
   Typically that would be written in an extension's creation script,
   and users would do this to install the extension:
<programlisting>
CREATE EXTENSION plsample;
</programlisting></para>
 </refsect1>

 <refsect1 id="sql-createlanguage-compat">
  <title>Compatibility</title>

  <para>
   <command>CREATE LANGUAGE</command> is a
   <productname>PostgreSQL</productname> extension.
  </para>
 </refsect1>

 <refsect1>
  <title>See Also</title>

  <simplelist type="inline">
   <member><xref linkend="sql-alterlanguage"/></member>
   <member><xref linkend="sql-createfunction"/></member>
   <member><xref linkend="sql-droplanguage"/></member>
   <member><xref linkend="sql-grant"/></member>
   <member><xref linkend="sql-revoke"/></member>
  </simplelist>
 </refsect1>
</refentry>