| From: | Daniel Farina <daniel(at)heroku(dot)com> |
|---|---|
| To: | Joel Jacobson <joel(at)trustly(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Schema version management |
| Date: | 2012-05-21 01:08:18 |
| Message-ID: | CAAZKuFapynzGfhrmEDoerTzdW+voXTtCGsOsQO0aao1=L0PzmA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, May 20, 2012 at 12:41 PM, Joel Jacobson <joel(at)trustly(dot)com> wrote:
> Hi,
>
> I just read a very interesting post about "schema version management".
>
> Quote: "You could set it up so that every developer gets their own
> test database, sets up the schema there, takes a dump, and checks that
> in. There are going to be problems with that, including that dumps
> produced by pg_dump are ugly and optimized for restoring, not for
> developing with, and they don't have a deterministic output order." (
> http://petereisentraut.blogspot.com/2012/05/my-anti-take-on-database-schema-version.html
> )
I think you are absolutely right, but I'm not sure if teaching pg_dump
a new option is the best idea. It's a pretty complex program as-is.
I've also heard some people who really wish pg knew how to self-dump
for valid reasons.
It sounds like some of the catalog wrangling and cycle-breaking
properties of pg_dump could benefit from being exposed stand-alone,
but unfortunately that's not a simple task, especially if you want to
do The Right Thing and have pg_dump link that code, given pg_dump's
criticality.
pg_extractor is a new/alternative take on the database copying
problem, maybe you could have a look at that?
--
fdr
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joel Jacobson | 2012-05-21 02:36:56 | Re: Schema version management |
| Previous Message | Robert Haas | 2012-05-20 23:57:06 | Re: Why is indexonlyscan so darned slow? |