Re: Schema version management

On Thu, Jul 5, 2012 at 6:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Well, to be perfectly frank, I already doubt that this entire feature
> passes the complexity-versus-value test, because pg_dump is not a
> substitute for an SCM --- people who have got enough functions to need
> this sort of thing need to be keeping them somewhere else than in dump
> files. Complicating things more by supporting multiple ways of doing it
> will make that worse. I think you need to pick one design and stick
> with it, not try to paint the bikeshed every color suggested by anybody.
>

I agree it should be one option only, and again I think the one file
variant is best.

This is indeed not a substitute for an SCM, but a nice complement.

Personally, I use this feature already to commit the schema for all versions
of my databases (production, test, development) into a git repo every
minute.
It only commits if something has changed.

This makes it super easy to compare the schema of the actual production
database
between different points in time.

This would not be possible if only manually committing stuff to the normal
git repo,
where I also have all the functions, which I modify when developing and
testing.

pg_dump -> git means you can be 100% certain version X of the schema was
active in the production database at date/time T.