Re: PostgreSQL pollutes the file system

classic Classic list List threaded Threaded
112 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL pollutes the file system

Andreas Karlsson
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

Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL pollutes the file system

Fred .Flintstone
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL pollutes the file system

Chris Travers-7
In reply to this post by Andreas Karlsson


On Wed, Mar 20, 2019 at 11:06 AM Andreas Karlsson <[hidden email]> 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

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,

 

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

Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL pollutes the file system

Chris Howard
In reply to this post by Fred .Flintstone

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 <[hidden email]> 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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL pollutes the file system

Tom Lane-2
In reply to this post by Chris Travers-7
Chris Travers <[hidden email]> writes:
> On Wed, Mar 20, 2019 at 11:06 AM Andreas Karlsson <[hidden email]> 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
>> https://www.postgresql.org/message-id/47EA5CC0.8040102%40sun.com and
>> also more recently but I cannot find it in the archives right now.

And also before that, eg
https://www.postgresql.org/message-id/flat/199910091253.IAA10670%40candle.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

Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL pollutes the file system

Tatsuo Ishii-3
>>> 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.
>
> And also before that, eg
> https://www.postgresql.org/message-id/flat/199910091253.IAA10670%40candle.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.

+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

Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL pollutes the file system

Fred .Flintstone
In reply to this post by Tom Lane-2
On Wed, Mar 20, 2019 at 3:19 PM Tom Lane <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL pollutes the file system

Euler Taveira
In reply to this post by Tatsuo Ishii-3
Em qua, 20 de mar de 2019 às 11:39, Tatsuo Ishii <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL pollutes the file system

Euler Taveira
In reply to this post by Fred .Flintstone
Em qua, 20 de mar de 2019 às 14:22, Fred .Flintstone
<[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL pollutes the file system

Alvaro Herrera-9
In reply to this post by Fred .Flintstone
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

Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL pollutes the file system

Julien Rouhaud
In reply to this post by Euler Taveira
On Wed, Mar 20, 2019 at 6:25 PM Euler Taveira <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL pollutes the file system

Tom Lane-2
Julien Rouhaud <[hidden email]> writes:
> On Wed, Mar 20, 2019 at 6:25 PM Euler Taveira <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL pollutes the file system

Euler Taveira
Em qua, 20 de mar de 2019 às 14:57, Tom Lane <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL pollutes the file system

Alvaro Herrera-9
On 2019-Mar-20, Euler Taveira wrote:

> Em qua, 20 de mar de 2019 às 14:57, Tom Lane <[hidden email]> 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:
https://postgr.es/m/CABUevExPrfPH5K5qM=zsT7tvfyACe+i5qjA6bfWCKKYrh8MJLw@...

> 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

Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL pollutes the file system

Jehan-Guillaume de Rorthais
In reply to this post by Tom Lane-2
On Wed, 20 Mar 2019 13:56:55 -0400
Tom Lane <[hidden email]> wrote:

> Julien Rouhaud <[hidden email]> writes:
> > On Wed, Mar 20, 2019 at 6:25 PM Euler Taveira <[hidden email]>
> > 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".

++

Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL pollutes the file system

Tom Lane-2
In reply to this post by Fred .Flintstone
"Fred .Flintstone" <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL pollutes the file system

David Steele
In reply to this post by Alvaro Herrera-9
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
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL pollutes the file system

Fred .Flintstone
In reply to this post by Alvaro Herrera-9
Then someone who don't want the symlinks could delete them.
Or the symlinks could ship in an optional postgesql-legacy-symlinks package.

On Wed, Mar 20, 2019 at 6:32 PM Alvaro Herrera <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL pollutes the file system

Jonathan S. Katz-3
In reply to this post by Alvaro Herrera-9
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 <[hidden email]> 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:
> https://postgr.es/m/CABUevExPrfPH5K5qM=zsT7tvfyACe+i5qjA6bfWCKKYrh8MJLw@...
>
>> 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.
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


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL pollutes the file system

Fred .Flintstone
In reply to this post by Tom Lane-2
I would be fine with that.
We can make an exception for psql.

As long as we get rid of:
* clusterdb
* createdb
* createuser
* dropdb
* dropuser
* reindexdb
* vacuumdb

On Wed, Mar 20, 2019 at 7:11 PM Tom Lane <[hidden email]> wrote:

>
> "Fred .Flintstone" <[hidden email]> 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

1234 ... 6