Re: New 'pg' consolidated metacommand patch - Mailing list pgsql-hackers
| From | Christopher Browne |
|---|---|
| Subject | Re: New 'pg' consolidated metacommand patch |
| Date | |
| Msg-id | CAFNqd5Vm0hnNiccyZOdu1sR+5Tiaqq0AVK6bFjh1akJRN3zY7Q@mail.gmail.com Whole thread Raw |
| In response to | Re: New 'pg' consolidated metacommand patch (Isaac Morland <isaac.morland@gmail.com>) |
| Responses |
Re: New 'pg' consolidated metacommand patch
Re: New 'pg' consolidated metacommand patch |
| List | pgsql-hackers |
On Wed, 27 May 2020 at 16:49, Isaac Morland <isaac.morland@gmail.com> wrote:
On Wed, 27 May 2020 at 16:00, Peter Eisentraut <peter.eisentraut@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 between a
command and its man page would be broken. Shell scripting becomes more
challenging: Instead of writing common things like "if which
pg_waldump; then" you'd need some custom code, to be determined. These
are all solvable, but just a sum of slight annoyances, for no real benefit.I don’t think the man page concern is justified. We could have a “help” subcommand, just like git; “git help add” is (to a casual observer; probably not precisely) the same as “man git-add”.
There's some very small gulf in between the concerns...
- On the one hand, git (and systems with similar "keyword" subsystems) have arrived at reasonable solutions to cope with various of the systematic issues, so that these shouldn't be considered to be gigantic insurmountable barriers.
Indeed, some of these tools present systematic solutions to additional matters. I was very pleased when I found that some of the Kubernetes tools I was working with included subcommands to configure my shell to know how to do command completion. Seems like a fine thing to me to have that become systematically *easier*, and I think that would be a good new subcommand... "pg completion bash" and "pg completion zsh" would be mighty fine things.
- On the other hand, mapping old commands that are names of programs onto "pg subcommands" is some additional effort, and we haven't yet started bikeshedding on the favoured names :-)
I have lately noticed some interesting looking apps wandering about that briefly attracted my attention, but, which, due to being painfully different from the existing commands and tools that I have already learned, and have "muscle memory" for, am loath to leave. I'll throw out 4 examples, 3 of them personal:
a) nnn is a terminal-based file manager. It has some nifty features surrounding the concept that you can set up custom file filters to look for sorts of files that you find interesting, and then offers customizable UI for running favorite actions against them. I'm 25 years into using Emacs Dired mode; as neat as nnn seems, it's not enough of an improvement to be worth the pain in the neck of relearning stuff.
b) 3mux is a redo of tmux (which was a redo of GNU Screen), and has key mappings that make it way easier for a new user to learn. I'm 20-ish years into Screen/Tmux; I wasn't looking for it to be easier to learn, because I did that quite a while ago.
c) Kakoune is a vi-like editor which rotates from vi's "verb/object" approach to commands to a "object/verb" approach, for apparent more efficiency. I think I already mentioned that my "muscle memory" is biased by Emacs features... I'm not adding a "rotated-vi-like" thing into my mix :-(
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 using it where I find some use, and have not been displeased with my results. And since modern systems now have USB and network devices added and dropped on a whim, there's a critical need for something newer with more dynamic responses than old SysV Init. But I certainly "get" that some aren't so happy with it, and I'm not thrilled at the ongoing scope creep that never seems to end.
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 :-).
-- When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
question, "How would the Lone Ranger handle this?"
pgsql-hackers by date: