Re: pg_utility ?

Hi Álvaro,

> One of the things that came up during the pgconf.eu talk about REPACK,
> proposed by Christoph Berg, is that adding another utility pg_repackdb
> to run it from the command line adds more noise to an already noisy tool
> neighbourhood. He asked, how about we instead add a generic tool to run
> utility commands? So the user would be able to do things such as
>
> pg_utility vacuum -t tab1 -t tab2 # what vacuumdb does
> pg_utility analyze -t tab1 -t tab2 # what vacuumdb -Z does
> pg_utility vacuum analyze -t tab1 -t tab2 # what vacuumdb -z does
> pg_utility cluster -t tab1 -t tab2 # what clusterdb does
> pg_utility reindex -t tab1 -t tab2 # what reindexdb does
>
> Each such tool would retain more or less its current behavior, i.e., its
> ability to run things in parallel, to discover tables to operate on
> based on circumstances, to silently ignore objects depending on the user
> lacking specific privilege bits, and so on.
>
> This way, instead of an entire pg_repackdb tool, we would add just a new
> mode to pg_utility:
>
> pg_utility repack -t tab1 -t tab2 # what pg_repackdb would do
>
> Christoph, can you please confirm that this is approximately what you
> had in mind? Other names are of course possible.
>
> I didn't immediately love this idea, but I'm not totally opposed to it
> either, and perhaps it makes things better rather than adding yet
> another very narrowly-focused tool. Also, pg_ctl already kinda has a
> somewhat similar facet with its "pg_ctl init" mode.

I'm not necessarily opposed to the idea in general, but I'm a bit
sceptical about the particular implementation. I fail to understand
the exact value of having "pg_utility (something)" instead of
"pg_(something)". To me it seems like we either end up supporting an
all-in-one utility, which will increase code complexity, or having an
additional utility which is going to be a wrapper for the existing
ones, which arguably has little value.

I get a feeling that the actual idea might be to refactor our CLI
tools to make the overall interface more consistent. Right now we have
several pg_* tools, and also tools like vacuumdb and createdb. Perhaps
what we might do instead is renaming/splitting the later ones into
pg_analyze, pg_vacuum, etc. Which of course is going to bring a
question about backward compatibility. I believe it can be provided by
symlinks or wrappers for several major releases.

--
Best regards,
Aleksander Alekseev