On Fri, Jan 08, 2016 at 12:53:24PM -0500, Tom Lane wrote: > Hm. So, by having installed this function as a check constraint, you have > created a data dependency that pg_dump has no way to know about. It's > going to load the tables in some order that's chosen without regard to the > need for dem.staff to be populated first. This is not a pg_dump bug. > > In general, embedding lookups of other tables into CHECK constraints > is going to cause you all kinds of grief quite aside from pg_dump > not understanding it, because the backend doesn't really understand it > either. If the other table changes, causing the CHECK expression to > fail, that will *not* cause anything to happen to the table with the > CHECK constraint. It could well be that pg_dump is loading the tables > in the right order by chance, and the reason you're seeing a failure > is that one or more rows have modified_by values corresponding to > people who no longer are in the staff table. > > Can you get rid of dem.staff in favor of something like creating a > "staff" role and GRANT'ing that to appropriate users? > > Alternatively, maybe you can make the modified_by column be a foreign > key referencing a table of users (it probably couldn't be defined > quite like "staff", but you get the idea). The presence of the foreign > key would be enough to cue pg_dump about load order. Just a crazy thought: If I create a foreign key from *.*.modified_by towards dem.staff.db_user but then DISABLE that FK -- would that still cue in pg_dump to order the tables appropriately ? Thanks, Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
