↑↓ select ↵ open ⌫ change scope Open full search

PG.CENTER connects PostgreSQL documentation, reference, and ecosystem knowledge. Maintained by Pigsty.

Wiki / Data Types / Type families

Domains

A domain is a user-defined data type that is based on another underlying type . Optionally, it can have constraints that restrict its valid values to a subset of what the underlying type would allow. Otherwise it behaves like the underlying type — for example, any operator or function that can be applied to the underlying type will work on the domain type. The underlying type can be any built-in or user-defined base type, enum type, array type, composite type, range type, or another domain.

Reading PostgreSQL 18.6.

PG10–20 core source inventory. Casts and operator classes show explicitly declared relationships; absent rows do not rule out coercions or indexing through other mechanisms.

Definition

A domain is a user-defined data type that is based on another underlying type . Optionally, it can have constraints that restrict its valid values to a subset of what the underlying type would allow. Otherwise it behaves like the underlying type — for example, any operator or function that can be applied to the underlying type will work on the domain type. The underlying type can be any built-in or user-defined base type, enum type, array type, composite type, range type, or another domain.

Domains
Object boundary
User-defined type family; not a finite list of user objects

English manual

Read the complete manual section

Read the source definition

8.18. Domain Types

A domain is a user-defined data type that is based on another underlying type. Optionally, it can have constraints that restrict its valid values to a subset of what the underlying type would allow. Otherwise it behaves like the underlying type — for example, any operator or function that can be applied to the underlying type will work on the domain type. The underlying type can be any built-in or user-defined base type, enum type, array type, composite type, range type, or another domain.

For example, we could create a domain over integers that accepts only positive integers:

CREATE DOMAIN posint AS integer CHECK (VALUE > 0);
CREATE TABLE mytable (id posint);
INSERT INTO mytable VALUES(1);   -- works
INSERT INTO mytable VALUES(-1);  -- fails

When an operator or function of the underlying type is applied to a domain value, the domain is automatically down-cast to the underlying type. Thus, for example, the result of mytable.id - 1 is considered to be of type integer not posint. We could write (mytable.id - 1)::posint to cast the result back to posint, causing the domain's constraints to be rechecked. In this case, that would result in an error if the expression had been applied to an id value of 1. Assigning a value of the underlying type to a field or variable of the domain type is allowed without writing an explicit cast, but the domain's constraints will be checked.

For additional information see CREATE DOMAIN.

Version comparison

PostgreSQL 17.11 → 18.6. Source build identifiers and prose are excluded from attribute changes.

No catalog or structured attribute changes between these samples.

The documentation also differs between these builds; inspect the versioned manual definitions.

Documentation and source

Build
18.6 · https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2
Fingerprint
555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f

All Data Types · Download this version as JSON · The first recorded sample does not establish when a type was introduced.