Thanks for your remarks and advices, and of course for your help to
rewrite the text.
So, it is now included in the new version attached.
I hope it will be ok this time.
Patrick Francelle
On 10/30/18 17:14, David G. Johnston wrote:
> The product name, when used in the documentation, is "PostgreSQL" with
> appropriate html elements surrounding it.
>
> Some parts that look or read oddly to me:
> "you may expect troubles"
> Use - if possible - (commas, not hypens, are customary here)
> "does not currently" - drop "currently", it doesn't and we don't need
> to predict the future (same goes for "are currently meant")
> "therefore we recommend to avoid them" - they are unsupported, the
> implied recommended is to not use them period, not avoid them if
> possible. Better to say that it isn't enforced even though it is
> unsupported.
>
> An alternative to consider as one the whole the reading of the v4
> patch just feels off and different than the rest of that section of
> the documentation.
>
> PostgreSQL does not support writing CHECK constraints that reference
> tables (though it does not reliably prevent one from doing so). While
> normal operations are likely to succeed even if you violate this rule
> it is probable that a database restoration will fail. Use FOREIGN KEY
> constraints or custom triggers for cross-table validations. For rows
> on the same table you should use UNIQUE or EXCLUDE constraints when
> applicable, or a custom trigger otherwise.
>
> David J.
>
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index b5ed1b7939..142918e2b1 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -403,6 +403,20 @@ CREATE TABLE products (
ensure that a column does not contain null values, the not-null
constraint described in the next section can be used.
</para>
+
+ <note>
+ <para>
+ <productname>PostgreSQL</productname> does not support writing
+ <literal>CHECK</literal> constraints that reference tables (though it does
+ not reliably prevent one from doing so). While normal operations are
+ likely to succeed even if you violate this rule, it is probable that a
+ database restoration will fail. Use <literal>FOREIGN KEY</literal>
+ constraints or custom <link linkend="triggers">triggers</link> for
+ cross-table validations. For rows on the same table you should use
+ <literal>UNIQUE</literal> or <literal>EXCLUDE</literal> constraints when
+ applicable, or a custom trigger otherwise.
+ </para>
+ </note>
</sect2>
<sect2>
