Re: New 'pg' consolidated metacommand patch

> On May 27, 2020, at 2:42 PM, Christopher Browne <cbbrowne(at)gmail(dot)com> wrote:
>
> There is merit to having a new, harmonious set of "pg commands." But it's eminently easy to get into trouble (and get people mad) by changing things that have been working fine for many years. Half the battle (against the "getting people mad" part) is making sure that it's clear that people were listened to. Listening to the community is one of the important things 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 we use 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, have a different set of command line options, etc. The only thing I changed about pg_ctl and friends in the v1 patch is that they moved from BINDIR to LIBEXECDIR, and internally they were updated to be able to still work despite the move. That change was partly designed to spark conversation. If people prefer they get moved back into BINDIR, fine by me. If people instead prefer that the patch include links between the old BINDIR location and the new LIBEXECDIR location, that's also fine by me. The "pg" command doesn't really care either. I'm intentionally not calling the shots here. I'm asking the community members, many of whom expressed an interest in something along the lines of this patch. I'm happy to 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, but I 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 options in some new standardized way. Or, we could preserve backwards compatibililty by having "pg" take --dbname and --debug options and pass them to the subcommand according to the grandfathered rules of the subcommand. I tend towards preserving compability, but maybe somebody on this list wants to argue for the other side? For new commands introduced after this 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" command needing 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