Re: New 'pg' consolidated metacommand patch

On Wed, May 27, 2020 at 4:00 PM Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> 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]".

I see your point here, but I think it's clear that some people are
already concerned about the proliferation of binaries on namespace
grounds. For example, it was proposed that pg_verifybackup should be
part of pg_basebackup, and then later and by someone else that it
should be part of pg_checksums. It's quite different from either of
those things and I'm pretty confident it shouldn't be merged with
either one, but there was certainly pressure in that direction. So
apparently for some people 36 is already too many. It's not clear to
me why it should be a problem to have a lot of commands, as long as
they all start with "pg_", but if it is then we should do something
about it rather than waiting until we have more of them.

> 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.

This doesn't strike me as a very practical proposal because
"pginstancetool checksums" is really stinking long compared to
"pg_checksums", where as "pg checksums" is no different, or one
keystroke better if you assume that the underscore requires pressing
shift.

> 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.

There are some potential benefits, I think, such as:

1. It seems to be the emerging standard for command line interfaces.
There's not only the 'git' example but also things like 'aws', which
is perhaps more similar to the case proposed here in that there are a
bunch of subcommands that do quite different sorts of things. I think
a lot of developers are now quite familiar with the idea of a main
command with a bunch of subcommands, and they expect to be able to
type 'git help' or 'aws help' or 'pg help' to get a list of commands,
and then 'pg help createdb' for help with that. If you don't know what
pg commands exist today, how do you discover them? You're right that
not everyone is going this way but it seems to be pretty common
(kubectl, yum, brew, npm, heroku, ...).

2. It lowers the barrier to adding more commands. For example, as
Chris Browne says, we could have a 'pg completion' command to emit
completion information for various shells. True, that would be more
necessary with this proposal. But I bet there's stuff that could be
done even today -- I think most modern shells have pretty powerful
completion facilities. Someone could propose it, but what are the
chances that a patch adding a pg_completion binary would be accepted?
I feel like the argument that this is too narrow to justify the
namespace pollution is almost inevitable.

3. It might help us achieve some better consistency between commands.
Right now we have a lot of warts in the way things are named, like
pgbench vs. pg_ctl vs. createdb, and also pg_basebackup vs.
pg_test_fsync (why not pg_base_backup or pg_testfsync?). Standardizing
on something like this would probably help us be more consistent
there. Over time, we might be able to also clean other things up.
Maybe we could get all of our client-side utilities to share a common
config file, and have a 'pg config' utility to configure it. Maybe we
could have common options that are shared by all commands as 'git'
does. These things aren't impossible without unifying the interface,
but unifying the interface does help to make it clearer why the other
things should also be unified.

Now maybe it's just not worth it. I'm pretty sure that if we made this
change I would spend some time cursing this because my fingers would
type commands that don't work any more, and that could be annoying,
and I suspect a lot of other people might feel similarly. I don't
think this is something we HAVE to do, but I am a little worried that
we're otherwise locked into a system that isn't particularly scalable
to more commands and doesn't really have any sort of unifying design
either.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company