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
