mirror of
https://github.com/postgres/postgres.git
synced 2025-09-02 04:21:28 +03:00
Allow CHECK constraints to be placed on foreign tables.
As with NOT NULL constraints, we consider that such constraints are merely reports of constraints that are being enforced by the remote server (or other underlying storage mechanism). Their only real use is to allow planner optimizations, for example in constraint-exclusion checks. Thus, the code changes here amount to little more than removal of the error that was formerly thrown for applying CHECK to a foreign table. (In passing, do a bit of cleanup of the ALTER FOREIGN TABLE reference page, which had accumulated some weird decisions about ordering etc.) Shigeru Hanada and Etsuro Fujita, reviewed by Kyotaro Horiguchi and Ashutosh Bapat.
This commit is contained in:
@@ -19,7 +19,8 @@
|
||||
<refsynopsisdiv>
|
||||
<synopsis>
|
||||
CREATE FOREIGN TABLE [ IF NOT EXISTS ] <replaceable class="PARAMETER">table_name</replaceable> ( [
|
||||
<replaceable class="PARAMETER">column_name</replaceable> <replaceable class="PARAMETER">data_type</replaceable> [ OPTIONS ( <replaceable class="PARAMETER">option</replaceable> '<replaceable class="PARAMETER">value</replaceable>' [, ... ] ) ] [ COLLATE <replaceable>collation</replaceable> ] [ <replaceable class="PARAMETER">column_constraint</replaceable> [ ... ] ]
|
||||
{ <replaceable class="PARAMETER">column_name</replaceable> <replaceable class="PARAMETER">data_type</replaceable> [ OPTIONS ( <replaceable class="PARAMETER">option</replaceable> '<replaceable class="PARAMETER">value</replaceable>' [, ... ] ) ] [ COLLATE <replaceable>collation</replaceable> ] [ <replaceable class="PARAMETER">column_constraint</replaceable> [ ... ] ]
|
||||
| <replaceable>table_constraint</replaceable> }
|
||||
[, ... ]
|
||||
] )
|
||||
SERVER <replaceable class="parameter">server_name</replaceable>
|
||||
@@ -30,7 +31,13 @@ CREATE FOREIGN TABLE [ IF NOT EXISTS ] <replaceable class="PARAMETER">table_name
|
||||
[ CONSTRAINT <replaceable class="PARAMETER">constraint_name</replaceable> ]
|
||||
{ NOT NULL |
|
||||
NULL |
|
||||
CHECK ( <replaceable class="PARAMETER">expression</replaceable> ) |
|
||||
DEFAULT <replaceable>default_expr</replaceable> }
|
||||
|
||||
<phrase>and <replaceable class="PARAMETER">table_constraint</replaceable> is:</phrase>
|
||||
|
||||
[ CONSTRAINT <replaceable class="PARAMETER">constraint_name</replaceable> ]
|
||||
CHECK ( <replaceable class="PARAMETER">expression</replaceable> )
|
||||
</synopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
@@ -137,6 +144,28 @@ CREATE FOREIGN TABLE [ IF NOT EXISTS ] <replaceable class="PARAMETER">table_name
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><literal>CHECK ( <replaceable class="PARAMETER">expression</replaceable> )</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The <literal>CHECK</> clause specifies an expression producing a
|
||||
Boolean result which each row in the foreign table is expected
|
||||
to satisfy; that is, the expression should produce TRUE or UNKNOWN,
|
||||
never FALSE, for all rows in the foreign table.
|
||||
A check constraint specified as a column constraint should
|
||||
reference that column's value only, while an expression
|
||||
appearing in a table constraint can reference multiple columns.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Currently, <literal>CHECK</literal> expressions cannot contain
|
||||
subqueries nor refer to variables other than columns of the
|
||||
current row. The system column <literal>tableoid</literal>
|
||||
may be referenced, but not any other system column.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><literal>DEFAULT
|
||||
<replaceable>default_expr</replaceable></literal></term>
|
||||
@@ -187,6 +216,40 @@ CREATE FOREIGN TABLE [ IF NOT EXISTS ] <replaceable class="PARAMETER">table_name
|
||||
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Notes</title>
|
||||
|
||||
<para>
|
||||
Constraints on foreign tables (such as <literal>CHECK</>
|
||||
or <literal>NOT NULL</> clauses) are not enforced by the
|
||||
core <productname>PostgreSQL</> system, and most foreign data wrappers
|
||||
do not attempt to enforce them either; that is, the constraint is
|
||||
simply assumed to hold true. There would be little point in such
|
||||
enforcement since it would only apply to rows inserted or updated via
|
||||
the foreign table, and not to rows modified by other means, such as
|
||||
directly on the remote server. Instead, a constraint attached to a
|
||||
foreign table should represent a constraint that is being enforced by
|
||||
the remote server.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Some special-purpose foreign data wrappers might be the only access
|
||||
mechanism for the data they access, and in that case it might be
|
||||
appropriate for the foreign data wrapper itself to perform constraint
|
||||
enforcement. But you should not assume that a wrapper does that
|
||||
unless its documentation says so.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Although <productname>PostgreSQL</> does not attempt to enforce
|
||||
constraints on foreign tables, it does assume that they are correct
|
||||
for purposes of query optimization. If there are rows visible in the
|
||||
foreign table that do not satisfy a declared constraint, queries on
|
||||
the table might produce incorrect answers. It is the user's
|
||||
responsibility to ensure that the constraint definition matches
|
||||
reality.
|
||||
</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1 id="SQL-CREATEFOREIGNTABLE-examples">
|
||||
<title>Examples</title>
|
||||
|
Reference in New Issue
Block a user