> 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,
issimply 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
externalproject that installed a "pg" command on top of an existing PostgreSQL installation. Or put differently, how
manyof 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'dsay no changes to those binaries would be needed, and the frontend would not be worth very much. The value in
havingthe frontend is that it makes it less difficult to introduce new commands to the postgres suite of commands, as
youdon't need to worry about whether another executable by the same name might happen to already exist somewhere. Even
introducinga command named "pg" has already gotten such a response on this thread. By having the commands installed in
postgres'slibexec rather than bin, you can put whatever commands you want in libexec without worrying about conflicts.
Thatstill leaves open the question of whether existing commands get moved into libexec, and if so, if they keep the
samename. An external project for this would be worthless in this regard, as the community wouldn't get any benefit
whendebating the merits of introducing a new command vs. the potential for conflicts.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
