Re: New 'pg' consolidated metacommand patch

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: New 'pg' consolidated metacommand patch
Date: 2020-05-27 19:59:59
Message-ID: 5a301725-eaeb-199e-6855-02af56c298ce@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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, along the 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 mostly as a way of moving the conversation along, fully expecting the community to want some (or all) of what I wrote to be changed.
>
> I'd also appreciate +1 and -1 votes on the overall idea, in case this entire feature, regardless of implementation, is simply 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2020-05-27 20:30:23 Re: future pg+llvm compilation is broken
Previous Message Victor Yegorov 2020-05-27 19:17:18 Re: Failure to create GiST on ltree column