> On May 27, 2020, at 2:42 PM, Christopher Browne <cbbro...@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 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
