On Mar 26, 2008, at 10:46 AM, Alvaro Herrera wrote:
Steve Atkins wrote:
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.
Eeek!
These were mostly rhetorical suggestions. Not serious in themselves,
but hoping to make people come clean about why name changes of
binaries might be needed.
If we really want to go down that route, I would suggest that psql
needs
to become a bridge program that calls another program in
$PREFIX/share/libexec. So 8.3 installs share/libexec/psql-8.3 and 8.2
installs share/libexec/psql-8.2. So bin/psql gets the server version
and then execv() the appropriate executable from share/libexec.
I "strongly object" to the idea of renaming the main binary to add a
version number to the name.
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.
That's what I do, for one. Not necessarily the best design, but it's
easy to do.
Me too. And, given that, I don't see that hypothetical clashes with
potential
future system utilities (the assumption this survey thread is based
on) is a
particularly strong reason for renaming binaries.
Perhaps something like changing "postmaster" to "postgresqld",
It is already called "postgres" on newer versions.
"pg_ctl" to "safe_postgresqld",
Now that's plain weird.
Yes, it is. But if the goal is to make it more approachable for people
who
are familiar with mysql, but not prepared to read postgresql
documentation
it's also the obvious change to make.
Cheers,
Steve
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
