> 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, 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.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
