Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA87096 for ; Sat, 18 Sep 1999 17:02:35 -0400 (EDT) (envelope-from tgl@sss.pgh.pa.us) Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id RAA20972; Sat, 18 Sep 1999 17:00:41 -0400 (EDT) To: Lamar Owen cc: Theo Kramer , "pgsql-hackers@postgreSQL.org" Subject: Re: [HACKERS] Re: HISTORY for 6.5.2 In-reply-to: Your message of Sat, 18 Sep 1999 16:27:08 -0400 <99091816355500.00581@lowen.wgcr.org> Date: Sat, 18 Sep 1999 17:00:41 -0400 Message-ID: <20970.937688441@sss.pgh.pa.us> From: Tom Lane Lamar Owen writes: > So, it IS an interesting thought -- while it would initially create a > good deal of confusion, what is the consensus of the hackers on this > issue?? Prepending "pg_" to all postgresql commands seems to me to be > a good idea (after all, we already hav pg_dump, pg_dumpall, > pg_upgrade, etc.). I don't see a need to change the names of psql or ecpg, which just happen to be the things most commonly invoked by users. I'd be in favor of prepending pg_ to all the "admin-type" commands like createuser. Especially the createXXX/destroyXXX/initXXX ones, which seem the most likely to cause naming conflicts. While we are thinking about this, I wonder if it wouldn't be a good idea to separate out the executables that aren't really intended to be executed willy-nilly, and put them in a different directory. postmaster, postgres, and initdb have no business being in users' PATH at all, ever. You could make a case that some of the other executables are admin tools not intended for ordinary mortals, as well, and should not live in a directory that might be put in users' PATH. Of course, the other way an admin can handle that issue is not to put /usr/local/pgsql/bin into PATH, but to make symlinks from a more popular directory (say, /usr/local/bin) for the programs that users are expected to execute. I suppose such an admin could stick pg_ on the front of the symlinks anyway. But then the program names don't match the documentation we supply, which would be confusing. regards, tom lane