> On May 26, 2020, at 4:59 PM, David G. Johnston <david.g.johnston@gmail.com> wrote: > > On Tue, May 26, 2020 at 4:19 PM Mark Dilger <mark.dilger@enterprisedb.com> 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 would be needed if someone were to create an external project that installed a "pg" command on top of an existing PostgreSQL installation. Or put differently, how many of the changes to the existing binaries are required versus nice-to-have?
If the only goal of something like this were to have a frontend that could execute the various postgres binaries, then I'd say no changes to those binaries would be needed, and the frontend would not be worth very much. The value in having the frontend is that it makes it less difficult to introduce new commands to the postgres suite of commands, as you don't need to worry about whether another executable by the same name might happen to already exist somewhere. Even introducing a command named "pg" has already gotten such a response on this thread. By having the commands installed in postgres's libexec rather than bin, you can put whatever commands you want in libexec without worrying about conflicts. That still leaves open the question of whether existing commands get moved into libexec, and if so, if they keep the same name. An external project for this would be worthless in this regard, as the community wouldn't get any benefit when debating the merits of introducing a new command vs. the potential for conflicts.
The issue you raise can almost certainly be resolved simply by prefixing pg- or something similar on all the existing binary names.
I think the beauty of having a single CLI executable is that we can redesign the user interface to make it nice and consistent for all the different functions it offers, and to cleanup old cruft such as createuser vs. createrole and pgbench vs. pg_* and so on.
