On Fri, Aug 10, 2018 at 12:27:49PM +0200, Peter Eisentraut wrote: > On 09/08/2018 23:32, Alvaro Herrera wrote: > > I agree that we should point this out in *some* way, just not sure how. > > Maybe something like "Postgres does not currently support CHECK > > constraints containing queries, therefore we recommend to avoid them." > > I would not mention pg_dump by name, just say dumps may not restore > > depending on phase of moon. > > I think it would be very easy to restore check constraints separately > after all tables in pg_dump. There is already support for that, but > it's only used when necessary, for things like not-valid constraints. > The argument in favor of keeping the constraint with the table is > probably only aesthetics, but of course the argument against is that it > sometimes doesn't work. So we could either enhance the smarts about > when to use the "dump separately" path (this might be difficult), or > just use it always.
+1 for dumping all constraints separately by default. Currently, it's possible to create unrestorable databases without fiddling with the catalog, as a legacy database I was dealing with just last week demonstrated. It occurs to me that the aesthetic issues might be dealt with by having a separate "aesthetic" restore mode, which is to say what you'd expect if you were writing the schema code /de novo/. This would be non-trivial to get right in some cases, and flat-out impossible for cases where we can't see into the code that could produce a dependency. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
