<!--
doc/src/sgml/ref/create_language.sgml
PostgreSQL documentation
-->
<refentry id="sql-createlanguage">
<indexterm zone="sql-createlanguage">
<primary>CREATE LANGUAGE</primary>
</indexterm>
<refmeta>
<refentrytitle>CREATE LANGUAGE</refentrytitle>
<manvolnum>7</manvolnum>
<refmiscinfo>SQL - Language Statements</refmiscinfo>
</refmeta>
<refnamediv>
<refname>CREATE LANGUAGE</refname>
<refpurpose>define a new procedural language</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
CREATE [ OR REPLACE ] [ TRUSTED ] [ PROCEDURAL ] LANGUAGE <replaceable class="parameter">name</replaceable>
HANDLER <replaceable class="parameter">call_handler</replaceable> [ INLINE <replaceable class="parameter">inline_handler</replaceable> ] [ VALIDATOR <replaceable>valfunction</replaceable> ]
CREATE [ OR REPLACE ] [ TRUSTED ] [ PROCEDURAL ] LANGUAGE <replaceable class="parameter">name</replaceable>
</synopsis>
</refsynopsisdiv>
<refsect1 id="sql-createlanguage-description">
<title>Description</title>
<para>
<command>CREATE LANGUAGE</command> registers a new
procedural language with a <productname>PostgreSQL</productname>
database. Subsequently, functions and procedures can be
defined in this new language.
</para>
<para>
<command>CREATE LANGUAGE</command> effectively associates the
language name with handler function(s) that are responsible for executing
functions written in the language. Refer to <xref linkend="plhandler"/>
for more information about language handlers.
</para>
<para>
<command>CREATE OR REPLACE LANGUAGE</command> will either create a
new language, or replace an existing definition. If the language
already exists, its parameters are updated according to the command,
but the language's ownership and permissions settings do not change,
and any existing functions written in the language are assumed to still
be valid.
</para>
<para>
One must have the
<productname>PostgreSQL</productname> superuser privilege to
register a new language or change an existing language's parameters.
However, once the language is created it is valid to assign ownership of
it to a non-superuser, who may then drop it, change its permissions,
rename it, or assign it to a new owner. (Do not, however, assign
ownership of the underlying C functions to a non-superuser; that would
create a privilege escalation path for that user.)
</para>
<para>
The form of <command>CREATE LANGUAGE</command> that does not supply
any handler function is obsolete. For backwards compatibility with
old dump files, it is interpreted as <command>CREATE EXTENSION</command>.
That will work if the language has been packaged into an extension of
the same name, which is the conventional way to set up procedural
languages.
</para>
</refsect1>
<refsect1 id="sql-createlanguage-parameters">
<title>Parameters</title>
<variablelist>
<varlistentry>
<term><literal>TRUSTED</literal></term>
<listitem>
<para><literal>TRUSTED</literal> specifies that the language does
not grant access to data that the user would not otherwise
have. If this key word is omitted
when registering the language, only users with the
<productname>PostgreSQL</productname> superuser privilege can
use this language to create new functions.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>PROCEDURAL</literal></term>
<listitem>
<para>
This is a noise word.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable class="parameter">name</replaceable></term>
<listitem>
<para>
The name of the new procedural language.
The name must be unique among the languages in the database.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>HANDLER</literal> <replaceable class="parameter">call_handler</replaceable></term>