SYSTEM CATALOG · System catalog

pg_type

PostgreSQL documentation ↗Source definition ↗

The catalog pg_type stores information about data types. Base types and enum types (scalar types) are created with CREATE TYPE, and domains with CREATE DOMAIN. A composite type is automatically created for each table in the database, to represent the row structure of the table. It is also possible to create composite types with CREATE TYPE AS.

First seen PG 9.0Last seen PG 19Columns 32

9.0 9.1 9.2 9.3 9.4 9.5 9.6 10 11 12 13 14 15 16 17 18 19^β3

Checked column by column against a PostgreSQL 18.6 instance · Raw measurement record ↗

Columns PostgreSQL 18

pg_type

COLUMN	TYPE	DESCRIPTION
`oid`	`oid`NOT NULL	Row identifier
`typname`	`name`NOT NULL	Data type name
`typnamespace`	`oid`NOT NULL	The OID of the namespace that contains this typeReferences:`pg_namespace.oid`
`typowner`	`oid`NOT NULL	Owner of the typeReferences:`pg_authid.oid`
`typlen`	`smallint`NOT NULLDocumented as:`int2`	For a fixed-size type, typlen is the number of bytes in the internal representation of the type. But for a variable-length type, typlen is negative. -1 indicates a “varlena” type (one that has a length word), -2 indicates a null-terminated C string.
`typbyval`	`boolean`NOT NULLDocumented as:`bool`	typbyval determines whether internal routines pass a value of this type by value or by reference. typbyval had better be false if typlen is not 1, 2, or 4 (or 8 on machines where Datum is 8 bytes). Variable-length types are always passed by reference. Note that typbyval can be false even if the length would allow pass-by-value.
`typtype`	`"char"`NOT NULLDocumented as:`char`	typtype is b for a base type, c for a composite type (e.g., a table's row type), d for a domain, e for an enum type, p for a pseudo-type, r for a range type, or m for a multirange type. See also typrelid and typbasetype.
`typcategory`	`"char"`NOT NULLDocumented as:`char`	typcategory is an arbitrary classification of data types that is used by the parser to determine which implicit casts should be “preferred”. See Table 52.65.
`typispreferred`	`boolean`NOT NULLDocumented as:`bool`	True if the type is a preferred cast target within its typcategory
`typisdefined`	`boolean`NOT NULLDocumented as:`bool`	True if the type is defined, false if this is a placeholder entry for a not-yet-defined type. When typisdefined is false, nothing except the type name, namespace, and OID can be relied on.
`typdelim`	`"char"`NOT NULLDocumented as:`char`	Character that separates two values of this type when parsing array input. Note that the delimiter is associated with the array element data type, not the array data type.
`typrelid`	`oid`NOT NULL	If this is a composite type (see typtype), then this column points to the pg_class entry that defines the corresponding table. (For a free-standing composite type, the pg_class entry doesn't really represent a table, but it is needed anyway for the type's pg_attribute entries to link to.) Zero for non-composite types.References:`pg_class.oid`
`typsubscript`	`regproc`NOT NULL	Subscripting handler function's OID, or zero if this type doesn't support subscripting. Types that are “true” array types have typsubscript = array_subscript_handler, but other types may have other handler functions to implement specialized subscripting behavior.References:`pg_proc.oid`
`typelem`	`oid`NOT NULL	If typelem is not zero then it identifies another row in pg_type, defining the type yielded by subscripting. This should be zero if typsubscript is zero. However, it can be zero when typsubscript isn't zero, if the handler doesn't need typelem to determine the subscripting result type. Note that a typelem dependency is considered to imply physical containment of the element type in this type; so DDL changes on the element type might be restricted by the presence of this type.References:`pg_type.oid`
`typarray`	`oid`NOT NULL	If typarray is not zero then it identifies another row in pg_type, which is the “true” array type having this type as elementReferences:`pg_type.oid`
`typinput`	`regproc`NOT NULL	Input conversion function (text format)References:`pg_proc.oid`
`typoutput`	`regproc`NOT NULL	Output conversion function (text format)References:`pg_proc.oid`
`typreceive`	`regproc`NOT NULL	Input conversion function (binary format), or zero if noneReferences:`pg_proc.oid`
`typsend`	`regproc`NOT NULL	Output conversion function (binary format), or zero if noneReferences:`pg_proc.oid`
`typmodin`	`regproc`NOT NULL	Type modifier input function, or zero if type does not support modifiersReferences:`pg_proc.oid`
`typmodout`	`regproc`NOT NULL	Type modifier output function, or zero to use the standard formatReferences:`pg_proc.oid`
`typanalyze`	`regproc`NOT NULL	Custom ANALYZE function, or zero to use the standard functionReferences:`pg_proc.oid`
`typalign`	`"char"`NOT NULLDocumented as:`char`	typalign is the alignment required when storing a value of this type. It applies to storage on disk as well as most representations of the value inside PostgreSQL. When multiple values are stored consecutively, such as in the representation of a complete row on disk, padding is inserted before a datum of this type so that it begins on the specified boundary. The alignment reference is the beginning of the first datum in the sequence. Possible values are:
`typstorage`	`"char"`NOT NULLDocumented as:`char`	typstorage tells for varlena types (those with typlen = -1) if the type is prepared for toasting and what the default strategy for attributes of this type should be. Possible values are: x is the usual choice for toast-able types. Note that m values can also be moved out to secondary storage, but only as a last resort (e and x values are moved first).
`typnotnull`	`boolean`NOT NULLDocumented as:`bool`	typnotnull represents a not-null constraint on a type. Used for domains only.
`typbasetype`	`oid`NOT NULL	If this is a domain (see typtype), then typbasetype identifies the type that this one is based on. Zero if this type is not a domain.References:`pg_type.oid`
`typtypmod`	`integer`NOT NULLDocumented as:`int4`	Domains use typtypmod to record the typmod to be applied to their base type (-1 if base type does not use a typmod). -1 if this type is not a domain.
`typndims`	`integer`NOT NULLDocumented as:`int4`	typndims is the number of array dimensions for a domain over an array (that is, typbasetype is an array type). Zero for types other than domains over array types.
`typcollation`	`oid`NOT NULL	typcollation specifies the collation of the type. If the type does not support collations, this will be zero. A base type that supports collations will have a nonzero value here, typically DEFAULT_COLLATION_OID. A domain over a collatable type can have a collation OID different from its base type's, if one was specified for the domain.References:`pg_collation.oid`
`typdefaultbin`	`pg_node_tree`	If typdefaultbin is not null, it is the nodeToString() representation of a default expression for the type. This is only used for domains.
`typdefault`	`text`	typdefault is null if the type has no associated default value. If typdefaultbin is not null, typdefault must contain a human-readable version of the default expression represented by typdefaultbin. If typdefaultbin is null and typdefault is not, then typdefault is the external representation of the type's default value, which can be fed to the type's input converter to produce a constant.
`typacl`	`aclitem[]`	Access privileges; see Section 5.8 for details

Columns marked "implicit" are not included in SELECT *; some early statistics views are completed from same-version source, and the extra provenance is shown in the column description.

Common system columns 6

System attributes PostgreSQL provides, normally not expanded by SELECT *. Kept separately so they are not mixed in with ordinary columns.

Columns	Type	attnum
`tableoid`	`oid`	-6
`cmax`	`cid`	-5
`xmax`	`xid`	-4
`cmin`	`cid`	-3
`xmin`	`xid`	-2
`ctid`	`tid`	-1

Column evolution matrix

Hover a cell for the column type

PresentAdded / type or attribute changeRemoved

COLUMN	9.0	9.1	9.2	9.3	9.4	9.5	9.6	10	11	12	13
`oid`
`typname`
`typnamespace`
`typowner`
`typlen`
`typbyval`
`typtype`
`typcategory`
`typispreferred`
`typisdefined`
`typdelim`
`typrelid`
`typelem`
`typarray`
`typinput`
`typoutput`
`typreceive`
`typsend`
`typmodin`
`typmodout`
`typanalyze`
`typalign`
`typstorage`
`typnotnull`
`typbasetype`
`typtypmod`
`typndims`
`typdefaultbin`
`typdefault`
`typcollation`	–
`typacl`	–	–
`typsubscript`	–	–	–	–	–	–	–	–	–	–	–

9.0 is the coverage baseline; a column already present in the baseline is not marked as added. The matrix aligns columns by name, so a rename appears as the old column removed and a new column added.

Evolution timeline

Changes between adjacent majors

PostgreSQL 19 ← 18

2 column description updates

PostgreSQL 18 ← 17

1 column description updates

PostgreSQL 17 ← 16

2 column description updates

PostgreSQL 15 ← 14

1 column description updates

PostgreSQL 14 ← 13

+ typsubscript9 column description updates

PostgreSQL 13 ← 12

3 column description updates

PostgreSQL 12 ← 11

~ oid: implicit → ordinary4 column description updates

PostgreSQL 11 ← 10

1 column description updates

PostgreSQL 10 ← 9.6

6 column description updates

PostgreSQL 9.6 ← 9.5

1 column description updates

PostgreSQL 9.5 ← 9.4

1 column description updates

PostgreSQL 9.4 ← 9.3

1 column description updates

PostgreSQL 9.3 ← 9.2

2 column description updates

PostgreSQL 9.2 ← 9.1

+ typacl2 column description updates

PostgreSQL 9.1 ← 9.0

+ typcollation~ typdefaultbin: text → pg_node_tree3 column description updates

Compare any two versions

FROMTOInclude description updates

Pick two versions to see added, removed, and retyped columns. The interactive comparison needs JavaScript; the evolution timeline reads fine without it.