| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Lætitia Avrot <laetitia(dot)avrot(at)gmail(dot)com> |
| Cc: | bpd0018(at)gmail(dot)com, vik(dot)fearing(at)2ndquadrant(dot)com, coelho(at)cri(dot)ensmp(dot)fr, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Constraint documentation |
| Date: | 2018-08-10 10:27:49 |
| Message-ID: | 9a9ec8f7-fee7-1a55-8fa8-6967517c6016@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2018-08-10 10:37:55 | Re: Doc patch for index access method function |
| Previous Message | Daniel Verite | 2018-08-10 10:25:49 | Re: csv format for psql |