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

title: ALTER PROCEDURE statement [YSQL] headerTitle: ALTER PROCEDURE linkTitle: ALTER PROCEDURE description: Change properties of an existing procedure. menu: v2.18: identifier: ddlalterprocedure parent: statements type: docs {{< tip title="See the dedicated 'User-defined subprograms and anonymous blocks' section." >}} User-defined procedures are part of a larger area of functionality. See this major section: {{< /tip >}} Use the `ALTER PROCEDURE` statement to change properties of an existing procedure. {{%ebnf%}} alter_procedure, subprogram_signature, arg_decl, specialfnandprocattribute, alterablefnandprocattribute {{%/ebnf%}} You must identify the to-be-altered procedure 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 procedure like this: ```plpgsql drop schema if exists s1 cascade; drop schema if exists s2 cascade; create schema s1; create procedure s1.p(i in int) security definer language plpgsql as $body$ begin execute format('set my_namespace.x = %L', i::text); end; $body$; call s1.p(42); select currentsetting('mynamespace.x')::int as "my_namespace.x"; ``` This is the result: ```output my_namespace.x 42 ``` Now suppose you realise that security definer was the wrong choice and that you want to set the statementtimeout attribute (never mind that this is unrealistic here). Suppose, too, that: you want to call the procedure q() instead of p(); and you want it to be in schema s2 and not in schema s1_. You must use three `ALTER` statements to do this, thus: ```plpgsql alter procedure s1.p(int) security invoker set statement_timeout = 1; ``` The attempt draws a warning in the current preview version of YugabyteDB, thus: ```output 0A000: ALTER PROCEDURE not supported yet ``` and the hint refers you to In spite of the warning, the attempt actually has the intended effect. You can see this by inspecting the procedure'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, proconfig as settings from pg_proc where proowner::regrole::text = 'u1' and proname::text in ('p', 'q'); ``` This is the result: ```output name | schema | security | settings +--+-+-- p | s1 | invoker | {statement_timeout=1} ``` Now rename the procedure: ```plpgsql alter procedure s1.p(int) rename to q; ``` You get the 0A000 warning ("not supported yet") again. But, again, you get the intended result. Confirm this by re-running the pgprpc_ query: This is new result: ```output name | schema | security | settings +--+-+-- q | s1 | invoker | {statement_timeout=1} ``` Now change the schema: ```plpgsql create schema s2; alter procedure s1.q(int) set schema s2; ``` This time you get a differently spelled warning: ```output 0A000: ALTER PROCEDURE SET SCHEMA not supported yet ``` but when you check the procedure's metadata you see, once again, that the schema is actually changed as intended: ```output name | schema | security | settings +--+-+-- q | s2 | invoker | {statement_timeout=1} ```