New 'pg' consolidated metacommand patch - Mailing list pgsql-hackers

Hackers,

Attached is a patch for a `pg' command that consolidates various PostgreSQL functionality into a single command, along
thelines 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. 

I'd also appreciate +1 and -1 votes on the overall idea, in case this entire feature, regardless of implementation, is
simplysomething the community does not want. 

Once again, this is mostly intended as a starting point for discussion.


The patch moves some commands from BINDIR to LIBEXECDIR where `pg' expects to find them.  For commands named pg_foo,
theexecutable is still named pg_foo and the sources are still located in src/bin/pg_foo/, but the command can now be
runas `pg foo`, `pg foo --version`, `pg foo FOO SPECIFIC ARGS`, etc. 

The command pgbench (no underscore) maps to 'pg bench'.

Commands without a "pg" prefix stay the same, so "createdb" => "pg createdb", etc.

The 'psql' and 'postgres'  executables (and the 'postmaster' link) have been left in BINDIR, as has 'ecpg'.  The 'pg'
executablehas been added to BINDIR. 

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.  For that reason, I
didnot change the names of the executables, merely their location.  During conversations with Robert off-list, we
discussedrenaming the executables to things like 'pg-ctl' (hyphen rather than underscore), mostly because that's the
moremodern way of doing it and follows what 'git' does.  To avoid breaking scripts that execute these commands by the
oldname, this patch doesn't go that far.  It also leaves the usage() functions alone such that when they report their
ownprogname in the usage text, they do so under the old name.  This would need to change at some point, but I'm unclear
onwhether that would be for v14 or if it would be delayed. 

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? 

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. 

The handling of the old libexec directory in pg_upgrade is not as robust as it could be.  I'll look to improve that for
asubsequent version of the patch, assuming the overall idea of the patch seems acceptable. 

I've updated some of the doc/sgml/* files, but don't want to spend too much time changing documentation until we have
someconsensus that the patch is moving in the right direction. 



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