On Sun, May 20, 2012 at 12:41 PM, Joel Jacobson <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
