Project: YugabyteDB (App Definition and Development / Database)
File: ddl_alter_function.md

title: ALTER FUNCTION statement [YSQL] headerTitle: ALTER FUNCTION linkTitle: ALTER FUNCTION description: Change properties of an existing function. menu: v2.18: identifier: ddlalterfunction parent: statements type: docs {{< tip title="See the dedicated 'User-defined subprograms and anonymous blocks' section." >}} User-defined functions are part of a larger area of functionality. See this major section: {{< /tip >}} Use the `ALTER FUNCTION` statement to change properties of an existing function. {{%ebnf%}} alter_function, subprogram_signature, arg_decl, specialfnandprocattribute, alterablefnandprocattribute, alterablefnonly_attribute, volatility, onnullinput, parallel_mode {{%/ebnf%}} You must identify the to-be-altered function by: Its name and the schema where it lives. This can be done by using its fully qualified name or by using just its bare name and letting name resolution find it in the first schema on the searchpath_ where it occurs. Notice that you don't need to (and cannot) mention the name of its owner. Its signature. The is sufficient; and this is typically used. You can use the full subprogramsignature. But you should realize that the argname and argmode for each argdecl carry no identifying information. (This is why it is not typically used when a function or procedure is to be altered or dropped.) This is explained in the section . This is explained in the section . Supposed that you create a function like this: ```plpgsql drop schema if exists s3 cascade; drop schema if exists s4 cascade; create schema s3; create function s3.f(i in int) returns text security definer volatile language plpgsql as $body$ begin return 'Result: '||(i*2)::text; end; $body$; select s3.f(17) as "s3.f(17)"; ``` This is the result: ```output s3.f(17) Result: 34 ``` Now suppose you realise that security definer was the wrong choice, that you want to mark it immutable, and that you want to set the statementtimeout attribute (never mind that this is unrealistic here). Suppose, too, that: you want to call the function g() instead of f(); and you want it to be in schema s4 and not in schema s3_. You must use three `ALTER` statements to do this, thus: ```plpgsql alter function s3.f(int) security invoker immutable set statement_timeout = 1; ``` Check the effect by inspecting the function's metadata. See the section for information on how to query subprogram metadata. ```plpgsql select proname::text as name, pronamespace::regnamespace::text as schema, case when prosecdef then 'definer' else 'invoker' end as security, case when provolatile = 'v' then 'volatile' when provolatile = 's' then 'stable' when provolatile = 'i' then 'immutable' end as volatility, proconfig as settings from pg_proc where proowner::regrole::text = 'u1' and proname::text in ('f', 'g'); ``` This is the result: ```output name | schema | security | volatility | settings +--+-++-- f | s3 | invoker | immutable | {statement_timeout=1} ``` Now rename the function: ```plpgsql alter function s3.f(int) rename to g; ``` Check the result by re-running the pgprpc_ query. This is new result: ```output name | schema | security | volatility | settings +--+-++-- g | s3 | invoker | immutable | {statement_timeout=1} ``` Now change the schema: ```plpgsql create schema s4; alter function s3.g(int) set schema s4; ``` Check the result by re-running the pgprpc_ query. This is new result: ```output name | schema | security | volatility | settings +--+-++-- g | s4 | invoker | immutable | {statement_timeout=1} ```