34.17. columns
The view columns
contains information about all table columns (or view columns) in the database. System columns (ctid
, etc.) are not included. Only those columns are shown that the current user has access to (by way of being the owner or having some privilege).
Table 34.15. columns
Columns
Column Type Description |
---|
Name of the database containing the table (always the current database) |
Name of the schema containing the table |
Name of the table |
Name of the column |
Ordinal position of the column within the table (count starts at 1) |
Default expression of the column |
|
Data type of the column, if it is a built-in type, or |
If |
If |
If |
If |
If |
If |
If |
Applies to a feature not available in Postgres Pro (see |
Applies to a feature not available in Postgres Pro |
Applies to a feature not available in Postgres Pro |
Applies to a feature not available in Postgres Pro |
Name of the database containing the collation of the column (always the current database), null if default or the data type of the column is not collatable |
Name of the schema containing the collation of the column, null if default or the data type of the column is not collatable |
Name of the collation of the column, null if default or the data type of the column is not collatable |
If the column has a domain type, the name of the database that the domain is defined in (always the current database), else null. |
If the column has a domain type, the name of the schema that the domain is defined in, else null. |
If the column has a domain type, the name of the domain, else null. |
Name of the database that the column data type (the underlying type of the domain, if applicable) is defined in (always the current database) |
Name of the schema that the column data type (the underlying type of the domain, if applicable) is defined in |
Name of the column data type (the underlying type of the domain, if applicable) |
Applies to a feature not available in Postgres Pro |
Applies to a feature not available in Postgres Pro |
Applies to a feature not available in Postgres Pro |
Always null, because arrays always have unlimited maximum cardinality in Postgres Pro |
An identifier of the data type descriptor of the column, unique among the data type descriptors pertaining to the table. This is mainly useful for joining with other instances of such identifiers. (The specific format of the identifier is not defined and not guaranteed to remain the same in future versions.) |
Applies to a feature not available in Postgres Pro |
If the column is an identity column, then |
If the column is an identity column, then |
If the column is an identity column, then the start value of the internal sequence, else null. |
If the column is an identity column, then the increment of the internal sequence, else null. |
If the column is an identity column, then the maximum value of the internal sequence, else null. |
If the column is an identity column, then the minimum value of the internal sequence, else null. |
If the column is an identity column, then |
If the column is a generated column, then |
If the column is a generated column, then the generation expression, else null. |
|
Since data types can be defined in a variety of ways in SQL, and Postgres Pro contains additional ways to define data types, their representation in the information schema can be somewhat difficult. The column data_type
is supposed to identify the underlying built-in type of the column. In Postgres Pro, this means that the type is defined in the system catalog schema pg_catalog
. This column might be useful if the application can handle the well-known built-in types specially (for example, format the numeric types differently or use the data in the precision columns). The columns udt_name
, udt_schema
, and udt_catalog
always identify the underlying data type of the column, even if the column is based on a domain. (Since Postgres Pro treats built-in types like user-defined types, built-in types appear here as well. This is an extension of the SQL standard.) These columns should be used if an application wants to process data differently according to the type, because in that case it wouldn't matter if the column is really based on a domain. If the column is based on a domain, the identity of the domain is stored in the columns domain_name
, domain_schema
, and domain_catalog
. If you want to pair up columns with their associated data types and treat domains as separate types, you could write coalesce(domain_name, udt_name)
, etc.