Re: New 'pg' consolidated metacommand patch

2020-05-28 Thread Robert Haas
On Wed, May 27, 2020 at 4:00 PM Peter Eisentraut wrote: > 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

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Peter Eisentraut
On 2020-05-27 23:42, Christopher Browne wrote: d) systemd is a Controversial System; the folk that seem particularly irate about it seem to be "Old Bearded Sysadmins" that hate the idea of redoing their understandings of how Unix systems initialize. Personally, my feelings are ambivalent; I'm u

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Mark Dilger
> On May 27, 2020, at 2:42 PM, Christopher Browne 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 >

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Christopher Browne
On Wed, 27 May 2020 at 16:49, Isaac Morland wrote: > On Wed, 27 May 2020 at 16:00, Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> wrote: > > >> Also consider some practical concerns with the command structure you >> describe: Tab completion of commands wouldn't work anymore, unless you >>

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Isaac Morland
On Wed, 27 May 2020 at 16:00, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > 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

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Peter Eisentraut
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`

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Isaac Morland
On Wed, 27 May 2020 at 12:35, Robert Haas wrote: > Ugh, yeah, please don't do that. Renaming them just to make it "look more > modern" helps nobody, really. Especially if the suggestion is people should > be using the shared-launcher binary anyway. > > The way things like 'git' work is that 'git

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Robert Haas
On Wed, May 27, 2020 at 4:51 AM Magnus Hagander wrote: >> For that reason, I did not change the names of the executables, merely their >> location. During conversations with Robert off-list, we discussed renaming >> the executables to things like 'pg-ctl' (hyphen rather than underscore), >> mo

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Robert Haas
On Wed, May 27, 2020 at 4:51 AM Magnus Hagander wrote: > As mentioned at least once before, the "pg" name is already taken in posix. > Granted it has been removed now, but it was removed from posix in 2018, which > I think is nowhere near soon enough to "steal. See for example > https://en.wiki

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Christoph Moench-Tegeder
## Magnus Hagander (mag...@hagander.net): > Ugh, yeah, please don't do that. Renaming them just to make it "look more > modern" helps nobody, really. Especially if the suggestion is people should > be using the shared-launcher binary anyway. Quick, let's invent a fancy name like "microcommand" fo

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Dave Page
On Wed, May 27, 2020 at 3:00 PM Mark Dilger wrote: > > > > On May 26, 2020, at 4:59 PM, David G. Johnston < > david.g.johns...@gmail.com> wrote: > > > > On Tue, May 26, 2020 at 4:19 PM Mark Dilger < > mark.dil...@enterprisedb.com> wrote: > > I'd also appreciate +1 and -1 votes on the overall idea

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Mark Dilger
> On May 27, 2020, at 1:50 AM, Magnus Hagander wrote: > > On Wed, May 27, 2020 at 1:19 AM Mark Dilger > wrote: > Hackers, > > 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

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Mark Dilger
> On May 27, 2020, at 1:13 AM, Dave Page wrote: > > Hi > > On Wed, May 27, 2020 at 12:19 AM Mark Dilger > wrote: > > I think it makes sense that packagers could put the LIBEXECDIR in the PATH so > that 3rd-party scripts which call pg_ctl, initdb, etc. continue to work. > > Having packa

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Mark Dilger
> On May 26, 2020, at 4:59 PM, David G. Johnston > wrote: > > On Tue, May 26, 2020 at 4:19 PM Mark Dilger > wrote: > 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. >

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Magnus Hagander
On Wed, May 27, 2020 at 1:19 AM Mark Dilger wrote: > Hackers, > > 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`

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Dave Page
Hi On Wed, May 27, 2020 at 12:19 AM Mark Dilger wrote: > > I think it makes sense that packagers could put the LIBEXECDIR in the PATH > so that 3rd-party scripts which call pg_ctl, initdb, etc. continue to > work. Having packages that futz with the PATH is generally a bad idea, especially thos

Re: New 'pg' consolidated metacommand patch

2020-05-26 Thread David G. Johnston
On Tue, May 26, 2020 at 4:19 PM Mark Dilger wrote: > 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. > -1, at least as part of core. My question would be how much of this is