Tom Lane wrote: > Jesper Krogh <jesper@xxxxxxxx> writes: >> Tom Lane wrote: >>> Drop the constraints in the source database. > >> That would be my workaround for the problem. But isn't it somehow >> desirable that pg_dumpall | psql "allways" would work? > > Well, sure. The reason why this sort of thing is deprecated is exactly > that the database can't promise it will work all the time. The DB has > no way to know that your constraints do something they're not supposed > to, and in particular no way to infer that there's a specific data > loading order needed to keep the constraint from failing. No, it should just prospone, both constraints and triggers to the end of the dump (no magic here). This is not different from triggers in general. When you need to dump with --disable-triggers, you by yourself ensure that your contraint was fulfilled before you dumped / disabled triggeres. Then load the data and enabled the triggers again. The database cant enable usual foreing-key constraints before it have the complete dataset either. In this case the DB cant promise anything either. (unless it actually runs the complete set of checks at "enable time", which it might as well should be able to do with the stuff in the triggers. The only difference is that this is per-table(disable-dump-enable) and not dump-wide. > We do allow you to do it, but if it breaks you get to keep both pieces. What would be the preferred way of enabling some sort of timetravelling on a database, where the usual foreing-key constraints (data-integrity) should be preserved? Our setup is inspired by: http://www.varlena.com/GeneralBits/122.php But it nicely jumps straight over foreing-keys. -- Jesper Krogh, jesper@xxxxxxxx ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
