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
