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