| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Aldrin Martoq Ahumada <aldrin(dot)martoq(at)gmail(dot)com> |
| Cc: | "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Postgresql upgrade to 9.5.12/10.3 changes pg_dump format for cloning schemas |
| Date: | 2018-03-09 14:22:11 |
| Message-ID: | CAKFQuwZVY81PXsZJBCir7HLax_wkfBpmmACku_znwcmA7Lon9g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Fri, Mar 9, 2018 at 6:26 AM, Aldrin Martoq Ahumada <
aldrin(dot)martoq(at)gmail(dot)com> wrote:
> Thinking in the long term, how could be the best way to clone a schema
> into another?
>
Depends on why you are cloning schemas.
Generally not cloning is the best bet - instead place the reference schema
into version control and simply install it whenever necessary.
Parameterize the installation script.
Or, clone into a different database and leave the namespace the same.
pg_dump, as currently written, is tasked with recreating the original
database exactly and safely. If you need it to do something different you
could teach it the desired behavior and add some relevant command line
switches to enable said behavior.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Herwin Weststrate | 2018-03-09 14:41:15 | Feature request: min/max for macaddr type |
| Previous Message | Aldrin Martoq Ahumada | 2018-03-09 13:26:28 | Postgresql upgrade to 9.5.12/10.3 changes pg_dump format for cloning schemas |