| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | David Barron <david(dot)barron(at)zencos(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Backup strategy |
| Date: | 2024-02-28 16:52:43 |
| Message-ID: | CAKFQuwbXWNyT0zyZG7iL1wNLQUPitTJ89z6WAsWbmqJZXiA_6Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On Wed, Feb 28, 2024, 09:45 David Barron <david(dot)barron(at)zencos(dot)com> wrote:
>
> If, for example, table a has a constraint that references rows in table b,
> table b has to be restored first, but pg_dump doesn't take that into
> account. So the restore tries to restore table a first, but can't because
> table b contains no data. That's what I ran into in general terms.
>
It is illegal to write a check constraint that references another table.
It doesn't matter that hiding your illegal setup inside a back box function
prevents the system from stopping you. You need to fix your design so as
not to break the documented rules. Namely by using a trigger.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Barron | 2024-02-28 16:53:35 | RE: Backup strategy |
| Previous Message | Peter Geoghegan | 2024-02-28 16:50:53 | Re: Backup strategy |