Re: PostgreSQL pollutes the file system

Another pattern is to have a separate bin path for
various software packages:  /opt/postgres/bin  for example.

That doesn't directly answer "what is createdb?" but it
does give a quicker indication via the 'which' command.

On 3/20/19 5:43 AM, Fred .Flintstone wrote:
> It seems nothing came out of the discussion in 2008.
> I feel the topic should be revisited.
>
> I am in favor of doing so too. The deprecation cycle could involve
> symlinks for a brief period of time or a couple of versions.
>
> Yes, the wrapper script approach is used by Git as well as the "dotnet" command.
> The wrapper script addition doesn't mean executing the commands
> directly without the wrapper won't be possible. So one doesn't exclude
> the other.
> It would be a welcome addition.
>
> On Wed, Mar 20, 2019 at 11:05 AM Andreas Karlsson <andreas(at)proxel(dot)se> wrote:
>> On 3/19/19 11:19 AM, Fred .Flintstone wrote:
>>> PostgreSQL pollutes the file system with lots of binaries that it is
>>> not obvious that they belong to PostgreSQL.
>>>
>>> Such as "/usr/bin/createdb", etc.
>>>
>>> It would be better if these files were renamed to be prefixed with
>>> pg_, such as pg_createdb.
>>> Or even better postgresql-createdb then be reachable by through a
>>> "postgresql" wrapper script.
>> Hi,
>>
>> This topic has been discussed before e.g. in 2008 in
>> https://www.postgresql.org/message-id/47EA5CC0.8040102%40sun.com and
>> also more recently but I cannot find it in the archives right now.
>>
>> I am personally in favor of renaming e.g. createdb to pg_createdb, since
>> it is not obvious that createdb belongs to PostgreSQL when reading a
>> script or looking in /usr/bin, but we would need a some kind of
>> deprecation cycle here or we would suddenly break tons of people's scripts.
>>
>> And as for the git-like solution with a wrapper script, that seems to be
>> the modern way to do things but would be an even larger breakage and I
>> am not convinced the advantage would be worth it especially since our
>> executables are not as closely related and consistent as for example git's.
>>
>> Andreas
>
>