postgresql/doc/src/sgml/ref/alter_function.sgml

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

391 lines
14 KiB
Plaintext
Raw Normal View History

2003-06-27 16:45:32 +02:00
<!--
2010-09-20 22:08:53 +02:00
doc/src/sgml/ref/alter_function.sgml
2003-06-27 16:45:32 +02:00
PostgreSQL documentation
-->
<refentry id="sql-alterfunction">
<indexterm zone="sql-alterfunction">
<primary>ALTER FUNCTION</primary>
</indexterm>
2003-06-27 16:45:32 +02:00
<refmeta>
<refentrytitle>ALTER FUNCTION</refentrytitle>
<manvolnum>7</manvolnum>
2003-06-27 16:45:32 +02:00
<refmiscinfo>SQL - Language Statements</refmiscinfo>
</refmeta>
<refnamediv>
<refname>ALTER FUNCTION</refname>
<refpurpose>change the definition of a function</refpurpose>
</refnamediv>
2003-06-27 16:45:32 +02:00
<refsynopsisdiv>
<synopsis>
ALTER FUNCTION <replaceable>name</replaceable> [ ( [ [ <replaceable class="parameter">argmode</replaceable> ] [ <replaceable class="parameter">argname</replaceable> ] <replaceable class="parameter">argtype</replaceable> [, ...] ] ) ]
<replaceable class="parameter">action</replaceable> [ ... ] [ RESTRICT ]
ALTER FUNCTION <replaceable>name</replaceable> [ ( [ [ <replaceable class="parameter">argmode</replaceable> ] [ <replaceable class="parameter">argname</replaceable> ] <replaceable class="parameter">argtype</replaceable> [, ...] ] ) ]
RENAME TO <replaceable>new_name</replaceable>
ALTER FUNCTION <replaceable>name</replaceable> [ ( [ [ <replaceable class="parameter">argmode</replaceable> ] [ <replaceable class="parameter">argname</replaceable> ] <replaceable class="parameter">argtype</replaceable> [, ...] ] ) ]
OWNER TO { <replaceable>new_owner</replaceable> | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER FUNCTION <replaceable>name</replaceable> [ ( [ [ <replaceable class="parameter">argmode</replaceable> ] [ <replaceable class="parameter">argname</replaceable> ] <replaceable class="parameter">argtype</replaceable> [, ...] ] ) ]
SET SCHEMA <replaceable>new_schema</replaceable>
ALTER FUNCTION <replaceable>name</replaceable> [ ( [ [ <replaceable class="parameter">argmode</replaceable> ] [ <replaceable class="parameter">argname</replaceable> ] <replaceable class="parameter">argtype</replaceable> [, ...] ] ) ]
[ NO ] DEPENDS ON EXTENSION <replaceable>extension_name</replaceable>
<phrase>where <replaceable class="parameter">action</replaceable> is one of:</phrase>
CALLED ON NULL INPUT | RETURNS NULL ON NULL INPUT | STRICT
IMMUTABLE | STABLE | VOLATILE
[ NOT ] LEAKPROOF
[ EXTERNAL ] SECURITY INVOKER | [ EXTERNAL ] SECURITY DEFINER
Determine whether it's safe to attempt a parallel plan for a query. Commit 924bcf4f16d54c55310b28f77686608684734f42 introduced a framework for parallel computation in PostgreSQL that makes most but not all built-in functions safe to execute in parallel mode. In order to have parallel query, we'll need to be able to determine whether that query contains functions (either built-in or user-defined) that cannot be safely executed in parallel mode. This requires those functions to be labeled, so this patch introduces an infrastructure for that. Some functions currently labeled as safe may need to be revised depending on how pending issues related to heavyweight locking under paralllelism are resolved. Parallel plans can't be used except for the case where the query will run to completion. If portal execution were suspended, the parallel mode restrictions would need to remain in effect during that time, but that might make other queries fail. Therefore, this patch introduces a framework that enables consideration of parallel plans only when it is known that the plan will be run to completion. This probably needs some refinement; for example, at bind time, we do not know whether a query run via the extended protocol will be execution to completion or run with a limited fetch count. Having the client indicate its intentions at bind time would constitute a wire protocol break. Some contexts in which parallel mode would be safe are not adjusted by this patch; the default is not to try parallel plans except from call sites that have been updated to say that such plans are OK. This commit doesn't introduce any parallel paths or plans; it just provides a way to determine whether they could potentially be used. I'm committing it on the theory that the remaining parallel sequential scan patches will also get committed to this release, hopefully in the not-too-distant future. Robert Haas and Amit Kapila. Reviewed (in earlier versions) by Noah Misch.
2015-09-16 21:38:47 +02:00
PARALLEL { UNSAFE | RESTRICTED | SAFE }
COST <replaceable class="parameter">execution_cost</replaceable>
ROWS <replaceable class="parameter">result_rows</replaceable>
SUPPORT <replaceable class="parameter">support_function</replaceable>
SET <replaceable class="parameter">configuration_parameter</replaceable> { TO | = } { <replaceable class="parameter">value</replaceable> | DEFAULT }
SET <replaceable class="parameter">configuration_parameter</replaceable> FROM CURRENT
RESET <replaceable class="parameter">configuration_parameter</replaceable>
RESET ALL
2003-06-27 16:45:32 +02:00
</synopsis>
</refsynopsisdiv>
2003-06-27 16:45:32 +02:00
<refsect1>
<title>Description</title>
<para>
<command>ALTER FUNCTION</command> changes the definition of a
function.
2003-06-27 16:45:32 +02:00
</para>
<para>
You must own the function to use <command>ALTER FUNCTION</command>.
To change a function's schema, you must also have <literal>CREATE</literal>
privilege on the new schema.
To alter the owner, you must also be a direct or indirect member of the new
owning role, and that role must have <literal>CREATE</literal> privilege on
the function's schema. (These restrictions enforce that altering the owner
doesn't do anything you couldn't do by dropping and recreating the function.
However, a superuser can alter ownership of any function anyway.)
</para>
2003-06-27 16:45:32 +02:00
</refsect1>
2003-06-27 16:45:32 +02:00
<refsect1>
<title>Parameters</title>
<variablelist>
<varlistentry>
<term><replaceable class="parameter">name</replaceable></term>
<listitem>
<para>
The name (optionally schema-qualified) of an existing function. If no
argument list is specified, the name must be unique in its schema.
2003-06-27 16:45:32 +02:00
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable class="parameter">argmode</replaceable></term>
<listitem>
<para>
The mode of an argument: <literal>IN</literal>, <literal>OUT</literal>,
<literal>INOUT</literal>, or <literal>VARIADIC</literal>.
If omitted, the default is <literal>IN</literal>.
Note that <command>ALTER FUNCTION</command> does not actually pay
any attention to <literal>OUT</literal> arguments, since only the input
arguments are needed to determine the function's identity.
So it is sufficient to list the <literal>IN</literal>, <literal>INOUT</literal>,
and <literal>VARIADIC</literal> arguments.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable class="parameter">argname</replaceable></term>
<listitem>
<para>
The name of an argument.
Note that <command>ALTER FUNCTION</command> does not actually pay
any attention to argument names, since only the argument data
types are needed to determine the function's identity.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable class="parameter">argtype</replaceable></term>
2003-06-27 16:45:32 +02:00
<listitem>
<para>
The data type(s) of the function's arguments (optionally
schema-qualified), if any.
2003-06-27 16:45:32 +02:00
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable class="parameter">new_name</replaceable></term>
2003-06-27 16:45:32 +02:00
<listitem>
<para>
The new name of the function.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable class="parameter">new_owner</replaceable></term>
<listitem>
<para>
The new owner of the function. Note that if the function is
marked <literal>SECURITY DEFINER</literal>, it will subsequently
execute as the new owner.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable class="parameter">new_schema</replaceable></term>
<listitem>
<para>
The new schema for the function.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>DEPENDS ON EXTENSION <replaceable class="parameter">extension_name</replaceable></literal></term>
<term><literal>NO DEPENDS ON EXTENSION <replaceable class="parameter">extension_name</replaceable></literal></term>
<listitem>
<para>
This form marks the function as dependent on the extension, or no longer
dependent on that extension if <literal>NO</literal> is specified.
A function that's marked as dependent on an extension is automatically
dropped when the extension is dropped.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>CALLED ON NULL INPUT</literal></term>
<term><literal>RETURNS NULL ON NULL INPUT</literal></term>
<term><literal>STRICT</literal></term>
<listitem>
<para><literal>CALLED ON NULL INPUT</literal> changes the function so
that it will be invoked when some or all of its arguments are
null. <literal>RETURNS NULL ON NULL INPUT</literal> or
<literal>STRICT</literal> changes the function so that it is not
invoked if any of its arguments are null; instead, a null result
is assumed automatically. See <xref linkend="sql-createfunction"/>
for more information.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>IMMUTABLE</literal></term>
<term><literal>STABLE</literal></term>
<term><literal>VOLATILE</literal></term>
<listitem>
<para>
2006-02-19 00:14:45 +01:00
Change the volatility of the function to the specified setting.
See <xref linkend="sql-createfunction"/> for details.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal><optional> EXTERNAL </optional> SECURITY INVOKER</literal></term>
<term><literal><optional> EXTERNAL </optional> SECURITY DEFINER</literal></term>
<listitem>
<para>
Change whether the function is a security definer or not. The
key word <literal>EXTERNAL</literal> is ignored for SQL
conformance. See <xref linkend="sql-createfunction"/> for more information about
2006-02-19 00:14:45 +01:00
this capability.
</para>
</listitem>
</varlistentry>
Determine whether it's safe to attempt a parallel plan for a query. Commit 924bcf4f16d54c55310b28f77686608684734f42 introduced a framework for parallel computation in PostgreSQL that makes most but not all built-in functions safe to execute in parallel mode. In order to have parallel query, we'll need to be able to determine whether that query contains functions (either built-in or user-defined) that cannot be safely executed in parallel mode. This requires those functions to be labeled, so this patch introduces an infrastructure for that. Some functions currently labeled as safe may need to be revised depending on how pending issues related to heavyweight locking under paralllelism are resolved. Parallel plans can't be used except for the case where the query will run to completion. If portal execution were suspended, the parallel mode restrictions would need to remain in effect during that time, but that might make other queries fail. Therefore, this patch introduces a framework that enables consideration of parallel plans only when it is known that the plan will be run to completion. This probably needs some refinement; for example, at bind time, we do not know whether a query run via the extended protocol will be execution to completion or run with a limited fetch count. Having the client indicate its intentions at bind time would constitute a wire protocol break. Some contexts in which parallel mode would be safe are not adjusted by this patch; the default is not to try parallel plans except from call sites that have been updated to say that such plans are OK. This commit doesn't introduce any parallel paths or plans; it just provides a way to determine whether they could potentially be used. I'm committing it on the theory that the remaining parallel sequential scan patches will also get committed to this release, hopefully in the not-too-distant future. Robert Haas and Amit Kapila. Reviewed (in earlier versions) by Noah Misch.
2015-09-16 21:38:47 +02:00
<varlistentry>
<term><literal>PARALLEL</literal></term>
<listitem>
<para>
Change whether the function is deemed safe for parallelism.
See <xref linkend="sql-createfunction"/> for details.
Determine whether it's safe to attempt a parallel plan for a query. Commit 924bcf4f16d54c55310b28f77686608684734f42 introduced a framework for parallel computation in PostgreSQL that makes most but not all built-in functions safe to execute in parallel mode. In order to have parallel query, we'll need to be able to determine whether that query contains functions (either built-in or user-defined) that cannot be safely executed in parallel mode. This requires those functions to be labeled, so this patch introduces an infrastructure for that. Some functions currently labeled as safe may need to be revised depending on how pending issues related to heavyweight locking under paralllelism are resolved. Parallel plans can't be used except for the case where the query will run to completion. If portal execution were suspended, the parallel mode restrictions would need to remain in effect during that time, but that might make other queries fail. Therefore, this patch introduces a framework that enables consideration of parallel plans only when it is known that the plan will be run to completion. This probably needs some refinement; for example, at bind time, we do not know whether a query run via the extended protocol will be execution to completion or run with a limited fetch count. Having the client indicate its intentions at bind time would constitute a wire protocol break. Some contexts in which parallel mode would be safe are not adjusted by this patch; the default is not to try parallel plans except from call sites that have been updated to say that such plans are OK. This commit doesn't introduce any parallel paths or plans; it just provides a way to determine whether they could potentially be used. I'm committing it on the theory that the remaining parallel sequential scan patches will also get committed to this release, hopefully in the not-too-distant future. Robert Haas and Amit Kapila. Reviewed (in earlier versions) by Noah Misch.
2015-09-16 21:38:47 +02:00
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>LEAKPROOF</literal></term>
<listitem>
<para>
Change whether the function is considered leakproof or not.
See <xref linkend="sql-createfunction"/> for more information about
this capability.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>COST</literal> <replaceable class="parameter">execution_cost</replaceable></term>
<listitem>
<para>
Change the estimated execution cost of the function.
See <xref linkend="sql-createfunction"/> for more information.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>ROWS</literal> <replaceable class="parameter">result_rows</replaceable></term>
<listitem>
<para>
Change the estimated number of rows returned by a set-returning
function. See <xref linkend="sql-createfunction"/> for more information.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>SUPPORT</literal> <replaceable class="parameter">support_function</replaceable></term>
<listitem>
<para>
Set or change the planner support function to use for this function.
See <xref linkend="xfunc-optimization"/> for details. You must be
superuser to use this option.
</para>
<para>
This option cannot be used to remove the support function altogether,
since it must name a new support function. Use <command>CREATE OR
REPLACE FUNCTION</command> if you need to do that.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable>configuration_parameter</replaceable></term>
<term><replaceable>value</replaceable></term>
<listitem>
<para>
Add or change the assignment to be made to a configuration parameter
when the function is called. If
<replaceable>value</replaceable> is <literal>DEFAULT</literal>
or, equivalently, <literal>RESET</literal> is used, the function-local
setting is removed, so that the function executes with the value
present in its environment. Use <literal>RESET
ALL</literal> to clear all function-local settings.
<literal>SET FROM CURRENT</literal> saves the value of the parameter that
is current when <command>ALTER FUNCTION</command> is executed as the value
to be applied when the function is entered.
</para>
<para>
See <xref linkend="sql-set"/> and
<xref linkend="runtime-config"/>
for more information about allowed parameter names and values.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>RESTRICT</literal></term>
<listitem>
<para>
Ignored for conformance with the SQL standard.
</para>
</listitem>
</varlistentry>
2003-06-27 16:45:32 +02:00
</variablelist>
</refsect1>
<refsect1>
<title>Examples</title>
<para>
To rename the function <literal>sqrt</literal> for type
<type>integer</type> to <literal>square_root</literal>:
<programlisting>
ALTER FUNCTION sqrt(integer) RENAME TO square_root;
</programlisting>
</para>
<para>
To change the owner of the function <literal>sqrt</literal> for type
<type>integer</type> to <literal>joe</literal>:
<programlisting>
ALTER FUNCTION sqrt(integer) OWNER TO joe;
</programlisting>
</para>
<para>
To change the schema of the function <literal>sqrt</literal> for type
<type>integer</type> to <literal>maths</literal>:
<programlisting>
ALTER FUNCTION sqrt(integer) SET SCHEMA maths;
2003-06-27 16:45:32 +02:00
</programlisting>
</para>
<para>
To mark the function <literal>sqrt</literal> for type
<type>integer</type> as being dependent on the extension
<literal>mathlib</literal>:
<programlisting>
ALTER FUNCTION sqrt(integer) DEPENDS ON EXTENSION mathlib;
</programlisting>
</para>
<para>
To adjust the search path that is automatically set for a function:
<programlisting>
ALTER FUNCTION check_password(text) SET search_path = admin, pg_temp;
</programlisting>
</para>
<para>
To disable automatic setting of <varname>search_path</varname> for a function:
<programlisting>
ALTER FUNCTION check_password(text) RESET search_path;
</programlisting>
The function will now execute with whatever search path is used by its
caller.
</para>
2003-06-27 16:45:32 +02:00
</refsect1>
<refsect1>
<title>Compatibility</title>
<para>
This statement is partially compatible with the <command>ALTER
FUNCTION</command> statement in the SQL standard. The standard allows more
properties of a function to be modified, but does not provide the
ability to rename a function, make a function a security definer,
attach configuration parameter values to a function,
or change the owner, schema, or volatility of a function. The standard also
requires the <literal>RESTRICT</literal> key word, which is optional in
<productname>PostgreSQL</productname>.
2003-06-27 16:45:32 +02:00
</para>
</refsect1>
<refsect1>
<title>See Also</title>
<simplelist type="inline">
<member><xref linkend="sql-createfunction"/></member>
<member><xref linkend="sql-dropfunction"/></member>
<member><xref linkend="sql-alterprocedure"/></member>
<member><xref linkend="sql-alterroutine"/></member>
2003-06-27 16:45:32 +02:00
</simplelist>
</refsect1>
</refentry>