34.40. routines

Представление routines показывает все функции в текущей базе данных. В нём показываются только функции, к которым имеет доступ текущий пользователь (являясь владельцем или имея некоторые права).

Таблица 34.38. Столбцы routines

ИмяТип данныхОписание
specific_catalogsql_identifierИмя базы данных, содержащей функцию (всегда текущая база)
specific_schemasql_identifierИмя схемы, содержащей функцию
specific_namesql_identifier«Однозначное имя» функции. Это имя однозначным образом идентифицирует функцию в схеме, даже если реальное имя функции перегружено. Формат однозначных имён не определён, так что его следует использовать только для сравнения с другими экземплярами однозначных имён подпрограмм.
routine_catalogsql_identifierИмя базы данных, содержащей функцию (всегда текущая база)
routine_schemasql_identifierИмя схемы, содержащей функцию
routine_namesql_identifierИмя функции (может дублироваться в случае перегрузки)
routine_typecharacter_dataВсегда FUNCTION (в будущем могут появиться и другие типы подпрограмм.)
module_catalogsql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
module_schemasql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
module_namesql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
udt_catalogsql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
udt_schemasql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
udt_namesql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
data_typecharacter_dataТип данных результата функции, если это встроенный тип, либо ARRAY, если это массив (в этом случае обратитесь к представлению element_types), иначе — USER-DEFINED (в этом случае тип определяется в type_udt_name и связанных столбцах).
character_maximum_lengthcardinal_numberВсегда NULL, так как эта информация неприменима к типам результатов в Postgres Pro
character_octet_lengthcardinal_numberВсегда NULL, так как эта информация неприменима к типам результатов в Postgres Pro
character_set_catalogsql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
character_set_schemasql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
character_set_namesql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
collation_catalogsql_identifierВсегда NULL, так как эта информация неприменима к типам результатов в Postgres Pro
collation_schemasql_identifierВсегда NULL, так как эта информация неприменима к типам результатов в Postgres Pro
collation_namesql_identifierВсегда NULL, так как эта информация неприменима к типам результатов в Postgres Pro
numeric_precisioncardinal_numberВсегда NULL, так как эта информация неприменима к типам результатов в Postgres Pro
numeric_precision_radixcardinal_numberВсегда NULL, так как эта информация неприменима к типам результатов в Postgres Pro
numeric_scalecardinal_numberВсегда NULL, так как эта информация неприменима к типам результатов в Postgres Pro
datetime_precisioncardinal_numberВсегда NULL, так как эта информация неприменима к типам результатов в Postgres Pro
interval_typecharacter_dataВсегда NULL, так как эта информация неприменима к типам результатов в Postgres Pro
interval_precisioncardinal_numberВсегда NULL, так как эта информация неприменима к типам результатов в Postgres Pro
type_udt_catalogsql_identifierИмя базы данных, в которой определён тип данных результата функции (всегда текущая база)
type_udt_schemasql_identifierИмя схемы, в которой определён тип данных результата функции
type_udt_namesql_identifierИмя типа данных результата функции
scope_catalogsql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
scope_schemasql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
scope_namesql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
maximum_cardinalitycardinal_numberВсегда NULL, так как массивы имеют неограниченную максимальную ёмкость в Postgres Pro
dtd_identifiersql_identifierИдентификатор дескриптора типа данных результата функции, уникальный среди всех дескрипторов типов, относящихся к функции. Он в основном полезен для соединения с другими экземплярами таких идентификаторов. (Конкретный формат идентификатора не определён и не гарантируется, что он останется неизменным в будущих версиях.)
routine_bodycharacter_dataЕсли функция написана на SQL, это поле содержит SQL, иначе EXTERNAL.
routine_definitioncharacter_dataИсходный текст функции (NULL, если функция не принадлежит текущей активной роли). (Согласно стандарту SQL, этот столбец актуален, только если в routine_body указано SQL, но в Postgres Pro он будет содержать любой исходный текст, заданный при создании функции.)
external_namecharacter_dataЕсли это функция на C, этот столбец содержит внешнее имя (объектный символ) функции, иначе — NULL. (Это будет то же значение, что содержит столбец routine_definition.)
external_languagecharacter_dataЯзык, на котором написана функция
parameter_stylecharacter_dataВсегда GENERAL (В стандарте SQL определены и другие стили параметров, но в Postgres Pro они отсутствуют.)
is_deterministicyes_or_noЕсли функция объявлена как постоянная (IMMUTABLE) (в стандарте SQL она называется детерминированной), этот столбец содержит YES, иначе — NO. (Получить другие уровни переменности функций, имеющиеся в Postgres Pro, через информационную схему нельзя.)
sql_data_accesscharacter_dataВсегда MODIFIES, что означает, что функция может модифицировать данные SQL. Для Postgres Pro эта информация бесполезна.
is_null_callyes_or_noЕсли функция автоматически возвращает NULL, когда один из аргументов NULL, этот столбец содержит YES, иначе — NO.
sql_pathcharacter_dataОтносится к функциональности, отсутствующей в Postgres Pro
schema_level_routineyes_or_noВсегда YES (Другое значение было бы у методов пользовательских типов, но в Postgres Pro их нет.)
max_dynamic_result_setscardinal_numberОтносится к функциональности, отсутствующей в Postgres Pro
is_user_defined_castyes_or_noОтносится к функциональности, отсутствующей в Postgres Pro
is_implicitly_invocableyes_or_noОтносится к функциональности, отсутствующей в Postgres Pro
security_typecharacter_dataЕсли функция выполняется с правами вызывающего пользователя, этот столбец содержит INVOKER, а если с правами пользователя, создавшего её, то — DEFINER.
to_sql_specific_catalogsql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
to_sql_specific_schemasql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
to_sql_specific_namesql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
as_locatoryes_or_noОтносится к функциональности, отсутствующей в Postgres Pro
createdtime_stampОтносится к функциональности, отсутствующей в Postgres Pro
last_alteredtime_stampОтносится к функциональности, отсутствующей в Postgres Pro
new_savepoint_levelyes_or_noОтносится к функциональности, отсутствующей в Postgres Pro
is_udt_dependentyes_or_noВ настоящее время всегда NO. Альтернативное значение YES связано с возможностями, отсутствующими в Postgres Pro.
result_cast_from_data_typecharacter_dataОтносится к функциональности, отсутствующей в Postgres Pro
result_cast_as_locatoryes_or_noОтносится к функциональности, отсутствующей в Postgres Pro
result_cast_char_max_lengthcardinal_numberОтносится к функциональности, отсутствующей в Postgres Pro
result_cast_char_octet_lengthcharacter_dataОтносится к функциональности, отсутствующей в Postgres Pro
result_cast_char_set_catalogsql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
result_cast_char_set_schemasql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
result_cast_char_set_namesql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
result_cast_collation_catalogsql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
result_cast_collation_schemasql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
result_cast_collation_namesql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
result_cast_numeric_precisioncardinal_numberОтносится к функциональности, отсутствующей в Postgres Pro
result_cast_numeric_precision_radixcardinal_numberОтносится к функциональности, отсутствующей в Postgres Pro
result_cast_numeric_scalecardinal_numberОтносится к функциональности, отсутствующей в Postgres Pro
result_cast_datetime_precisioncharacter_dataОтносится к функциональности, отсутствующей в Postgres Pro
result_cast_interval_typecharacter_dataОтносится к функциональности, отсутствующей в Postgres Pro
result_cast_interval_precisioncardinal_numberОтносится к функциональности, отсутствующей в Postgres Pro
result_cast_type_udt_catalogsql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
result_cast_type_udt_schemasql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
result_cast_type_udt_namesql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
result_cast_scope_catalogsql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
result_cast_scope_schemasql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
result_cast_scope_namesql_identifierОтносится к функциональности, отсутствующей в Postgres Pro
result_cast_maximum_cardinalitycardinal_numberОтносится к функциональности, отсутствующей в Postgres Pro
result_cast_dtd_identifiersql_identifierОтносится к функциональности, отсутствующей в Postgres Pro

36.2. The Postgres Pro Type System

Postgres Pro data types can be divided into base types, container types, domains, and pseudo-types.

36.2.1. Base Types

Base types are those, like integer, that are implemented below the level of the SQL language (typically in a low-level language such as C). They generally correspond to what are often known as abstract data types. Postgres Pro can only operate on such types through functions provided by the user and only understands the behavior of such types to the extent that the user describes them. The built-in base types are described in Chapter 8.

Enumerated (enum) types can be considered as a subcategory of base types. The main difference is that they can be created using just SQL commands, without any low-level programming. Refer to Section 8.7 for more information.

36.2.2. Container Types

Postgres Pro has three kinds of container types, which are types that contain multiple values of other types. These are arrays, composites, and ranges.

Arrays can hold multiple values that are all of the same type. An array type is automatically created for each base type, composite type, range type, and domain type. But there are no arrays of arrays. So far as the type system is concerned, multi-dimensional arrays are the same as one-dimensional arrays. Refer to Section 8.15 for more information.

Composite types, or row types, are created whenever the user creates a table. It is also possible to use CREATE TYPE to define a stand-alone composite type with no associated table. A composite type is simply a list of types with associated field names. A value of a composite type is a row or record of field values. Refer to Section 8.16 for more information.

A range type can hold two values of the same type, which are the lower and upper bounds of the range. Range types are user-created, although a few built-in ones exist. Refer to Section 8.17 for more information.

36.2.3. Domains

A domain is based on a particular underlying type and for many purposes is interchangeable with its underlying type. However, a domain can have constraints that restrict its valid values to a subset of what the underlying type would allow. Domains are created using the SQL command CREATE DOMAIN. Refer to Section 8.18 for more information.

36.2.4. Pseudo-Types

There are a few pseudo-types for special purposes. Pseudo-types cannot appear as columns of tables or components of container types, but they can be used to declare the argument and result types of functions. This provides a mechanism within the type system to identify special classes of functions. Table 8.25 lists the existing pseudo-types.

36.2.5. Polymorphic Types

Five pseudo-types of special interest are anyelement, anyarray, anynonarray, anyenum, and anyrange, which are collectively called polymorphic types. Any function declared using these types is said to be a polymorphic function. A polymorphic function can operate on many different data types, with the specific data type(s) being determined by the data types actually passed to it in a particular call.

Polymorphic arguments and results are tied to each other and are resolved to a specific data type when a query calling a polymorphic function is parsed. Each position (either argument or return value) declared as anyelement is allowed to have any specific actual data type, but in any given call they must all be the same actual type. Each position declared as anyarray can have any array data type, but similarly they must all be the same type. And similarly, positions declared as anyrange must all be the same range type. Furthermore, if there are positions declared anyarray and others declared anyelement, the actual array type in the anyarray positions must be an array whose elements are the same type appearing in the anyelement positions. Similarly, if there are positions declared anyrange and others declared anyelement or anyarray, the actual range type in the anyrange positions must be a range whose subtype is the same type appearing in the anyelement positions and the same as the element type of the anyarray positions. anynonarray is treated exactly the same as anyelement, but adds the additional constraint that the actual type must not be an array type. anyenum is treated exactly the same as anyelement, but adds the additional constraint that the actual type must be an enum type.

Thus, when more than one argument position is declared with a polymorphic type, the net effect is that only certain combinations of actual argument types are allowed. For example, a function declared as equal(anyelement, anyelement) will take any two input values, so long as they are of the same data type.

When the return value of a function is declared as a polymorphic type, there must be at least one argument position that is also polymorphic, and the actual data type supplied as the argument determines the actual result type for that call. For example, if there were not already an array subscripting mechanism, one could define a function that implements subscripting as subscript(anyarray, integer) returns anyelement. This declaration constrains the actual first argument to be an array type, and allows the parser to infer the correct result type from the actual first argument's type. Another example is that a function declared as f(anyarray) returns anyenum will only accept arrays of enum types.

In most cases, the parser can infer the actual data type for a polymorphic result type from arguments that are of a different polymorphic type; for example anyarray can be deduced from anyelement or vice versa. The exception is that a polymorphic result of type anyrange requires an argument of type anyrange; it cannot be deduced from anyarray or anyelement arguments. This is because there could be multiple range types with the same subtype.

Note that anynonarray and anyenum do not represent separate type variables; they are the same type as anyelement, just with an additional constraint. For example, declaring a function as f(anyelement, anyenum) is equivalent to declaring it as f(anyenum, anyenum): both actual arguments have to be the same enum type.

A variadic function (one taking a variable number of arguments, as in Section 36.5.5) can be polymorphic: this is accomplished by declaring its last parameter as VARIADIC anyarray. For purposes of argument matching and determining the actual result type, such a function behaves the same as if you had written the appropriate number of anynonarray parameters.