database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-12-21 05:21:08 +03:00
Code Activity

Don't use SGML empty tags

Browse Source 
For DocBook XML compatibility, don't use SGML empty tags (</>) anymore,
replace by the full tag name.  Add a warning option to catch future
occurrences.

Alexander Lakhin, Jürgen Purtz
This commit is contained in:
Peter Eisentraut
2017-10-08 21:44:17 -04:00
parent 6ecabead4b
commit c29c578908
337 changed files with 31636 additions and 31635 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
doc/src/sgml/ref/create_domain.sgml
View File

@@ -45,7 +45,7 @@ CREATE DOMAIN <replaceable class="parameter">name</replaceable> [ AS ] <replacea
<para>
If a schema name is given (for example, <literal>CREATE DOMAIN
myschema.mydomain ...</>) then the domain is created in the
myschema.mydomain ...</literal>) 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.
@@ -95,7 +95,7 @@ CREATE DOMAIN <replaceable class="parameter">name</replaceable> [ AS ] <replacea
<para>
An optional collation for the domain. If no collation is
specified, the underlying data type's default collation is used.
The underlying type must be collatable if <literal>COLLATE</>
The underlying type must be collatable if <literal>COLLATE</literal>
is specified.
</para>
</listitem>
@@ -106,7 +106,7 @@ CREATE DOMAIN <replaceable class="parameter">name</replaceable> [ AS ] <replacea
<listitem>
<para>
The <literal>DEFAULT</> clause specifies a default value for
The <literal>DEFAULT</literal> 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
@@ -136,7 +136,7 @@ CREATE DOMAIN <replaceable class="parameter">name</replaceable> [ AS ] <replacea
</varlistentry>
<varlistentry>
<term><literal>NOT NULL</></term>
<term><literal>NOT NULL</literal></term>
<listitem>
<para>
Values of this domain are prevented from being null
@@ -146,7 +146,7 @@ CREATE DOMAIN <replaceable class="parameter">name</replaceable> [ AS ] <replacea
</varlistentry>
<varlistentry>
<term><literal>NULL</></term>
<term><literal>NULL</literal></term>
<listitem>
<para>
Values of this domain are allowed to be null. This is the default.
@@ -163,10 +163,10 @@ CREATE DOMAIN <replaceable class="parameter">name</replaceable> [ AS ] <replacea
<varlistentry>
<term><literal>CHECK (<replaceable class="parameter">expression</replaceable>)</literal></term>
<listitem>
<para><literal>CHECK</> clauses specify integrity constraints or tests
<para><literal>CHECK</literal> 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</>
producing a Boolean result. It should use the key word <literal>VALUE</literal>
to refer to the value being tested. Expressions evaluating
to TRUE or UNKNOWN succeed. If the expression produces a FALSE result,
an error is reported and the value is not allowed to be converted
@@ -175,13 +175,13 @@ CREATE DOMAIN <replaceable class="parameter">name</replaceable> [ AS ] <replacea
<para>
Currently, <literal>CHECK</literal> expressions cannot contain
subqueries nor refer to variables other than <literal>VALUE</>.
subqueries nor refer to variables other than <literal>VALUE</literal>.
</para>
<para>
When a domain has multiple <literal>CHECK</literal> constraints,
they will be tested in alphabetical order by name.
(<productname>PostgreSQL</> versions before 9.5 did not honor any
(<productname>PostgreSQL</productname> versions before 9.5 did not honor any
particular firing order for <literal>CHECK</literal> constraints.)
</para>
</listitem>
@@ -193,7 +193,7 @@ CREATE DOMAIN <replaceable class="parameter">name</replaceable> [ AS ] <replacea
<title>Notes</title>
<para>
Domain constraints, particularly <literal>NOT NULL</>, are checked when
Domain constraints, particularly <literal>NOT NULL</literal>, are checked when
converting a value to the domain type. It is possible for a column that
is nominally of the domain type to read as null despite there being such
a constraint. For example, this can happen in an outer-join query, if
@@ -211,7 +211,7 @@ INSERT INTO tab (domcol) VALUES ((SELECT domcol FROM tab WHERE false));
It is very difficult to avoid such problems, because of SQL's general
assumption that a null value is a valid value of every data type. Best practice
therefore is to design a domain's constraints so that a null value is allowed,
and then to apply column <literal>NOT NULL</> constraints to columns of
and then to apply column <literal>NOT NULL</literal> constraints to columns of
the domain type as needed, rather than directly to the domain type.
</para>
</refsect1>