On 2019-Mar-27, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > On 2019-Mar-27, Tomas Vondra wrote:
> >> I think the consensus in this thread (and the previous ancient ones) is
> >> that it's not worth it. It's one thing to introduce new commands with the
> >> pg_ prefix, and it's a completely different thing to rename existing ones.
> >> That has inherent costs, and as Tom pointed out the burden would fall on
> >> people using PostgreSQL (and that's rather undesirable).
>
> > I thought the consensus was to rename them, and install symlinks to the
> > old names.
>
> The question is what's the endgame. We haven't actually fixed the
> complained-of confusion problem unless we eventually remove createuser
> and dropuser under those names.
Well, partly we have, because there mere act of having a symlink
documents the command via the symlink target.
Somebody proposed to rename createuser not to pg_createuser, though, but
rather to pg_createrole; ditto dropuser. That seems to make sense.
I additionally proposed (nobody replied to this part) that we could have
the command print a WARNING if the argv[0] is shown to be the old name.
Not necessarily in pg12; maybe we can have them print such a warning in
pg13, and then remove the old names three years from now, or something
like that.
I suppose that if you're a Postgres developer, you naturally expect that
"createdb" creates a Postgres DB. What if you use multiple database
systems, and then only occasionally have to do DBA tasks? I find this
POV that createdb doesn't need renaming a bit self-centered.
> Are we prepared to force script breakage of that sort, even over a
> multi-year deprecation cycle?
Why not?
> (As a comparison point, I note that we still haven't removed the
> "postmaster" symlink, though it's been deprecated for at least a
> dozen years.)
I don't think that change was because of executable namespace pollution
or user confusion. (Commit 5266f221a2e1, can't find the discussion
though.)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services