Re: New 'pg' consolidated metacommand patch

> On May 27, 2020, at 2:42 PM, Christopher Browne <cbbrowne@gmail.com> wrote:
>
> There is merit to having a new, harmonious set of "pg commands."  But it's eminently easy to get into trouble (and
getpeople mad) by changing things that have been working fine for many years.  Half the battle (against the "getting
peoplemad" part) is making sure that it's clear that people were listened to.  Listening to the community is one of the
importantthings to do :-). 

I totally agree.

There are options for keeping the existing tools and not modifying them.  If the "pg" command (or "pgsql" command, if
weuse that naming) knows, for example, how to execute pg_ctl, that's no harm to people who prefer to just run pg_ctl
directly. It only becomes a problem when this patch, or one like it, decides that "pg_ctl" needs to work differently,
havea different set of command line options, etc.  The only thing I changed about pg_ctl and friends in the v1 patch is
thatthey moved from BINDIR to LIBEXECDIR, and internally they were updated to be able to still work despite the move.
Thatchange was partly designed to spark conversation.  If people prefer they get moved back into BINDIR, fine by me.
Ifpeople instead prefer that the patch include links between the old BINDIR location and the new LIBEXECDIR location,
that'salso fine by me.  The "pg" command doesn't really care either.  I'm intentionally not calling the shots here.
I'masking the community members, many of whom expressed an interest in something along the lines of this patch.  I'm
happyto do the grunt work of the patch to meet the community needs. 

Dave Page expressed an interest upthread in standardizing the interfaces of the various commands.  He didn't say this,
butI assume he is thinking about things like -d meaning --debug in initdb but meaning --dbname=CONNSTR in
pg_basebackup. We could break backwards compatibility by changing one or both of those commands to interpret those
optionsin some new standardized way.  Or, we could preserve backwards compatibililty by having "pg" take --dbname and
--debugoptions and pass them to the subcommand according to the grandfathered rules of the subcommand.  I tend towards
preservingcompability, but maybe somebody on this list wants to argue for the other side?  For new commands introduced
afterthis patch gets committed (assuming it does), options could be passed from "pg" through to the subcommand
unmolested. That supports Robert's idea that people could install new subcommands from contrib modules without the "pg"
commandneeding to know anything about them.  This, too, is still open to conversation and debate. 

I'd like to hear from more community members on this.  I'm listening.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company