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.
On 08/10/18 07:02, Pantelis Theodosiou wrote:
>
> I like this:
>
>> "Postgres does not currently support CHECK constraints containing
> queries, therefore we recommend to avoid them."
>
> Perhaps adding:
>
>> CHECK constraints are currently meant to be used as *row constraints*
> only.
>> Use - if possible - UNIQUE or EXCLUDE constraints. for constraints
> that involve many or all rows of a table,
>> and FOREIGN KEY constraints for cross table constraints.
>> More complex constraints will be available when ASSERTION are implemented.
>
> And then adding some warning about using functions in CHECK constraints
> to bypass current limitations.
>
> Pantelis Theodsoiou
Hi,
I have rewritten the patch to include your remarks.
In fact, the whole patch is now based on it, so thank you.
Patrick Francelle