Program names and "pollution"

A Linux user's $PATH likely contains well over a thousand different commands that were installed by various packages. It's not immediately obvious which package is responsible for a command with a generic name, like createuser. There are ways to figure it out, of course, but perhaps it would make sense for packages like PostgreSQL, which is responsible for createuser, to give their commands names that are less generic—and more easily disambiguated—such as pg_createuser. But renaming commands down the road has "backward compatibility problems" written all over it, as a recent discussion on the pgsql-hackers mailing list shows.

Someone with the unlikely name of "Fred .Flintstone" started things off with a post complaining that PostgreSQL "pollutes the file system" with generic program names. The post suggested that names either be prefixed with "pg_" or that they become subcommands of a wrapper command, à la Git: postgresql createuser. It is not the first time that the topic has been raised, Andreas Karlsson pointed to this thread from 2008; Tom Lane reached further back and pointed to a discussion in 1999.

At issue are a handful of commands that come with PostgreSQL and are potential sources of confusion for users: createdb, dropuser, vacuumdb, and so on. As Lane pointed out, though, the outcomes from the previous discussions make it pretty clear what will probably happen this time as well:

One command that was not mentioned in the early going, perhaps because it is so widely used in scripts, is initdb. Julien Rouhaud thought its name was more confusing than some of the others that had been mentioned, but Lane disagreed:

That led Alvaro Herrera to suggest making symbolic links from pg_* to, at least, createuser and dropuser. That would cause no change but, at some point, a deprecation warning could be printed for the unadorned versions and, eventually, they could perhaps be dropped entirely. But Tomas Vondra wondered what problem was truly being solved:

He went on to note that there are multiple ways for users to figure out what some random binary does, including man, -h or --help flags, or asking the package manager. Most seem to agree that some of the names are too generic (createuser and dropuser in particular), but there are not likely to be name conflicts with other tools since PostgreSQL has 20+ years of seniority at this point. Even though there is support for some kind of rename, doing so will cause pain—and not for the PostgreSQL project. As Lane put it:

A suggestion from Chris Travers that perhaps createuser and dropuser should just be removed led to concerns that leaving it to users to write their own shell scripts might result in security problems. The psql command can be used to create users, but the way to do so is somewhat non-obvious—more obvious alternatives could lead to SQL injection holes. But Lane wondered what the overarching plan is; will createuser actually be removed at some point, especially given that the postmaster command has been deprecated for more than 12 years but still has not been removed? Peter Eisentraut agreed that deprecation was not the project's strong suit, so: "How about we compromise in this thread and remove postmaster and leave everything else as is. ;-)"

Herrera argued that clearing up the confusion should be done as a service to future users. "The implicit argument here is that existing users are a larger population than future users. I, for one, don't believe that." Some seem to think that simply adding symbolic links for the pg_* variants might help things down the road, however. Herrera suggested adding the links and leaving it for a fictional future AI to do the deprecation. David Steele concurred with that plan: "+1 to tasking Skynet with removing deprecated features. Seems like it would save a lot of arguing."

Jokes aside, it doesn't really seem like the idea is going any further than it did in 2008 or 1999. As Lane repeatedly said, if the project were starting from scratch, surely other choices would be made; at this point, though, there is two decades of precedent, scripts, and muscle memory to overcome. That sentiment likely affects plenty of other projects, especially those that have been around for many years—free software grew up in a much smaller pool.

For the future, though, we will probably see less of these kinds of problems. New projects are generally thinking about "pollution" and finding ways to make it clear which binaries go with a particular package/project. That is a good thing since the number of packages we install is only going to grow.