From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Lætitia Avrot <laetitia(dot)avrot(at)gmail(dot)com> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Constraint documentation |
Date: | 2018-06-23 17:15:35 |
Message-ID: | alpine.DEB.2.21.1806231902391.1087@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello lætitia,
My 0.02 € to try to simplify the suggested documentation.
> Check constraint were not
are not
> designed to enforce business rules across tables.
> Avoid using check constraints with function accessing to other tables
accessing other tables (no "to")
> and prefer triggers instead (please refer to <xref linkend="triggers"/>
> for more information about triggers).
... and use <xref linkend="triggers"/> instead.
> PostgreSQL won't prevent you from doing so,
Although PostgreSQL ... so,
> but be aware you might encounter difficulties to restore dumps
> (generated with pg_dump or pg_dumpall) if you do.
beware that dumps generated by <application>pg_*<...> or <...> may be hard
to restore because of such checks, as the underlying dependencies are not
taken into account.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2018-06-23 17:23:08 | postgresql_fdw doesn't handle defaults correctly |
Previous Message | Vik Fearing | 2018-06-23 15:23:30 | Re: Adding Markodwn formatting to psql output |