Hello Peter,
+ <note>
+ <para>
+ Check constraints are not designed to enforce business rules across
tables.
+ Avoid using check constraints with a function accessing other tables and
+ use <xref linkend="triggers"/> instead. Although PostgreSQL won't prevent
you
+ from doing so, beware that dumps generated by
<application>pg_dump</application>
+ or <application>pg_dumpall</application> may be hard
+ to restore because of such checks, as the underlying dependencies are not
+ taken into account.
+ </para>
+ </note>
In a way, I think this is attacking the wrong problem. It is saying
that you should use triggers instead of check constraints in certain
circumstances.
Yep. The circumstance is being able to dump & restore the database. If you
do not care about dump/restore, check constraints are always fine.
But triggers are also used as an implementation detail of constraints.
Yep.
It's not the triggerness that fixes this problem. The problem is more
generally that if a function uses a table, then pg_dump can't know about
the ordering.
Yep.
It happens to work for triggers because triggers are dumped after all
tables, as a performance optimization, and we could very well dump check
constraints differently as well.
Sure.
ISTM that is more or less what the text is saying?
I'm not sure what is the suggestion wrt to the documentation text. Is the
issue only with the first introductory sentence? Would removing it be
enough?
--
Fabien.
