Re: [HACKERS] Re: HISTORY for 6.5.2 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Re: HISTORY for 6.5.2
Date
Msg-id 20970.937688441@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Re: HISTORY for 6.5.2  (Lamar Owen <lamar.owen@wgcr.org>)
Responses Re: [HACKERS] Re: HISTORY for 6.5.2
List pgsql-hackers
Lamar Owen <lamar.owen@wgcr.org> 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


pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: v6.5.2 vacuum...?
Next
From: Lamar Owen
Date:
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2