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 <andr...@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
