On 2019-Mar-27, Tom Lane wrote: > Alvaro Herrera <alvhe...@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
