This page in other versions: 9.1 / 9.2 / 9.3 / 9.4 / current (9.5)  |  Development versions: devel  |  Unsupported versions: 7.3 / 7.4 / 8.0 / 8.1 / 8.2 / 8.3 / 8.4 / 9.0



CREATE DOMAIN  --  define a new domain


CREATE DOMAIN domainname [AS] data_type
    [ DEFAULT default_expr ]
    [ constraint [ ... ] ]

where constraint is:

[ CONSTRAINT constraint_name ]



The name (optionally schema-qualified) of a domain to be created.


The underlying data type of the domain. This may include array specifiers. Refer to the User's Guide for further information about data types and arrays.

DEFAULT default_expr

The DEFAULT clause specifies a default value for columns of the domain data type. The value is any variable-free expression (but subselects are not allowed). The data type of the default expression must match the data type of the domain.

The default expression will be used in any insert operation that does not specify a value for the column. If there is no default for a domain, then the default is NULL.

Note: If a default value is specified for a particular column, it overrides any default associated with the domain. In turn, the domain default overrides any default value associated with the underlying data type.

CONSTRAINT constraint_name

An optional name for a constraint. If not specified, the system generates a name.


Values of this domain are not allowed to be NULL.


Values of this domain are allowed to be NULL. This is the default.

This clause is only available for compatibility with non-standard SQL databases. Its use is discouraged in new applications.



Message returned if the domain is successfully created.


CREATE DOMAIN allows the user to register a new data domain with PostgreSQL for use in the current data base. The user who defines a domain becomes its owner.

If a schema name is given (for example, CREATE DOMAIN myschema.mydomain ...) then the domain is created in the specified schema. Otherwise it is created in the current schema (the one at the front of the search path; see CURRENT_SCHEMA()). The domain name must be unique among the types and domains existing in its schema.

Domains are useful for abstracting common fields between tables into a single location for maintenance. An email address column may be used in several tables, all with the same properties. Define a domain and use that rather than setting up each table's constraints individually.


This example creates the country_code data type and then uses the type in a table definition:

CREATE DOMAIN country_code char(2) NOT NULL;
CREATE TABLE countrylist (id INT4, country country_code);


SQL99 defines CREATE DOMAIN, but says that the only allowed constraint type is CHECK constraints. CHECK constraints for domains are not yet supported by PostgreSQL.

See Also

DROP DOMAIN, PostgreSQL Programmer's Guide


June 23, 2003, 6:06 p.m.

Note that domains seem to have serious issues in versions <7.3.3 which prevent them from being useful. For example, explicit column casts are necessary for some operators usage. I recommend upgrading to 7.3.3 in order to avert such bugs.

July 23, 2003, 5:27 p.m.

Don\'t be misled by the strange name (domain): domains are really a fancy way of saying \'create a special type based on one of the built in types\'. They are incredibly useful!

When 7.4 comes out (hopefully by the end of this month), domains will get the ablity to do CHECK constraints along with other improvements. Lack of this feature is the only reason why not to use domains.

For example:
create domain phone_number char(13) not null
check (phone_number ~ \'\\\\([0-9](3)\\\\)[0-9])(3)-[0-9](4)]\');

This creates a phone number type that validates incoming data to conform to (999)999-9999. Now you can do:

create table my_table
contact_number phone_number,

Domains are in that class of features (like views and referential integrity) that are crucial to strong database design, especially for complex databases. They bring numerous benifits to your database:
1. insulation from non-standard SQL types
2. elegant syntax
3. heplful in creating flexible schema
4. help prevent stupid design consderidations when construction schema (like only allowing 15 characters for email).


Privacy Policy | About PostgreSQL
Copyright © 1996-2016 The PostgreSQL Global Development Group