The catalog pg_proc
stores information about functions (or procedures).
See CREATE FUNCTION
and Section 33.3, “User-Defined Functions” for more information.
The table contains data for aggregate functions as well as plain functions.
If proisagg
is true, there should be a matching
row in pg_aggregate
.
Table 43.27. pg_proc
Columns
Name | Type | References | Description |
---|---|---|---|
proname |
name |
Name of the function | |
pronamespace |
oid |
|
The OID of the namespace that contains this function |
proowner |
oid |
|
Owner of the function |
prolang |
oid |
|
Implementation language or call interface of this function |
proisagg |
bool |
Function is an aggregate function | |
prosecdef |
bool |
Function is a security definer (i.e., a “setuid” function) | |
proisstrict |
bool |
Function returns null if any call argument is null. In that case the function won't actually be called at all. Functions that are not “strict” must be prepared to handle null inputs | |
proretset |
bool |
Function returns a set (i.e., multiple values of the specified data type) | |
provolatile |
char |
provolatile tells whether the function's
result depends only on its input arguments, or is affected by outside
factors.
It is i for “immutable” functions,
which always deliver the same result for the same inputs.
It is s for “stable” functions,
whose results (for fixed inputs) do not change within a scan.
It is v for “volatile” functions,
whose results may change at any time. (Use v also
for functions with side-effects, so that calls to them cannot get
optimized away.)
|
|
pronargs |
int2 |
Number of arguments | |
prorettype |
oid |
|
Data type of the return value |
proargtypes |
oidvector |
|
An array with the data types of the function arguments. This includes
only input arguments (including INOUT arguments), and thus represents
the call signature of the function
|
proallargtypes |
oid[] |
|
An array with the data types of the function arguments. This includes
all arguments (including OUT and INOUT arguments); however, if all the
arguments are IN arguments, this field will be null.
Note that subscripting is 1-based, whereas for historical reasons
proargtypes is subscripted from 0
|
proargmodes |
char[] |
An array with the modes of the function arguments, encoded as
i for IN arguments,
o for OUT arguments,
b for INOUT arguments.
If all the arguments are IN arguments, this field will be null.
Note that subscripts correspond to positions of
proallargtypes not proargtypes
|
|
proargnames |
text[] |
An array with the names of the function arguments.
Arguments without a name are set to empty strings in the array.
If none of the arguments have a name, this field will be null.
Note that subscripts correspond to positions of
proallargtypes not proargtypes
|
|
prosrc |
text |
This tells the function handler how to invoke the function. It might be the actual source code of the function for interpreted languages, a link symbol, a file name, or just about anything else, depending on the implementation language/call convention | |
probin |
bytea |
Additional information about how to invoke the function. Again, the interpretation is language-specific | |
proacl |
aclitem[] |
Access privileges; see GRANT and REVOKE for details |
For compiled functions, both built-in and dynamically loaded,
prosrc
contains the function's C-language
name (link symbol). For all other currently-known language types,
prosrc
contains the function's source
text. probin
is unused except for
dynamically-loaded C functions, for which it gives the name of the
shared library file containing the function.