|
|
|
<!--
|
|
|
|
doc/src/sgml/ref/create_domain.sgml
|
|
|
|
PostgreSQL documentation
|
|
|
|
-->
|
|
|
|
|
|
|
|
<refentry id="SQL-CREATEDOMAIN">
|
|
|
|
<refmeta>
|
|
|
|
<refentrytitle>CREATE DOMAIN</refentrytitle>
|
|
|
|
<manvolnum>7</manvolnum>
|
|
|
|
<refmiscinfo>SQL - Language Statements</refmiscinfo>
|
|
|
|
</refmeta>
|
|
|
|
|
|
|
|
<refnamediv>
|
|
|
|
<refname>CREATE DOMAIN</refname>
|
|
|
|
<refpurpose>define a new domain</refpurpose>
|
|
|
|
</refnamediv>
|
|
|
|
|
|
|
|
<indexterm zone="sql-createdomain">
|
|
|
|
<primary>CREATE DOMAIN</primary>
|
|
|
|
</indexterm>
|
|
|
|
|
|
|
|
<refsynopsisdiv>
|
|
|
|
<synopsis>
|
|
|
|
CREATE DOMAIN <replaceable class="parameter">name</replaceable> [ AS ] <replaceable class="parameter">data_type</replaceable>
|
|
|
|
[ COLLATE <replaceable>collation</replaceable> ]
|
|
|
|
[ DEFAULT <replaceable>expression</replaceable> ]
|
|
|
|
[ <replaceable class="PARAMETER">constraint</replaceable> [ ... ] ]
|
|
|
|
|
|
|
|
<phrase>where <replaceable class="PARAMETER">constraint</replaceable> is:</phrase>
|
|
|
|
|
|
|
|
[ CONSTRAINT <replaceable class="PARAMETER">constraint_name</replaceable> ]
|
|
|
|
{ NOT NULL | NULL | CHECK (<replaceable class="PARAMETER">expression</replaceable>) }
|
|
|
|
</synopsis>
|
|
|
|
</refsynopsisdiv>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>Description</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
<command>CREATE DOMAIN</command> creates a new domain. A domain is
|
|
|
|
essentially a data type with optional constraints (restrictions on
|
|
|
|
the allowed set of values).
|
|
|
|
The user who defines a domain becomes its owner.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
If a schema name is given (for example, <literal>CREATE DOMAIN
|
|
|
|
myschema.mydomain ...</>) then the domain is created in the
|
|
|
|
specified schema. Otherwise it is created in the current schema.
|
|
|
|
The domain name must be unique among the types and domains existing
|
|
|
|
in its schema.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Domains are useful for abstracting common constraints on fields into
|
|
|
|
a single location for maintenance. For example, several tables might
|
|
|
|
contain email address columns, all requiring the same CHECK constraint
|
|
|
|
to verify the address syntax.
|
|
|
|
Define a domain rather than setting up each table's constraint
|
|
|
|
individually.
|
|
|
|
</para>
|
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>Parameters</title>
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable class="parameter">name</replaceable></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The name (optionally schema-qualified) of a domain to be created.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable class="PARAMETER">data_type</replaceable></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
Update reference documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
19 years ago
|
|
|
The underlying data type of the domain. This can include array
|
|
|
|
specifiers.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable>collation</replaceable></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
An optional collation for the domain. If no collation is
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
15 years ago
|
|
|
specified, the underlying data type's default collation is used.
|
|
|
|
The underlying type must be collatable if <literal>COLLATE</>
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
15 years ago
|
|
|
is specified.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term><literal>DEFAULT <replaceable>expression</replaceable></literal></term>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The <literal>DEFAULT</> clause specifies a default value for
|
|
|
|
columns of the domain data type. The value is any
|
|
|
|
variable-free expression (but subqueries are not allowed).
|
|
|
|
The data type of the default expression must match the data
|
|
|
|
type of the domain. If no default value is specified, then
|
|
|
|
the default value is the null value.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The default expression will be used in any insert operation
|
|
|
|
that does not specify a value for the column. If a default
|
|
|
|
value is defined 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.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term><literal>CONSTRAINT <replaceable class="PARAMETER">constraint_name</replaceable></literal></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
An optional name for a constraint. If not specified,
|
|
|
|
the system generates a name.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term><literal>NOT NULL</></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Values of this domain are normally prevented from being null.
|
|
|
|
However, it is still possible for a domain with this constraint
|
|
|
|
to take a null value if it is assigned a matching domain type
|
|
|
|
that has become null, e.g. via a LEFT OUTER JOIN, or
|
|
|
|
<command>INSERT INTO tab (domcol) VALUES ((SELECT domcol FROM
|
|
|
|
tab WHERE false))</command>.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term><literal>NULL</></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Values of this domain are allowed to be null. This is the default.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
This clause is only intended for compatibility with
|
|
|
|
nonstandard SQL databases. Its use is discouraged in new
|
|
|
|
applications.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term><literal>CHECK (<replaceable class="PARAMETER">expression</replaceable>)</literal></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
<literal>CHECK</> clauses specify integrity constraints or tests
|
|
|
|
which values of the domain must satisfy.
|
|
|
|
Each constraint must be an expression
|
|
|
|
producing a Boolean result. It should use the key word <literal>VALUE</>
|
|
|
|
to refer to the value being tested.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Currently, <literal>CHECK</literal> expressions cannot contain
|
|
|
|
subqueries nor refer to variables other than <literal>VALUE</>.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>Examples</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
This example creates the <type>us_postal_code</type> data type and
|
|
|
|
then uses the type in a table definition. A regular expression test
|
|
|
|
is used to verify that the value looks like a valid US postal code:
|
|
|
|
|
|
|
|
<programlisting>
|
|
|
|
CREATE DOMAIN us_postal_code AS TEXT
|
|
|
|
CHECK(
|
|
|
|
VALUE ~ '^\\d{5}$'
|
|
|
|
OR VALUE ~ '^\\d{5}-\\d{4}$'
|
|
|
|
);
|
|
|
|
|
|
|
|
CREATE TABLE us_snail_addy (
|
|
|
|
address_id SERIAL PRIMARY KEY,
|
|
|
|
street1 TEXT NOT NULL,
|
|
|
|
street2 TEXT,
|
|
|
|
street3 TEXT,
|
|
|
|
city TEXT NOT NULL,
|
|
|
|
postal us_postal_code NOT NULL
|
|
|
|
);
|
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1 id="SQL-CREATEDOMAIN-compatibility">
|
|
|
|
<title>Compatibility</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The command <command>CREATE DOMAIN</command> conforms to the SQL
|
|
|
|
standard.
|
|
|
|
</para>
|
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1 id="SQL-CREATEDOMAIN-see-also">
|
|
|
|
<title>See Also</title>
|
|
|
|
|
|
|
|
<simplelist type="inline">
|
|
|
|
<member><xref linkend="sql-alterdomain"></member>
|
|
|
|
<member><xref linkend="sql-dropdomain"></member>
|
|
|
|
</simplelist>
|
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
</refentry>
|