Re: PostgreSQL pollutes the file system - Mailing list pgsql-hackers

From Fred .Flintstone
Subject Re: PostgreSQL pollutes the file system
Date
Msg-id CAJgfmqV2N01PqLYMHswT2cQW28u-O8NZs5bVFYun6eQPc8psPg@mail.gmail.com
Whole thread Raw
In response to Re: PostgreSQL pollutes the file system  (Andreas Karlsson <andreas@proxel.se>)
Responses Re: PostgreSQL pollutes the file system
List pgsql-hackers
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@proxel.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


pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: Re: Planning counters in pg_stat_statements (using pgss_store)
Next
From: David Steele
Date:
Subject: Re: Re: query logging of prepared statements