Re: Schema version management
От | Daniel Farina |
---|---|
Тема | Re: Schema version management |
Дата | |
Msg-id | CAAZKuFapynzGfhrmEDoerTzdW+voXTtCGsOsQO0aao1=L0PzmA@mail.gmail.com обсуждение исходный текст |
Ответ на | Schema version management (Joel Jacobson <joel@trustly.com>) |
Ответы |
Re: Schema version management
|
Список | pgsql-hackers |
On Sun, May 20, 2012 at 12:41 PM, Joel Jacobson <joel@trustly.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
В списке pgsql-hackers по дате отправления: