docs/content/v2.25/api/ysql/user-defined-subprograms-and-anon-blocks/subprogram-attributes/_index.md
The overall behavior of a user-defined function or procedure is determined by a set of characteristics that are defined with the create [or replace] and alter statements for each subprogram kind.
The following characteristics are singletons in the categorization scheme in that they may be set only with create [or replace] and the rules that specify how they are set are not spelled with "attribute":
The argument list (i.e. the name, the mode, the data type, and optionally a default expression for each argument). See the arg_decl_with_dflt rule.
And, just for a function, the return data type.
All of the other determining characteristics are known by the term of art attribute. This term is used in the names of rules in the YSQL Grammar for distinct subcategories of attribute, grouped according to when they may be set (only with create [or replace], only with alter, or with both) and to which kind of subprogram they apply (only to functions, or to both functions and procedures).
You can see the names of all of these rules in the grammars for create [or replace] function, create [or replace] procedure, alter function, and alter procedure, below:
{{%ebnf localrefs="alterable_fn_only_attribute,alterable_fn_and_proc_attribute,special_fn_and_proc_attribute,unalterable_fn_attribute,unalterable_proc_attribute" %}} create_function, create_procedure, alter_function, alter_procedure {{%/ebnf%}}
Here are the different attribute rules.
The unalterable subprogram attributes can be set only with the create [or replace] statement. Each of function and procedure has its own unalterable attributes rule. They share language and subprogram_implementation. But the status regular function or window function is meaningless for a procedure.
{{%ebnf%}} unalterable_fn_attribute, unalterable_proc_attribute {{%/ebnf%}}
{{< note title="This major section, so far, describes only user-defined subprograms and anonymous blocks that are implemented in SQL or PL/pgSQL." >}} Further, it does not yet describe how to create user-defined window functions. {{< /note >}}
The special subprogram attributes are set using a general syntax style with the alter statements.
{{%ebnf%}} special_fn_and_proc_attribute {{%/ebnf%}}
The syntax diagram shows that if you want to change any of these attributes, then you must change them one at a time by issuing alter repeatedly.
The schema and the name of a subprogram are set using dedicated explicit syntax with create [or replace]. But the owner cannot be explicitly set with create [or replace]; rather, a new subprogram's owner is implicitly set to what the current_role built-in function returns. (This will be what the session_user built-in function returns if create [or replace] is issued as a top-level SQL statement; and it will be the owner of a security definer subprogram that issues the SQL statement.)
As it happens, and just for PostgreSQL-historical reasons, if you want to specify the extension on which a new subprogram depends you can do this only by first creating the subprogram and then specifying the name of the extension using the subprogram-specific alter statement.
See the section The semantics of the "depends on extension" subprogram attribute for more information about this attribute.
These attributes are common for both functions and procedures:
{{%ebnf%}} alterable_fn_and_proc_attribute {{%/ebnf%}}
See the subsection Alterable subprogram attributes for the explanations of the configuration parameter and security attributes.
Notice that there are no procedure-specific alterable attributes. These attributes are specific to just functions:
{{%ebnf%}} alterable_fn_only_attribute {{%/ebnf%}}
See the subsection Alterable function-only attributes for the explanations of the volatility, On NULL input, parallel, leakproof, cost and rows attributes.