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 |
Message-ID: | cda2f7e2-cc6d-1504-9ede-5af88cbf4335@francelle.name |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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 |
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 |