steve@blighty.com (Steve Atkins) writes:
> There are no existing clashes with system tools that I'm aware of. Are
> there any? Most of the clashes are with other installations of
> postgresql installed on the same machine, so if name clashes is the
> real reason for the change, then the version number or port number of
> the installation should be part of the command name - pg_8.3.1_psql,
> and so on.
>
> The normal way of dealing with multiple installations and name clashes
> would be to set your shell path appropriately, though, surely? It's a
> more normal way of dealing with that than renaming the actual binaries.
pg_8.3.1_psql?? That seems pretty awful to me...
My practice is to use PATH to control this.
Debian has some "more or less idiosyncratic" tools to handle having
multiple clusters around, with pg_wrapper controlling which of these
binaries you wind up pointing to. I keep finding that I hate that,
though I haven't gotten so mad about it that I have done anything
about it ;-).
> If, on the other hand, the main reason behind name changes were to
> make the naming more intuitive for new users then changing the names
> to something more appropriate might be useful. Perhaps something like
> changing "postmaster" to "postgresqld", "pg_ctl" to
> "safe_postgresqld", change "psql" to "postgresql", replace "createuser
> -s monty" with "postgresql --user=root", followed by "GRANT ALL
> PRIVILEGES ON *.* TO 'monty'@'localhost';" and so on.
pg_ctl is really more like the scripts in /etc/init.d; whatever it
"ought" to be called instead, I don't think "safe_postgresqld" is
it...
--
select 'cbbrowne' || '@' || 'linuxfinances.info';
http://cbbrowne.com/info/wp.html
All ITS machines now have hardware for a new machine instruction --
PFLT Prove Fermat's Last Theorem.
Please update your programs.