"Oliver Elphick" <olly@lfix.co.uk> writes:
>> Tom Lane wrote:
>>> I think it would be a real bad idea to put the postmaster and postgres
>>> executables right in /usr/local/bin. Perhaps it is time to think about
>>> a separate 'sbin' directory for programs that aren't supposed to be
>>> invoked by normal users. Those two, initdb, initlocation, and ipcclean
> In the Debian package, I have put the administrator programs in
> /usr/lib/postgresql/bin. The postgres user has that directory in its path
> so that all works properly. Since root cannot run these, I don't think it
> appropriate to put them in /usr/sbin.
That seems like a good compromise to me. From a more general
perspective I guess that install would see it as two separate target
directories for executables, which I suppose we'd describe as "user"
and "dbadmin" bin directories. When installing one should have a
choice of a "traditional" setup (both user and admin exes go into
a single directory, eg /usr/local/pgsql/bin) or a "shared" setup
(user exes to a shared dir like /usr/local/bin, admin exes still go
to a private dir like /usr/local/pgsql/bin).
Offhand I'd make the division be user:
createdb dropdb ecpg pg-config pgaccess pgtclsh pgtksh psql
and admin:
createlang createuser droplang dropuser initdb initlocation ipcclean
pg_ctl pg_dump pg_dumpall pg_id pg_passwd pg_restore pg_upgrade postgres
postmaster vacuumdb
(Not sure about pg_dump/pg_dumpall/pg_restore; are these of any
significant use to non-superusers?) This would keep createuser/dropuser
out of the shared bin directory, which certainly seem like the names
most likely to cause conflicts.
The man pages probably need to adopt the same division as the exes,
ie some to /usr/local/man and some to /usr/local/pgsql/man.
Note that it'd be a real bad idea to abandon the option of the
"traditional" install-tree configuration. For people like me, with
three or four versions of Postgres hanging around on the same machine,
it's critical to be able to install everything into a single private
directory tree.
Comments?
regards, tom lane