Re: Constraint documentation

From: Patrick Francelle <patrick(at)francelle(dot)name>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Pantelis Theodosiou <ypercube(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Lætitia Avrot <laetitia(dot)avrot(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Brad DeJong <bpd0018(at)gmail(dot)com>, Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Constraint documentation
Date: 2018-11-02 18:41:21
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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.

Attachment Content-Type Size
check_constraint_accross_table_note_v5.patch text/x-patch 1.0 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-11-02 18:49:13 Re: partitioned indexes and tablespaces
Previous Message Paul Ramsey 2018-11-02 18:25:15 Re: Compressed TOAST Slicing