On Thu, Jan 9, 2014 at 12:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Jan 8, 2014 at 10:32 PM, Tom Lane <tgl@sss.pgh.pa.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.
I was referring to the analyze-in-stages logic, which is not specific
to 8.4. I don't see a reason not to put that into vacuumdb.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
