| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Joel Jacobson <joel(at)trustly(dot)com> |
| Cc: | Vik Reykja <vikreykja(at)gmail(dot)com>, Michael Glaesemann <grzm(at)seespotcode(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Schema version management |
| Date: | 2012-07-05 16:09:10 |
| Message-ID: | 27144.1341504550@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Joel Jacobson <joel(at)trustly(dot)com> writes:
> On Thu, Jul 5, 2012 at 4:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> pg_dump is already a bloated, nearly unmaintainable mess. The very
>> last thing it needs is even more options.
> If you are referring to the code, I don't think that's a good argument
> against implementing new good features.
> The important ratio is the value of a feature compared to the increased
> complexity.
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christopher Browne | 2012-07-05 16:10:09 | Re: Schema version management |
| Previous Message | Joel Jacobson | 2012-07-05 16:05:10 | Re: Schema version management |