From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: integrate pg_upgrade analyze_new_cluster.sh into vacuumdb |
Date: | 2014-01-09 17:44:24 |
Message-ID: | 10483.1389289464@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Jan 8, 2014 at 10:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I don't think this vacuumdb feature should deal with any
>> version-conversion issues. So it sounds like the thing to do is keep the
>> wrapper script, which will give us a place to put any such special actions
>> without having to kluge up vacuumdb's behavior. That'll avoid breaking
>> scripts that users might've built for using pg_upgrade, too.
> I guess I don't see what's wrong with kludging up vacuumdb. It's not
> like that's a very complicated utility; what will be hurt by a few
> more options?
Carrying kluges forever, and exposing them to users' view. The particular
example Peter gave was only relevant to upgrades from 8.4; why would we be
putting code into vacuumdb now for that, and expecting to support it
forevermore? What if the code to fix up something doesn't even *work*
unless we're updating from version M.N? Putting such code into vacuumdb
means you have to make it bulletproof against other invocation
circumstances, and document what it does (since it's a user-visible
switch), and just in general greatly increases the development overhead.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Claudio Freire | 2014-01-09 17:46:03 | Re: [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL |
Previous Message | Florian Pflug | 2014-01-09 17:44:18 | Re: [PATCH] Negative Transition Aggregate Functions (WIP) |