Re: Constraint documentation
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Lætitia Avrot <laetitia.avrot@gmail.com>, bpd0018@gmail.com
Cc: vik.fearing@2ndquadrant.com, coelho@cri.ensmp.fr,
pgsql-hackers@lists.postgresql.org
Date: 2018-06-27T06:44:15Z
Lists: pgsql-hackers
On 6/26/18 09:49, Lætitia Avrot wrote: > + <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. But triggers are also used as an implementation detail of constraints. While it currently doesn't exist, a deferrable check constraint would probably be implemented as a trigger. 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. 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. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Clarify that cross-row constraints are unsupported
- 36d442a25a1a 12.0 landed