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: | Raw Message | Whole Thread | 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? |