Re: New 'pg' consolidated metacommand patch - Mailing list pgsql-hackers

On 2020-05-27 01:19, Mark Dilger wrote:
> Attached is a patch for a `pg' command that consolidates various PostgreSQL functionality into a single command,
alongthe lines of how `git' commands are run from a single 'git' executable.  In other words,
 
> 
>    `pg upgrade`   # instead of `pg_upgrade`
>    `pg resetwal`   # instead of `pg_resetwal`
> 
> This has been discussed before on the -hackers list, but I don't recall seeing a patch.  I'm submitting this patch
mostlyas a way of moving the conversation along, fully expecting the community to want some (or all) of what I wrote to
bechanged.
 
> 
> I'd also appreciate +1 and -1 votes on the overall idea, in case this entire feature, regardless of implementation,
issimply something the community does not want.
 

I'm not excited about this.

First, consider that git has over 170 subcommands.  PostgreSQL currently 
has 36, and we're probably not going to add dozens more any time soon. 
So the issue is not of the same scope.  It also seems to me that the way 
git is organized this becomes a self-perpetuating system:  They are 
adding subcommands all the time without much care where you might in 
other situations think harder about combining them and keeping the 
surface area smaller.  For example, we wouldn't really need separate 
commands clusterdb, reindexdb, vacuumdb if we had better support in psql 
for "run this command in each database [in parallel]".

git (and svn etc. before it) also has a much more consistent operating 
model that is sensible to reflect in the command structure.  They all 
more or less operate on a git repository, in apparently 170 different 
ways.  The 36 PostgreSQL commands don't all work in the same way.  Now 
if someone were to propose a way to combine server tools, perhaps like 
pginstancetool {init|controldata|resetwal|checksum}, and perhaps also in 
a way that actually saves code duplication and inconsistency, that would 
be something to consider.  Or maybe a client-side tool that does 
pgclienttool {create user|drop user|create database|...} -- but that 
pretty much already exists by the name of psql.  But just renaming 
everything that's shipped with PostgreSQL to one common bucket without 
regard to how it actually works and what role it plays would be 
unnecessarily confusing.

Also consider some practical concerns with the command structure you 
describe: Tab completion of commands wouldn't work anymore, unless you 
supply custom tab completion setups.  The direct association between a 
command and its man page would be broken.  Shell scripting becomes more 
challenging:  Instead of writing common things like "if which 
pg_waldump; then" you'd need some custom code, to be determined.  These 
are all solvable, but just a sum of slight annoyances, for no real benefit.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services