Re: New 'pg' consolidated metacommand patch

> On May 27, 2020, at 1:50 AM, Magnus Hagander <magnus@hagander.net> wrote:
>
> On Wed, May 27, 2020 at 1:19 AM Mark Dilger <mark.dilger@enterprisedb.com> wrote:
> Hackers,
>
> Attached is a patch for a `pg' command that consolidates various PostgreSQL functionality into a single command,
alongthe lines of how `git' commands are run from a single 'git' executable.  In other words, 
>
>   `pg upgrade`   # instead of `pg_upgrade`
>   `pg resetwal`   # instead of `pg_resetwal`
>
> This has been discussed before on the -hackers list, but I don't recall seeing a patch.  I'm submitting this patch
mostlyas a way of moving the conversation along, fully expecting the community to want some (or all) of what I wrote to
bechanged. 
>
> As mentioned at least once before, the "pg" name is already taken in posix. Granted it has been removed now, but it
wasremoved from posix in 2018, which I think is nowhere near soon enough to "steal. See for example
https://en.wikipedia.org/wiki/Pg_(Unix)

Care to recommend a different name?

> All other executables have been moved to LIBEXECDIR where they retain their old names and can still be run directly
fromthe command line.  If we committed this patch for v14, I think it makes sense that packagers could put the
LIBEXECDIRin the PATH so that 3rd-party scripts which call pg_ctl, initdb, etc. continue to work.  
>
> I would definitely not expect a packager to change the PATH, as also mentioned by others. More likely options would
beto symlink the binaries into the actual  bindir, or just set both those directories to the same one (in the path) for
anumber of releases as a transition. 

There is nothing in the patch that expects packagers to muck with the PATH.  The idea, badly phrased, was that by
keepingthe names of the executables and only changing locations, people would have more options for how to deal with
thechange. 

> But you should definitely poll the packagers separately to make sure something is done that works well for them --
especiallywhen it comes to integrating with for example the debian/ubuntu wrapper system that already supports multiple
parallelinstalls. And mind that they don't typically follow hackers actively (I think), so it would be worthwhile to
bringtheir attention specifically to the thread. In many ways I'd find them more important to get input from than most
"otherhackers" :) 

Yeah, good advice.  Since I've already floated this on -hackers, I might wait a few days for comment, then if it looks
encouraging,ask on other lists. 

> For that reason, I did not change the names of the executables, merely their location.  During conversations with
Robertoff-list, we discussed renaming the executables to things like 'pg-ctl' (hyphen rather than underscore), mostly
becausethat's the more modern way of doing it and follows what 'git' does.  To avoid breaking scripts that execute
thesecommands by the old name, this patch doesn't go that far.  It also leaves the usage() functions alone such that
whenthey report their own progname in the usage text, they do so under the old name.  This would need to change at some
point,but I'm unclear on whether that would be for v14 or if it would be delayed. 
>
> Ugh, yeah, please don't do that. Renaming them just to make it "look more modern" helps nobody, really. Especially if
thesuggestion is people should be using the shared-launcher binary anyway.  
>
> usage() seems more reasonable to change as part of a patch like this.
>
>
> The binaries 'createuser' and 'dropuser' might be better named 'createrole' and 'droprole'.  I don't currently have
aliasesin this patch, but it might make sense to allow 'pg createrole' as a synonym for 'pg createuser' and 'pg
droprole'as a synonym for 'pg dropuser'.  I have not pursued that yet, largely because as soon as you go that route, it
startsmaking sense to have things like 'pg drop user', 'pg cluster db' and so forth, with the extra spaces.  How far
wouldpeople want me to go in this direction? 
>
> I'd say a createrole would make sense, but certainly not a "create role". You'd end up with unlimited number of
commands.But in either of them, I'd say keep aliases completely out of it for a first iteration. 

Ok.

> Prior to this patch, postgres binaries that need to execute other postgres binaries determine the BINDIR using
find_my_execand trimming off their own executable name.  They can then assume the other binary is in that same
directory. After this patch, binaries need to find the common prefix ROOTDIR = commonprefix(BINDIR,LIBEXECDIR) and then
assumethe other binary is either in ROOTDIR/binsuffix or ROOTDIR/libexecsuffix.  This may cause problems on windows if
BINDIRand LIBEXECDIR are configured on different drives, as there won't be a common prefix of C:\my\pg\bin and
D:\my\pg\libexec. I'm hoping somebody with more Windows savvy expresses an opinion about how to handle this. 
>
> Maybe the "pg" binary could just pass down it's own location as a parameter to the binary it calls, thereby making
surethat binary has direct access to both?  

Perhaps.  Thus far, I've avoided making the binaries dependent on being called from 'pg'.  Having them depend on a
parameterthat 'pg' passes would be a big change. 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company