Re: Schema version management

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

In response to

Responses

Browse pgsql-hackers by date

  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?