PostgreSQL pollutes the file system
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.
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
/messages/by-id/47EA5CC0.8040102@sun.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
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.
Show quoted text
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
/messages/by-id/47EA5CC0.8040102@sun.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
On Wed, Mar 20, 2019 at 11:06 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
/messages/by-id/47EA5CC0.8040102@sun.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
I wouldn't be opposed to this, but I would note two points on a deprecation
cycle:
1 Given that people may have tools that work with all supported versions
of PostgreSQL, this needs to be a long cycle, and
2. Managing that cycle makes it a little bit of a tough sell.
.
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.
Git commands may be related, but I would actually argue that git commands
have a lot of inconsistency because of this structure,
See, for example, http://stevelosh.com/blog/2013/04/git-koans/
Andreas
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
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.
Show quoted text
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@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
/messages/by-id/47EA5CC0.8040102@sun.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
Chris Travers <chris.travers@adjust.com> writes:
On Wed, Mar 20, 2019 at 11:06 AM Andreas Karlsson <andreas@proxel.se> wrote:
On 3/19/19 11:19 AM, Fred .Flintstone wrote:
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.
This topic has been discussed before e.g. in 2008 in
/messages/by-id/47EA5CC0.8040102@sun.com and
also more recently but I cannot find it in the archives right now.
And also before that, eg
/messages/by-id/199910091253.IAA10670@candle.pha.pa.us
I wouldn't be opposed to this, but I would note two points on a deprecation
cycle:
1 Given that people may have tools that work with all supported versions
of PostgreSQL, this needs to be a long cycle, and
2. Managing that cycle makes it a little bit of a tough sell.
If we didn't pull the trigger twenty years ago, nor ten years ago,
we're not likely to do so now. Yeah, it's a mess and we'd certainly
do it differently if we were starting from scratch, but we're not
starting from scratch. There are decades worth of scripts out there
that know these program names, most of them not under our control.
Every time this has been looked at, we've concluded that the
distributed costs of getting rid of these program names would exceed
the value; and that tradeoff gets worse, not better, as more years
go by. I don't foresee it happening.
regards, tom lane
This topic has been discussed before e.g. in 2008 in
/messages/by-id/47EA5CC0.8040102@sun.com and
also more recently but I cannot find it in the archives right now.And also before that, eg
/messages/by-id/199910091253.IAA10670@candle.pha.pa.usI wouldn't be opposed to this, but I would note two points on a deprecation
cycle:
1 Given that people may have tools that work with all supported versions
of PostgreSQL, this needs to be a long cycle, and
2. Managing that cycle makes it a little bit of a tough sell.If we didn't pull the trigger twenty years ago, nor ten years ago,
we're not likely to do so now. Yeah, it's a mess and we'd certainly
do it differently if we were starting from scratch, but we're not
starting from scratch. There are decades worth of scripts out there
that know these program names, most of them not under our control.Every time this has been looked at, we've concluded that the
distributed costs of getting rid of these program names would exceed
the value; and that tradeoff gets worse, not better, as more years
go by. I don't foresee it happening.
+1. As one of third party PostgreSQL tool developers, I am afraid
changing names of PostgreSQL commands would give us lots of pain: for
example checking PostgreSQL version to decide to use command "foo" not
"pg_foo".
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
On Wed, Mar 20, 2019 at 3:19 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
If we didn't pull the trigger twenty years ago, nor ten years ago,
we're not likely to do so now. Yeah, it's a mess and we'd certainly
do it differently if we were starting from scratch, but we're not
starting from scratch. There are decades worth of scripts out there
that know these program names, most of them not under our control.Every time this has been looked at, we've concluded that the
distributed costs of getting rid of these program names would exceed
the value; and that tradeoff gets worse, not better, as more years
go by. I don't foresee it happening.
Even just creating symlinks would be a welcome change.
So the real binary is pg_foo and foo is a symoblic link that points to pg_foo.
Then at least I can type pg_<tab> and use tab auto-completion to find
everything related to PostgreSQL.
Em qua, 20 de mar de 2019 às 11:39, Tatsuo Ishii <ishii@sraoss.co.jp> escreveu:
+1. As one of third party PostgreSQL tool developers, I am afraid
changing names of PostgreSQL commands would give us lots of pain: for
example checking PostgreSQL version to decide to use command "foo" not
"pg_foo".
createdb, dropdb, createuser, dropuser, reindexdb are binaries that
confuse most newbies. Which tool is theses binaries from? The names
does not give a hint. How often those confusing name tools are used?
AFAICS a graphical tool or psql is used to create roles and databases.
psql -c "stmt" can replace createdb, dropdb, createuser and dropuser.
What about deprecate them (and remove after a support cycle)?
--
Euler Taveira Timbira -
http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
Em qua, 20 de mar de 2019 às 14:22, Fred .Flintstone
<eldmannen@gmail.com> escreveu:
Even just creating symlinks would be a welcome change.
So the real binary is pg_foo and foo is a symoblic link that points to pg_foo.
Then at least I can type pg_<tab> and use tab auto-completion to find
everything related to PostgreSQL.
There are Postgres binaries that do not start with 'pg_' (for example,
pgbench and ecpg) and do not confuse newbies or conflict with OS
binary names.
--
Euler Taveira Timbira -
http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
On 2019-Mar-20, Fred .Flintstone wrote:
Even just creating symlinks would be a welcome change.
So the real binary is pg_foo and foo is a symoblic link that points to pg_foo.
Then at least I can type pg_<tab> and use tab auto-completion to find
everything related to PostgreSQL.
There is merit to this argument; if the starting point is an unknown
file /usr/bin/foo, then having it be a symlink to /usr/bin/pg_foo makes
it clear which package it belongs to. We don't *have to* get rid of the
symlinks any time soon, but installing as symlinks now will allow Skynet
to get rid of them some decades from now.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, Mar 20, 2019 at 6:25 PM Euler Taveira <euler@timbira.com.br> wrote:
createdb, dropdb, createuser, dropuser, reindexdb are binaries that
confuse most newbies. Which tool is theses binaries from? The names
does not give a hint. How often those confusing name tools are used?
initdb is probably an order of magnitude worse name than all of these.
Julien Rouhaud <rjuju123@gmail.com> writes:
On Wed, Mar 20, 2019 at 6:25 PM Euler Taveira <euler@timbira.com.br> wrote:
createdb, dropdb, createuser, dropuser, reindexdb are binaries that
confuse most newbies. Which tool is theses binaries from? The names
does not give a hint. How often those confusing name tools are used?
initdb is probably an order of magnitude worse name than all of these.
Meh. The ones with "db" in the name don't strike me as mortal sins;
even if you don't recognize them as referring to a "database", you're
not likely to guess wrongly that you know what they do. The two that
seem the worst to me are createuser and dropuser, which not only have
no visible connection to "postgres" or "database" but could easily
be mistaken for utilities for managing operating-system accounts.
We managed to get rid of createlang and droplang in v10, and there
hasn't been that much push-back about it. So maybe there could be
a move to remove createuser/dropuser? Or at least rename them to
pg_createuser and pg_dropuser. But I think this was discussed
(again) during the v10 cycle, and we couldn't agree to do more than
get rid of createlang/droplang.
regards, tom lane
Em qua, 20 de mar de 2019 às 14:57, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
We managed to get rid of createlang and droplang in v10, and there
hasn't been that much push-back about it. So maybe there could be
a move to remove createuser/dropuser? Or at least rename them to
pg_createuser and pg_dropuser. But I think this was discussed
(again) during the v10 cycle, and we couldn't agree to do more than
get rid of createlang/droplang.
Votes? +1 to remove createuser/dropuser (and also createdb/dropdb as I
said in the other email). However, if we don't have sufficient votes,
let's at least consider a 'pg_' prefix.
--
Euler Taveira Timbira -
http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
On 2019-Mar-20, Euler Taveira wrote:
Em qua, 20 de mar de 2019 �s 14:57, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
We managed to get rid of createlang and droplang in v10, and there
hasn't been that much push-back about it. So maybe there could be
a move to remove createuser/dropuser? Or at least rename them to
pg_createuser and pg_dropuser. But I think this was discussed
(again) during the v10 cycle, and we couldn't agree to do more than
get rid of createlang/droplang.
Previous discussion:
/messages/by-id/CABUevExPrfPH5K5qM=zsT7tvfyACe+i5qjA6bfWCKKYrh8MJLw@mail.gmail.com
Votes? +1 to remove createuser/dropuser (and also createdb/dropdb as I
said in the other email). However, if we don't have sufficient votes,
let's at least consider a 'pg_' prefix.
I vote to keep these rename these utilities to have a pg_ prefix and to
simultaneously install symlinks for their current names, so that nothing
breaks.
[In a couple of releases we could patch them so that they print a
deprecation warning to stderr if they're invoked without the prefix.]
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, 20 Mar 2019 13:56:55 -0400
Tom Lane <tgl@sss.pgh.pa.us> wrote:
Julien Rouhaud <rjuju123@gmail.com> writes:
On Wed, Mar 20, 2019 at 6:25 PM Euler Taveira <euler@timbira.com.br>
wrote:createdb, dropdb, createuser, dropuser, reindexdb are binaries that
confuse most newbies. Which tool is theses binaries from? The names
does not give a hint. How often those confusing name tools are used?initdb is probably an order of magnitude worse name than all of these.
Meh. The ones with "db" in the name don't strike me as mortal sins;
even if you don't recognize them as referring to a "database", you're
not likely to guess wrongly that you know what they do. The two that
seem the worst to me are createuser and dropuser, which not only have
no visible connection to "postgres" or "database" but could easily
be mistaken for utilities for managing operating-system accounts.We managed to get rid of createlang and droplang in v10, and there
hasn't been that much push-back about it. So maybe there could be
a move to remove createuser/dropuser? Or at least rename them to
pg_createuser and pg_dropuser.
If you rename them, rename as pg_createrole and pg_droprole :)
I teach people not to use "CREATE USER/GROUP", but each time I have to tell
them "Yes, we kept createuser since 8.1 where roles has been introduced for
backward compatibility. No, there's no createrole".
++
"Fred .Flintstone" <eldmannen@gmail.com> writes:
Even just creating symlinks would be a welcome change.
So the real binary is pg_foo and foo is a symoblic link that points to pg_foo.
Then at least I can type pg_<tab> and use tab auto-completion to find
everything related to PostgreSQL.
You'd miss psql. I think the odds of renaming psql are not
distinguishable from zero: whatever arguments you might want to make
about, say, renaming initdb perhaps not affecting too many scripts
are surely not going to fly for psql. So that line of argument
isn't too convincing.
regards, tom lane
On 3/20/19 9:32 PM, Alvaro Herrera wrote:
On 2019-Mar-20, Fred .Flintstone wrote:
Even just creating symlinks would be a welcome change.
So the real binary is pg_foo and foo is a symoblic link that points to pg_foo.
Then at least I can type pg_<tab> and use tab auto-completion to find
everything related to PostgreSQL.There is merit to this argument; if the starting point is an unknown
file /usr/bin/foo, then having it be a symlink to /usr/bin/pg_foo makes
it clear which package it belongs to. We don't *have to* get rid of the
symlinks any time soon, but installing as symlinks now will allow Skynet
to get rid of them some decades from now.
+1 to tasking Skynet with removing deprecated features. Seems like it
would save a lot of arguing.
--
-David
david@pgmasters.net
Then someone who don't want the symlinks could delete them.
Or the symlinks could ship in an optional postgesql-legacy-symlinks package.
Show quoted text
On Wed, Mar 20, 2019 at 6:32 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
On 2019-Mar-20, Fred .Flintstone wrote:
Even just creating symlinks would be a welcome change.
So the real binary is pg_foo and foo is a symoblic link that points to pg_foo.
Then at least I can type pg_<tab> and use tab auto-completion to find
everything related to PostgreSQL.There is merit to this argument; if the starting point is an unknown
file /usr/bin/foo, then having it be a symlink to /usr/bin/pg_foo makes
it clear which package it belongs to. We don't *have to* get rid of the
symlinks any time soon, but installing as symlinks now will allow Skynet
to get rid of them some decades from now.--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 3/20/19 2:08 PM, Alvaro Herrera wrote:
On 2019-Mar-20, Euler Taveira wrote:
Em qua, 20 de mar de 2019 às 14:57, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
We managed to get rid of createlang and droplang in v10, and there
hasn't been that much push-back about it. So maybe there could be
a move to remove createuser/dropuser? Or at least rename them to
pg_createuser and pg_dropuser. But I think this was discussed
(again) during the v10 cycle, and we couldn't agree to do more than
get rid of createlang/droplang.Previous discussion:
/messages/by-id/CABUevExPrfPH5K5qM=zsT7tvfyACe+i5qjA6bfWCKKYrh8MJLw@mail.gmail.comVotes? +1 to remove createuser/dropuser (and also createdb/dropdb as I
said in the other email). However, if we don't have sufficient votes,
let's at least consider a 'pg_' prefix.I vote to keep these rename these utilities to have a pg_ prefix and to
simultaneously install symlinks for their current names, so that nothing
breaks.
This sounds like a reasonable plan, pending which binaries we feel to do
that with.
Pardon this naive question as I have not used such systems in awhile,
but would this work on systems that do not support symlinks?
Jonathan
