Re: New 'pg' consolidated metacommand patch - Mailing list pgsql-hackers
From | Mark Dilger |
---|---|
Subject | Re: New 'pg' consolidated metacommand patch |
Date | |
Msg-id | CDF82182-8CAD-406C-B90B-27B8C9B4C104@enterprisedb.com Whole thread Raw |
In response to | Re: New 'pg' consolidated metacommand patch (Christopher Browne <cbbrowne@gmail.com>) |
List | pgsql-hackers |
> 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
pgsql-hackers by date: