On Thu, Jul 5, 2012 at 6:09 PM, Tom Lane
<tgl@sss.pgh.pa.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.
