Thread: Re: PostgreSQL pollutes the file system

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

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

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

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

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

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: 
https://postgr.es/m/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.

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:
> https://postgr.es/m/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.

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

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 <tgl@sss.pgh.pa.us> wrote:
>
> "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 2:11 PM, Tom Lane wrote:
> "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.

To add to that, for better or worse, many people associate the
PostgreSQL database itself as "psql" or "pgsql" ("I use psql, it's my
favorite database!").

If we are evaluating this whole symlink / renaming thing, there could be
arguments for a "pgsql" alias to psql (or vice versa), but I don't think
"pg_sql" makes any sense and could be fairly confusing.

Jonathan

The binaries:
* clusterdb
* createdb
* createuser
* dropdb
* dropuser
* reindexdb
* vacuumdb

On Wed, Mar 20, 2019 at 8:13 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>
> 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:
> > https://postgr.es/m/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.
>
> 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
>

On 2019-03-20 15:13:00 -0400, Jonathan S. Katz wrote:
> Pardon this naive question as I have not used such systems in awhile,
> but would this work on systems that do not support symlinks?

We can just copy the binaries there, they're not that big anyway.

Hi,

On 2019-03-20 15:15:02 -0400, Jonathan S. Katz wrote:
> If we are evaluating this whole symlink / renaming thing, there could be
> arguments for a "pgsql" alias to psql (or vice versa), but I don't think
> "pg_sql" makes any sense and could be fairly confusing.

I don't care much about createdb etc, but I'm *strongly* against
renaming psql and/or adding symlinks. That's like 95% of all
interactions people have with postgres binaries, making that more
confusing would be an enterily unnecessary self own.

Greetings,

Andres Freund

On 3/20/19 3:19 PM, Andres Freund wrote:
> Hi,
>
> On 2019-03-20 15:15:02 -0400, Jonathan S. Katz wrote:
>> If we are evaluating this whole symlink / renaming thing, there could be
>> arguments for a "pgsql" alias to psql (or vice versa), but I don't think
>> "pg_sql" makes any sense and could be fairly confusing.
>
> I don't care much about createdb etc, but I'm *strongly* against
> renaming psql and/or adding symlinks. That's like 95% of all
> interactions people have with postgres binaries, making that more
> confusing would be an enterily unnecessary self own.

Yeah I agree. The only one I would entertain is "pgsql" given enough
people refer to PostgreSQL as such, but note I use the term "entertain"
in a similar way to when I knowingly watch terrible movies.

Jonathan

On 2019-Mar-20, Andres Freund wrote:

> On 2019-03-20 15:15:02 -0400, Jonathan S. Katz wrote:
> > If we are evaluating this whole symlink / renaming thing, there could be
> > arguments for a "pgsql" alias to psql (or vice versa), but I don't think
> > "pg_sql" makes any sense and could be fairly confusing.
> 
> I don't care much about createdb etc, but I'm *strongly* against
> renaming psql and/or adding symlinks.

+1.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 3/20/19 7: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: 
> https://postgr.es/m/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.
> 

I don't really understand what issue are we trying to solve here.

Can someone describe a scenario where this (name of the binary not
clearly indicating it's related postgres) causes issues in practice? On
my system, there are ~1400 binaries in /usr/bin, and for the vast
majority of them it's rather unclear where do they come from.

But it's not really an issue, because we have tools to do that

1) man

2) -h/--help

3) rpm -qf $file (and similarly for other packagers)

4) set --prefix to install binaries so separate directory (which some
distros already do anyway)

So to me this seems like a fairly invasive change (potentially breaking
quite a few scripts/tools) just to address a minor inconvenience.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

>> +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)?

At least psql, initdb, pg_config, pgbench and pg_ctl for now. But I
don't want to say that renaming other commands would be fine for me
because I would like to take a liberty to extend my tool for my users.

BTW, a strange thing in the whole discussion is, installing those
PostgreSQL commands in /usr/bin is done by packagers, not PostgreSQL
core project itself. The default installation directory has been
/usr/local/pgsql/bin in the source code of PostgreSQL since it was
born, and I love the place. Forcing to install everything into
/usr/bin is distributions' policy, not PostgreSQL core project's as
far as I know. So I wonder why people don't ask the renaming request
to packagers, rather than PostgreSQL core project itself.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

> I don't really understand what issue are we trying to solve here.
> 
> Can someone describe a scenario where this (name of the binary not
> clearly indicating it's related postgres) causes issues in practice? On
> my system, there are ~1400 binaries in /usr/bin, and for the vast
> majority of them it's rather unclear where do they come from.
> 
> But it's not really an issue, because we have tools to do that
> 
> 1) man
> 
> 2) -h/--help
> 
> 3) rpm -qf $file (and similarly for other packagers)
> 
> 4) set --prefix to install binaries so separate directory (which some
> distros already do anyway)
> 
> So to me this seems like a fairly invasive change (potentially breaking
> quite a few scripts/tools) just to address a minor inconvenience.

+1.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

On Thu, Mar 21, 2019 at 08:41:32AM +0900, Tatsuo Ishii wrote:
>> Can someone describe a scenario where this (name of the binary not
>> clearly indicating it's related postgres) causes issues in practice? On
>> my system, there are ~1400 binaries in /usr/bin, and for the vast
>> majority of them it's rather unclear where do they come from.

Naming conflict because our binary names are too generic?  createdb
could for example be applied to any database, and not only Postgres.
(I have 1600 entries in /usr/bin on a Debian installation.)

>>
>> But it's not really an issue, because we have tools to do that
>>
>> 1) man
>>
>> 2) -h/--help
>>
>> 3) rpm -qf $file (and similarly for other packagers)
>>
>> 4) set --prefix to install binaries so separate directory (which some
>> distros already do anyway)
>>
>> So to me this seems like a fairly invasive change (potentially breaking
>> quite a few scripts/tools) just to address a minor inconvenience.
>
> +1.

Yes, +1.
--
Michael

On 3/21/19 1:49 AM, Michael Paquier wrote:
> On Thu, Mar 21, 2019 at 08:41:32AM +0900, Tatsuo Ishii wrote:
>>> Can someone describe a scenario where this (name of the binary not
>>> clearly indicating it's related postgres) causes issues in practice? On
>>> my system, there are ~1400 binaries in /usr/bin, and for the vast
>>> majority of them it's rather unclear where do they come from.
> 
> Naming conflict because our binary names are too generic?  createdb
> could for example be applied to any database, and not only Postgres.
> (I have 1600 entries in /usr/bin on a Debian installation.)
> 

Maybe. Do we actually know about such cases? Also, isn't setting
--prefix a suitable solution? I mean, it's what we/packagers do to
support installing multiple Pg versions (in which case it'll conflict no
matter how we rename stuff) anyway.


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> On 3/21/19 1:49 AM, Michael Paquier wrote:
>> On Thu, Mar 21, 2019 at 08:41:32AM +0900, Tatsuo Ishii wrote:
>>> Can someone describe a scenario where this (name of the binary not
>>> clearly indicating it's related postgres) causes issues in practice?

>> Naming conflict because our binary names are too generic?

> Maybe. Do we actually know about such cases?

More to the point, we have now got twenty+ years seniority on any other
package that might want those /usr/bin names.  So a conflict is not
*really* going to happen, or at least it's not going to be our problem
if it does.

The whole thing is unfortunate, without a doubt, but it's still
unclear that renaming those programs will buy anything that's worth
the conversion costs.  I'd be happy to pay said costs if it were all
falling to this project to do so ... but most of the pain will be
borne by other people.

            regards, tom lane

At 2019-03-20 23:22:44 +0100, tomas.vondra@2ndquadrant.com wrote:
>
> I don't really understand what issue are we trying to solve here.
> 
> Can someone describe a scenario where this (name of the binary not
> clearly indicating it's related postgres) causes issues in practice?
> On my system, there are ~1400 binaries in /usr/bin, and for the vast
> majority of them it's rather unclear where do they come from.

It sounds like a problem especially when described with charged terms
like "pollutes", but I agree with you and others that it just doesn't
seem worth the effort to try to rename everything.

-- Abhijit

On 3/20/19 8:19 PM, Andres Freund wrote:
> On 2019-03-20 15:15:02 -0400, Jonathan S. Katz wrote:
>> If we are evaluating this whole symlink / renaming thing, there could be
>> arguments for a "pgsql" alias to psql (or vice versa), but I don't think
>> "pg_sql" makes any sense and could be fairly confusing.
> 
> I don't care much about createdb etc, but I'm *strongly* against
> renaming psql and/or adding symlinks. That's like 95% of all
> interactions people have with postgres binaries, making that more
> confusing would be an enterily unnecessary self own.

+1 "psql" as a tool for connecting to PostgreSQL is so well established 
that renaming it would just confuse everyone.

Andreas

On 2019-Mar-20, Tomas Vondra wrote:

> So to me this seems like a fairly invasive change (potentially breaking
> quite a few scripts/tools) just to address a minor inconvenience.

I don't think anything would break, actually.  What are you thinking
would break?

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 3/21/19 7:07 AM, Chris Travers wrote:
> 1.  createuser/dropuser are things that I don't consider good ways of 
> creating users anyway.  I think we should just consider removing these 
> binaries.  The SQL queries are better, more functional, and can be 
> rolled back as a part of a larger transaction.

Those binaries are pretty convenient to use in scripts since they handle 
SQL escaping for you, but probably not convenient enough that we would 
have added createuser today.

Compare

createuser "$USER"

vs

echo 'CREATE ROLE :"user" LOGIN' | psql postgres -v "user=$USER"

Andreas

Andreas Karlsson <andreas@proxel.se> writes:
> On 3/21/19 7:07 AM, Chris Travers wrote:
>> 1.  createuser/dropuser are things that I don't consider good ways of 
>> creating users anyway.

> Those binaries are pretty convenient to use in scripts since they handle 
> SQL escaping for you, but probably not convenient enough that we would 
> have added createuser today.

> Compare
> createuser "$USER"
> vs
> echo 'CREATE ROLE :"user" LOGIN' | psql postgres -v "user=$USER"

Hmm.  That example is actually quite scary, because while nearly
anybody who's ever done any shell scripting would get the first
one right, the second one requires a fair deal of specialized
knowledge and creativity.  I fear that 99% of people would have
coded it like

    echo "CREATE USER $USER" | psql

or some variant on that, and now they have a SQL-injection
hazard that they didn't have before.

So there seems like a real risk that taking away createuser would
result in security holes, not just annoying-but-trivial script update
work.  That puts me more in the camp of "if we're going to do anything,
rename it with a pg_ prefix" than "if we're going to do anything,
remove it".

            regards, tom lane

On Thu, Mar 21, 2019 at 10:02:40AM -0400, Tom Lane wrote:
> So there seems like a real risk that taking away createuser would
> result in security holes, not just annoying-but-trivial script update
> work.  That puts me more in the camp of "if we're going to do anything,
> rename it with a pg_ prefix" than "if we're going to do anything,
> remove it".

Removing it would be a bad idea as it is very easy to mess up with
things in such cases.  As you mentioned, renaming the tools now would
create more pain than actually solving things, so that's a bad idea
anyway.

I would be curious to hear the reason why such tool names have been
chosen from the start.  The tools have been switched to C in 9e0ab71
from 2003, have been introduced by Peter Eisentraut as of 240e4c9 from
1999, and I cannot spot the thread from the time where this was
discussed.
--
Michael

Michael Paquier <michael@paquier.xyz> writes:
> I would be curious to hear the reason why such tool names have been
> chosen from the start.  The tools have been switched to C in 9e0ab71
> from 2003, have been introduced by Peter Eisentraut as of 240e4c9 from
> 1999, and I cannot spot the thread from the time where this was
> discussed.

createuser, at least, dates back to Berkeley days: my copy of the
PG v4r2 tarball contains a "src/bin/createuser/createuser.sh" file
dated 1994-03-19.  (The 1999 commit you mention just moved the
functionality around; it was there before.)  So I imagine the answer
is that nobody at the time thought of fitting these scripts into a
larger ecosystem.

            regards, tom lane

On 22/03/19 3:05 PM, Tom Lane wrote:
> Michael Paquier <michael@paquier.xyz> writes:
>> I would be curious to hear the reason why such tool names have been
>> chosen from the start.  The tools have been switched to C in 9e0ab71
>> from 2003, have been introduced by Peter Eisentraut as of 240e4c9 from
>> 1999, and I cannot spot the thread from the time where this was
>> discussed.
> createuser, at least, dates back to Berkeley days: my copy of the
> PG v4r2 tarball contains a "src/bin/createuser/createuser.sh" file
> dated 1994-03-19.  (The 1999 commit you mention just moved the
> functionality around; it was there before.)  So I imagine the answer
> is that nobody at the time thought of fitting these scripts into a
> larger ecosystem.


FWIW the whole set is there in version 6.4.2:

markir@vedavec:/download/postgres/src/postgresql-6.4.2/src/bin$ ls -l
total 72
drwxr-sr-x 3 markir adm 4096 Dec 31  1998 cleardbdir
drwxr-sr-x 3 markir adm 4096 Dec 31  1998 createdb
drwxr-sr-x 3 markir adm 4096 Dec 31  1998 createuser
drwxr-sr-x 2 markir adm 4096 Dec 31  1998 CVS
drwxr-sr-x 3 markir adm 4096 Dec 31  1998 destroydb
drwxr-sr-x 3 markir adm 4096 Dec 31  1998 destroyuser
drwxr-sr-x 3 markir adm 4096 Dec 31  1998 initdb
drwxr-sr-x 3 markir adm 4096 Dec 31  1998 initlocation
drwxr-sr-x 3 markir adm 4096 Dec 31  1998 ipcclean
-rw-r--r-- 1 markir adm  795 Dec 19  1998 Makefile
drwxr-sr-x 3 markir adm 4096 Dec 31  1998 pgaccess
drwxr-sr-x 3 markir adm 4096 Dec 31  1998 pg_dump
drwxr-sr-x 3 markir adm 4096 Dec 31  1998 pg_encoding
drwxr-sr-x 3 markir adm 4096 Dec 31  1998 pg_id
drwxr-sr-x 3 markir adm 4096 Dec 31  1998 pg_passwd
drwxr-sr-x 3 markir adm 4096 Dec 31  1998 pgtclsh
drwxr-sr-x 3 markir adm 4096 Dec 31  1998 pg_version
drwxr-sr-x 3 markir adm 4096 Dec 31  1998 psql

--

Mark

Many of these are gone in the modern PostgreSQL, a few remain.
https://packages.ubuntu.com/disco/amd64/postgresql-client-11/filelist

/usr/lib/postgresql/11/bin/clusterdb
/usr/lib/postgresql/11/bin/createdb
/usr/lib/postgresql/11/bin/createuser
/usr/lib/postgresql/11/bin/dropdb
/usr/lib/postgresql/11/bin/dropuser
/usr/lib/postgresql/11/bin/pg_basebackup
/usr/lib/postgresql/11/bin/pg_dump
/usr/lib/postgresql/11/bin/pg_dumpall
/usr/lib/postgresql/11/bin/pg_isready
/usr/lib/postgresql/11/bin/pg_receivewal
/usr/lib/postgresql/11/bin/pg_recvlogical
/usr/lib/postgresql/11/bin/pg_restore
/usr/lib/postgresql/11/bin/psql
/usr/lib/postgresql/11/bin/reindexdb
/usr/lib/postgresql/11/bin/vacuumdb

Can we rename clusterdb, reindexdb and vacuumdb to carry the pg_ prefix?

On Fri, Mar 22, 2019 at 3:13 AM Mark Kirkwood
<mark.kirkwood@catalyst.net.nz> wrote:
>
> On 22/03/19 3:05 PM, Tom Lane wrote:
> > Michael Paquier <michael@paquier.xyz> writes:
> >> I would be curious to hear the reason why such tool names have been
> >> chosen from the start.  The tools have been switched to C in 9e0ab71
> >> from 2003, have been introduced by Peter Eisentraut as of 240e4c9 from
> >> 1999, and I cannot spot the thread from the time where this was
> >> discussed.
> > createuser, at least, dates back to Berkeley days: my copy of the
> > PG v4r2 tarball contains a "src/bin/createuser/createuser.sh" file
> > dated 1994-03-19.  (The 1999 commit you mention just moved the
> > functionality around; it was there before.)  So I imagine the answer
> > is that nobody at the time thought of fitting these scripts into a
> > larger ecosystem.
>
>
> FWIW the whole set is there in version 6.4.2:
>
> markir@vedavec:/download/postgres/src/postgresql-6.4.2/src/bin$ ls -l
> total 72
> drwxr-sr-x 3 markir adm 4096 Dec 31  1998 cleardbdir
> drwxr-sr-x 3 markir adm 4096 Dec 31  1998 createdb
> drwxr-sr-x 3 markir adm 4096 Dec 31  1998 createuser
> drwxr-sr-x 2 markir adm 4096 Dec 31  1998 CVS
> drwxr-sr-x 3 markir adm 4096 Dec 31  1998 destroydb
> drwxr-sr-x 3 markir adm 4096 Dec 31  1998 destroyuser
> drwxr-sr-x 3 markir adm 4096 Dec 31  1998 initdb
> drwxr-sr-x 3 markir adm 4096 Dec 31  1998 initlocation
> drwxr-sr-x 3 markir adm 4096 Dec 31  1998 ipcclean
> -rw-r--r-- 1 markir adm  795 Dec 19  1998 Makefile
> drwxr-sr-x 3 markir adm 4096 Dec 31  1998 pgaccess
> drwxr-sr-x 3 markir adm 4096 Dec 31  1998 pg_dump
> drwxr-sr-x 3 markir adm 4096 Dec 31  1998 pg_encoding
> drwxr-sr-x 3 markir adm 4096 Dec 31  1998 pg_id
> drwxr-sr-x 3 markir adm 4096 Dec 31  1998 pg_passwd
> drwxr-sr-x 3 markir adm 4096 Dec 31  1998 pgtclsh
> drwxr-sr-x 3 markir adm 4096 Dec 31  1998 pg_version
> drwxr-sr-x 3 markir adm 4096 Dec 31  1998 psql
>
> --
>
> Mark
>
>

On Wed, Mar 27, 2019 at 02:31:14PM +0100, Fred .Flintstone wrote:
>Many of these are gone in the modern PostgreSQL, a few remain.
>https://packages.ubuntu.com/disco/amd64/postgresql-client-11/filelist
>
>/usr/lib/postgresql/11/bin/clusterdb
>/usr/lib/postgresql/11/bin/createdb
>/usr/lib/postgresql/11/bin/createuser
>/usr/lib/postgresql/11/bin/dropdb
>/usr/lib/postgresql/11/bin/dropuser
>/usr/lib/postgresql/11/bin/pg_basebackup
>/usr/lib/postgresql/11/bin/pg_dump
>/usr/lib/postgresql/11/bin/pg_dumpall
>/usr/lib/postgresql/11/bin/pg_isready
>/usr/lib/postgresql/11/bin/pg_receivewal
>/usr/lib/postgresql/11/bin/pg_recvlogical
>/usr/lib/postgresql/11/bin/pg_restore
>/usr/lib/postgresql/11/bin/psql
>/usr/lib/postgresql/11/bin/reindexdb
>/usr/lib/postgresql/11/bin/vacuumdb
>
>Can we rename clusterdb, reindexdb and vacuumdb to carry the pg_ prefix?
>

I think the consensus in this thread (and the previous ancient ones) is
that it's not worth it. It's one thing to introduce new commands with the
pg_ prefix, and it's a completely different thing to rename existing ones.
That has inherent costs, and as Tom pointed out the burden would fall on
people using PostgreSQL (and that's rather undesirable).

I personally don't see why having commands without pg_ prefix would be
an issue. Especially when placed in a separate directory, which eliminates
the possibility of conflict with other commands.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

It does not matter if they are in a different directory, because when
I use tab-completion in the shell, then all commands show.
I type "create<tab>" then "createdb" and "createuser" shows up. This
is very confusing, and I don't know if this creates a Linux system
user account or a PostgreSQL account. Without knowing better, I would
be inclined to believe such a command would create a system account.

It gets even more confusing when a user have multiple database servers
installed such as MySQL and PostgreSQL or MongoDB and PostgreSQL. Then
it is very confusing what "createdb" does.


On Wed, Mar 27, 2019 at 2:51 PM Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
>
> On Wed, Mar 27, 2019 at 02:31:14PM +0100, Fred .Flintstone wrote:
> >Many of these are gone in the modern PostgreSQL, a few remain.
> >https://packages.ubuntu.com/disco/amd64/postgresql-client-11/filelist
> >
> >/usr/lib/postgresql/11/bin/clusterdb
> >/usr/lib/postgresql/11/bin/createdb
> >/usr/lib/postgresql/11/bin/createuser
> >/usr/lib/postgresql/11/bin/dropdb
> >/usr/lib/postgresql/11/bin/dropuser
> >/usr/lib/postgresql/11/bin/pg_basebackup
> >/usr/lib/postgresql/11/bin/pg_dump
> >/usr/lib/postgresql/11/bin/pg_dumpall
> >/usr/lib/postgresql/11/bin/pg_isready
> >/usr/lib/postgresql/11/bin/pg_receivewal
> >/usr/lib/postgresql/11/bin/pg_recvlogical
> >/usr/lib/postgresql/11/bin/pg_restore
> >/usr/lib/postgresql/11/bin/psql
> >/usr/lib/postgresql/11/bin/reindexdb
> >/usr/lib/postgresql/11/bin/vacuumdb
> >
> >Can we rename clusterdb, reindexdb and vacuumdb to carry the pg_ prefix?
> >
>
> I think the consensus in this thread (and the previous ancient ones) is
> that it's not worth it. It's one thing to introduce new commands with the
> pg_ prefix, and it's a completely different thing to rename existing ones.
> That has inherent costs, and as Tom pointed out the burden would fall on
> people using PostgreSQL (and that's rather undesirable).
>
> I personally don't see why having commands without pg_ prefix would be
> an issue. Especially when placed in a separate directory, which eliminates
> the possibility of conflict with other commands.
>
> regards
>
> --
> Tomas Vondra                  http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>

On 2019-Mar-27, Tomas Vondra wrote:

> I think the consensus in this thread (and the previous ancient ones) is
> that it's not worth it. It's one thing to introduce new commands with the
> pg_ prefix, and it's a completely different thing to rename existing ones.
> That has inherent costs, and as Tom pointed out the burden would fall on
> people using PostgreSQL (and that's rather undesirable).

I thought the consensus was to rename them, and install symlinks to the
old names.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 3/27/19 2:51 PM, Tomas Vondra wrote:
> I think the consensus in this thread (and the previous ancient ones) is
> that it's not worth it. It's one thing to introduce new commands with the
> pg_ prefix, and it's a completely different thing to rename existing ones.
> That has inherent costs, and as Tom pointed out the burden would fall on
> people using PostgreSQL (and that's rather undesirable).
> 
> I personally don't see why having commands without pg_ prefix would be
> an issue. Especially when placed in a separate directory, which eliminates
> the possibility of conflict with other commands.

I buy that it may not be worth breaking tens of thousands of scripts to 
fix this, but I disagree about it not being an issue. Most Linux 
distributions add PostgreSQL's executables in to a directory which is in 
the default $PATH (/usr/bin in the case of Debian). And even if it would 
be installed into a separate directory there would still be a conflict 
as soon as that directory is added to $PATH.

And I think that it is also relatively easy to confuse adduser and 
createuser when reading a script. Nothing about the name createuser 
indicates that it will create a role in an SQL database.

Andreas

On Wed, Mar 27, 2019 at 11:00:18AM -0300, Alvaro Herrera wrote:
>On 2019-Mar-27, Tomas Vondra wrote:
>
>> I think the consensus in this thread (and the previous ancient ones) is
>> that it's not worth it. It's one thing to introduce new commands with the
>> pg_ prefix, and it's a completely different thing to rename existing ones.
>> That has inherent costs, and as Tom pointed out the burden would fall on
>> people using PostgreSQL (and that's rather undesirable).
>
>I thought the consensus was to rename them, and install symlinks to the
>old names.
>

I know symlinks were mentioned/proposed, but I don't think there's a clear
consensus to do that. I might have missed that part of the discussion.

That being said, I'm not strongly opposed to doing that, although I still
don't see the need to do that ...

regard

>-- 
>Álvaro Herrera                https://www.2ndQuadrant.com/
>PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2019-Mar-27, Tomas Vondra wrote:
>> I think the consensus in this thread (and the previous ancient ones) is
>> that it's not worth it. It's one thing to introduce new commands with the
>> pg_ prefix, and it's a completely different thing to rename existing ones.
>> That has inherent costs, and as Tom pointed out the burden would fall on
>> people using PostgreSQL (and that's rather undesirable).

> I thought the consensus was to rename them, and install symlinks to the
> old names.

The question is what's the endgame.  We haven't actually fixed the
complained-of confusion problem unless we eventually remove createuser
and dropuser under those names.  Are we prepared to force script
breakage of that sort, even over a multi-year deprecation cycle?

(As a comparison point, I note that we still haven't removed the
"postmaster" symlink, though it's been deprecated for at least a
dozen years.)

            regards, tom lane

On Wed, Mar 27, 2019 at 03:07:24PM +0100, Andreas Karlsson wrote:
>On 3/27/19 2:51 PM, Tomas Vondra wrote:
>>I think the consensus in this thread (and the previous ancient ones) is
>>that it's not worth it. It's one thing to introduce new commands with the
>>pg_ prefix, and it's a completely different thing to rename existing ones.
>>That has inherent costs, and as Tom pointed out the burden would fall on
>>people using PostgreSQL (and that's rather undesirable).
>>
>>I personally don't see why having commands without pg_ prefix would be
>>an issue. Especially when placed in a separate directory, which eliminates
>>the possibility of conflict with other commands.
>
>I buy that it may not be worth breaking tens of thousands of scripts 
>to fix this, but I disagree about it not being an issue. Most Linux 
>distributions add PostgreSQL's executables in to a directory which is 
>in the default $PATH (/usr/bin in the case of Debian). And even if it 
>would be installed into a separate directory there would still be a 
>conflict as soon as that directory is added to $PATH.
>

That is true, of course. But are there actual examples of such conflicts
in practice? I mean, are there tools/packages that provide commands with
a conflicting name? I'm not aware of any, and as was pointed before, we'd
have ~20 years of history on any new ones.

>And I think that it is also relatively easy to confuse adduser and 
>createuser when reading a script. Nothing about the name createuser 
>indicates that it will create a role in an SQL database.
>

Sure, and I've confused those tools too in the past. But that's not
something you'll hit in a script, at least not if you test it before
running it on production system. And if you're running untested scripts,
this is likely the least of your problems ...

cheers

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 3/27/19 3:26 PM, Tomas Vondra wrote:
> That is true, of course. But are there actual examples of such conflicts
> in practice? I mean, are there tools/packages that provide commands with
> a conflicting name? I'm not aware of any, and as was pointed before, we'd
> have ~20 years of history on any new ones.

That is a fair argument. Since we squatted those names back in the 
mid-90s I think the risk of collision is low.

Andreas

Andreas Karlsson <andreas@proxel.se> writes:
> On 3/27/19 3:26 PM, Tomas Vondra wrote:
>> That is true, of course. But are there actual examples of such conflicts
>> in practice? I mean, are there tools/packages that provide commands with
>> a conflicting name? I'm not aware of any, and as was pointed before, we'd
>> have ~20 years of history on any new ones.

> That is a fair argument. Since we squatted those names back in the 
> mid-90s I think the risk of collision is low.

Right.  I think there is a fair argument to be made for user confusion
(not actual conflict) with respect to createuser and dropuser.  The
argument for renaming any of the other tools is much weaker, IMO.

            regards, tom lane

On 2019-Mar-27, Tom Lane wrote:

> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > On 2019-Mar-27, Tomas Vondra wrote:
> >> I think the consensus in this thread (and the previous ancient ones) is
> >> that it's not worth it. It's one thing to introduce new commands with the
> >> pg_ prefix, and it's a completely different thing to rename existing ones.
> >> That has inherent costs, and as Tom pointed out the burden would fall on
> >> people using PostgreSQL (and that's rather undesirable).
> 
> > I thought the consensus was to rename them, and install symlinks to the
> > old names.
> 
> The question is what's the endgame.  We haven't actually fixed the
> complained-of confusion problem unless we eventually remove createuser
> and dropuser under those names.

Well, partly we have, because there mere act of having a symlink
documents the command via the symlink target.

Somebody proposed to rename createuser not to pg_createuser, though, but
rather to pg_createrole; ditto dropuser.  That seems to make sense.

I additionally proposed (nobody replied to this part) that we could have
the command print a WARNING if the argv[0] is shown to be the old name.
Not necessarily in pg12; maybe we can have them print such a warning in
pg13, and then remove the old names three years from now, or something
like that.

I suppose that if you're a Postgres developer, you naturally expect that
"createdb" creates a Postgres DB.  What if you use multiple database
systems, and then only occasionally have to do DBA tasks?  I find this
POV that createdb doesn't need renaming a bit self-centered.

> Are we prepared to force script breakage of that sort, even over a
> multi-year deprecation cycle?

Why not?

> (As a comparison point, I note that we still haven't removed the
> "postmaster" symlink, though it's been deprecated for at least a
> dozen years.)

I don't think that change was because of executable namespace pollution
or user confusion.  (Commit 5266f221a2e1, can't find the discussion
though.)

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Wed, 2019-03-27 at 15:07 +0100, Andreas Karlsson wrote:
> [EXTERNAL SOURCE]
> 
> 
> 
> On 3/27/19 2:51 PM, Tomas Vondra wrote:
> > I think the consensus in this thread (and the previous ancient ones) is
> > that it's not worth it. It's one thing to introduce new commands with the
> > pg_ prefix, and it's a completely different thing to rename existing ones.
> > That has inherent costs, and as Tom pointed out the burden would fall on
> > people using PostgreSQL (and that's rather undesirable).
> > 
> > I personally don't see why having commands without pg_ prefix would be
> > an issue. Especially when placed in a separate directory, which eliminates
> > the possibility of conflict with other commands.
> 
> I buy that it may not be worth breaking tens of thousands of scripts to
> fix this, but I disagree about it not being an issue. Most Linux
> distributions add PostgreSQL's executables in to a directory which is in
> the default $PATH (/usr/bin in the case of Debian). And even if it would
> be installed into a separate directory there would still be a conflict
> as soon as that directory is added to $PATH.
> 
> And I think that it is also relatively easy to confuse adduser and
> createuser when reading a script. Nothing about the name createuser
> indicates that it will create a role in an SQL database.
> 
> Andreas
> 

theres nothing about createuser or adduser( useradd on my system,
adduser doesn't exist on mine ) that indicates that either would/should
create a user in the system either.  That's what man and -h/--help are
for.  If you don't know what an executable does, don't invoke it until
you do.  That's a basic premise for any executable.

reid

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> I suppose that if you're a Postgres developer, you naturally expect that
> "createdb" creates a Postgres DB.  What if you use multiple database
> systems, and then only occasionally have to do DBA tasks?  I find this
> POV that createdb doesn't need renaming a bit self-centered.

Nobody is defending the existing names as being something we'd pick
if we were picking them today.  The question is whether changing them
is worth the pain.  (And, one more time, may I point out that most
of the pain will be borne by people not on this mailing list, hence
unable to vote here.)  I don't think there is any reasonable argument
that said pain will be justified for any of them except maybe createuser
and dropuser.

>> "postmaster" symlink, though it's been deprecated for at least a
>> dozen years.)

> I don't think that change was because of executable namespace pollution
> or user confusion.  (Commit 5266f221a2e1, can't find the discussion
> though.)

My recollection of the discussion is that people argued that "postmaster"
might be taken to have something to do with an e-mail server, and
therefore we needed to stop using that name.  The lack of either follow-on
complaints or follow-on action doesn't make me too well disposed to
what is essentially that same argument over again.

            regards, tom lane

On 27/03/2019 15:26, Tomas Vondra wrote:
> On Wed, Mar 27, 2019 at 03:07:24PM +0100, Andreas Karlsson wrote:
>> On 3/27/19 2:51 PM, Tomas Vondra wrote:
>>> I think the consensus in this thread (and the previous ancient ones) is
>>> that it's not worth it. It's one thing to introduce new commands with
>>> the
>>> pg_ prefix, and it's a completely different thing to rename existing
>>> ones.
>>> That has inherent costs, and as Tom pointed out the burden would fall on
>>> people using PostgreSQL (and that's rather undesirable).
>>>
>>> I personally don't see why having commands without pg_ prefix would be
>>> an issue. Especially when placed in a separate directory, which
>>> eliminates
>>> the possibility of conflict with other commands.
>>
>> I buy that it may not be worth breaking tens of thousands of scripts
>> to fix this, but I disagree about it not being an issue. Most Linux
>> distributions add PostgreSQL's executables in to a directory which is
>> in the default $PATH (/usr/bin in the case of Debian). And even if it
>> would be installed into a separate directory there would still be a
>> conflict as soon as that directory is added to $PATH.
>>
> 
> That is true, of course.

It's only partially true, for example on my systems:

Debian/Ubuntu:
$ readlink -f /usr/bin/createuser
/usr/share/postgresql-common/pg_wrapper

Centos (PGDG package):
readlink -f /usr/bin/createdb
/usr/pgsql-11/bin/createdb

This also means that the idea about symlinks is something packages
already do.

-- 
  Petr Jelinek                  http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services

Symlinks would be great, because then the symlinks could be packaged
as an optional package.
such as;
- postgresql-11
- postgresql-client-11
- postgresql-client-symlinks-11
- postgresql-client-common
- postgresql-common

Then one might chose to not install the symlinks package or uninstall it.

And it would ease discoverability, predictability, intuitiveness, and
ease-of-use so much by just being able to type pg_<tab> to discover
all the PostgreSQL-related commands.

On Wed, Mar 27, 2019 at 6:26 PM Petr Jelinek
<petr.jelinek@2ndquadrant.com> wrote:
>
> On 27/03/2019 15:26, Tomas Vondra wrote:
> > On Wed, Mar 27, 2019 at 03:07:24PM +0100, Andreas Karlsson wrote:
> >> On 3/27/19 2:51 PM, Tomas Vondra wrote:
> >>> I think the consensus in this thread (and the previous ancient ones) is
> >>> that it's not worth it. It's one thing to introduce new commands with
> >>> the
> >>> pg_ prefix, and it's a completely different thing to rename existing
> >>> ones.
> >>> That has inherent costs, and as Tom pointed out the burden would fall on
> >>> people using PostgreSQL (and that's rather undesirable).
> >>>
> >>> I personally don't see why having commands without pg_ prefix would be
> >>> an issue. Especially when placed in a separate directory, which
> >>> eliminates
> >>> the possibility of conflict with other commands.
> >>
> >> I buy that it may not be worth breaking tens of thousands of scripts
> >> to fix this, but I disagree about it not being an issue. Most Linux
> >> distributions add PostgreSQL's executables in to a directory which is
> >> in the default $PATH (/usr/bin in the case of Debian). And even if it
> >> would be installed into a separate directory there would still be a
> >> conflict as soon as that directory is added to $PATH.
> >>
> >
> > That is true, of course.
>
> It's only partially true, for example on my systems:
>
> Debian/Ubuntu:
> $ readlink -f /usr/bin/createuser
> /usr/share/postgresql-common/pg_wrapper
>
> Centos (PGDG package):
> readlink -f /usr/bin/createdb
> /usr/pgsql-11/bin/createdb
>
> This also means that the idea about symlinks is something packages
> already do.
>
> --
>   Petr Jelinek                  http://www.2ndQuadrant.com/
>   PostgreSQL Development, 24x7 Support, Training & Services

On 2019-Mar-27, Tom Lane wrote:

> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > I suppose that if you're a Postgres developer, you naturally expect that
> > "createdb" creates a Postgres DB.  What if you use multiple database
> > systems, and then only occasionally have to do DBA tasks?  I find this
> > POV that createdb doesn't need renaming a bit self-centered.
> 
> Nobody is defending the existing names as being something we'd pick
> if we were picking them today.  The question is whether changing them
> is worth the pain.  (And, one more time, may I point out that most
> of the pain will be borne by people not on this mailing list, hence
> unable to vote here.)  I don't think there is any reasonable argument
> that said pain will be justified for any of them except maybe createuser
> and dropuser.

The implicit argument here is that existing users are a larger
population than future users.  I, for one, don't believe that.  I think
taking no action is a disservice to future users.  Also, that modifying
the code will be utterly painful and that less administrative code will be
written in the future than has already been written.

We *could* run a poll on twitter/slack/website to get a feeling on a
wider population.  That would still reach mostly existing Postgres
users, but at least it would be much more diverse than this group.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 28/03/2019 03:07, Andreas Karlsson wrote:
> On 3/27/19 2:51 PM, Tomas Vondra wrote:
>> I think the consensus in this thread (and the previous ancient ones) is
>> that it's not worth it. It's one thing to introduce new commands with 
>> the
>> pg_ prefix, and it's a completely different thing to rename existing 
>> ones.
>> That has inherent costs, and as Tom pointed out the burden would fall on
>> people using PostgreSQL (and that's rather undesirable).
>>
>> I personally don't see why having commands without pg_ prefix would be
>> an issue. Especially when placed in a separate directory, which 
>> eliminates
>> the possibility of conflict with other commands.
>
> I buy that it may not be worth breaking tens of thousands of scripts 
> to fix this, but I disagree about it not being an issue. Most Linux 
> distributions add PostgreSQL's executables in to a directory which is 
> in the default $PATH (/usr/bin in the case of Debian). And even if it 
> would be installed into a separate directory there would still be a 
> conflict as soon as that directory is added to $PATH.
>
> And I think that it is also relatively easy to confuse adduser and 
> createuser when reading a script. Nothing about the name createuser 
> indicates that it will create a role in an SQL database.
>
> Andreas
>
>
Existing users would feel some pain, but continued use of commands  
'creatuser' rather than pg_createuser (better still pg_createrole, as 
suggested elsewhere) create confusion and display unintended arrogance.

There is a suggestion to use aliases, and I think that is a good interim 
step, to introduce the 'pg_' variants. Possible with an option at 
install time to force only 'pg_' variants (with the possible exception 
of psql).

The only command, that I think warrants a permanent alias is psql, which 
I think is not ambiguous, but having a pg_sql for consistency would be good.


Cheers,
Gavin

On 28/03/2019 03:41, Tom Lane wrote:
> Andreas Karlsson <andreas@proxel.se> writes:
>> On 3/27/19 3:26 PM, Tomas Vondra wrote:
>>> That is true, of course. But are there actual examples of such conflicts
>>> in practice? I mean, are there tools/packages that provide commands with
>>> a conflicting name? I'm not aware of any, and as was pointed before, we'd
>>> have ~20 years of history on any new ones.
>> That is a fair argument. Since we squatted those names back in the
>> mid-90s I think the risk of collision is low.
> Right.  I think there is a fair argument to be made for user confusion
> (not actual conflict) with respect to createuser and dropuser.  The
> argument for renaming any of the other tools is much weaker, IMO.
>
>             regards, tom lane
>
>
I think the consistency of having all PostgreSQL commands start with 
'pg_' would make them both easier to find and to learn.

Although I think we should keep the psql command name, in addition to 
the pg_sql variant - the latter needed for consistency.


Cheers,
Gavin

On 2019-03-27 18:09, Tom Lane wrote:
> My recollection of the discussion is that people argued that "postmaster"
> might be taken to have something to do with an e-mail server, and
> therefore we needed to stop using that name.  The lack of either follow-on
> complaints or follow-on action doesn't make me too well disposed to
> what is essentially that same argument over again.

The reason there was that the distinction was mostly useless and the
different command-line option parsing was confusing.  The name itself
was confusing but not in conflict with anything.

However, we do know that we are very bad at actually getting rid of
deprecated things.

How about we compromise in this thread and remove postmaster and leave
everything else as is. ;-)

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

There would be no need to remove anything if we just renamed the
executable and created symlinks for them.

On Wed, Mar 27, 2019 at 10:20 PM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
>
> On 2019-03-27 18:09, Tom Lane wrote:
> > My recollection of the discussion is that people argued that "postmaster"
> > might be taken to have something to do with an e-mail server, and
> > therefore we needed to stop using that name.  The lack of either follow-on
> > complaints or follow-on action doesn't make me too well disposed to
> > what is essentially that same argument over again.
>
> The reason there was that the distinction was mostly useless and the
> different command-line option parsing was confusing.  The name itself
> was confusing but not in conflict with anything.
>
> However, we do know that we are very bad at actually getting rid of
> deprecated things.
>
> How about we compromise in this thread and remove postmaster and leave
> everything else as is. ;-)
>
> --
> Peter Eisentraut              http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

There would be no need to remove anything if we just renamed the
executable and created symlinks for them.

On Wed, Mar 27, 2019 at 10:20 PM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
>
> On 2019-03-27 18:09, Tom Lane wrote:
> > My recollection of the discussion is that people argued that "postmaster"
> > might be taken to have something to do with an e-mail server, and
> > therefore we needed to stop using that name.  The lack of either follow-on
> > complaints or follow-on action doesn't make me too well disposed to
> > what is essentially that same argument over again.
>
> The reason there was that the distinction was mostly useless and the
> different command-line option parsing was confusing.  The name itself
> was confusing but not in conflict with anything.
>
> However, we do know that we are very bad at actually getting rid of
> deprecated things.
>
> How about we compromise in this thread and remove postmaster and leave
> everything else as is. ;-)
>
> --
> Peter Eisentraut              http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 2019-Mar-28, Abel Abraham Camarillo Ojeda wrote:

> On Thursday, March 28, 2019, Fred .Flintstone <eldmannen@gmail.com> wrote:
> 
> > There would be no need to remove anything if we just renamed the
> > executable and created symlinks for them.
> 
> Will there still be man pages for both commands?
> 
> man pg_createuser
> man createuser

There are provisions in the manpage system to have some pages be
symlinks to other pages.  We don't currently use that anywhere, but I
see no reason why we couldn't just do that.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> There are provisions in the manpage system to have some pages be
> symlinks to other pages.  We don't currently use that anywhere,

Actually we do, eg WITH is a link to SELECT.

            regards, tom lane

So what we could do is:
* Rename executables to be prefixed with pg_. Symlink old names to
renamed executables. This while remaining 100% backwards
compatibility, not breaking anything legacy.
* Print warnings when the executables are executed using the symlink.
* Have the option to have the symlinks in a different optional package.
* At later time in the future be able to chose to remove the symlinks.

On Thu, Mar 28, 2019 at 2:52 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > There are provisions in the manpage system to have some pages be
> > symlinks to other pages.  We don't currently use that anywhere,
>
> Actually we do, eg WITH is a link to SELECT.
>
>                         regards, tom lane

> Andreas Karlsson <andreas@proxel.se> writes:
>> On 3/27/19 3:26 PM, Tomas Vondra wrote:
>>> That is true, of course. But are there actual examples of such conflicts
>>> in practice? I mean, are there tools/packages that provide commands with
>>> a conflicting name? I'm not aware of any, and as was pointed before, we'd
>>> have ~20 years of history on any new ones.
> 
>> That is a fair argument. Since we squatted those names back in the 
>> mid-90s I think the risk of collision is low.
> 
> Right.  I think there is a fair argument to be made for user confusion
> (not actual conflict) with respect to createuser and dropuser.  The
> argument for renaming any of the other tools is much weaker, IMO.

If we were to invent new command names, what about doing similar to
git? I mean something like:

pgsql createdb ....

Here, "pgsql" is new command name and "createdb" is a sub command name
to create a database.

This way, we would be free from the command name conflict problem and
plus, we could do:

pgsql --help

which will prints subscommand names when a user is not sure what is
the sub command name.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

I think that would be amazing! It would be great!

On Fri, Mar 29, 2019 at 4:01 AM Tatsuo Ishii <ishii@sraoss.co.jp> wrote:
>
> > Andreas Karlsson <andreas@proxel.se> writes:
> >> On 3/27/19 3:26 PM, Tomas Vondra wrote:
> >>> That is true, of course. But are there actual examples of such conflicts
> >>> in practice? I mean, are there tools/packages that provide commands with
> >>> a conflicting name? I'm not aware of any, and as was pointed before, we'd
> >>> have ~20 years of history on any new ones.
> >
> >> That is a fair argument. Since we squatted those names back in the
> >> mid-90s I think the risk of collision is low.
> >
> > Right.  I think there is a fair argument to be made for user confusion
> > (not actual conflict) with respect to createuser and dropuser.  The
> > argument for renaming any of the other tools is much weaker, IMO.
>
> If we were to invent new command names, what about doing similar to
> git? I mean something like:
>
> pgsql createdb ....
>
> Here, "pgsql" is new command name and "createdb" is a sub command name
> to create a database.
>
> This way, we would be free from the command name conflict problem and
> plus, we could do:
>
> pgsql --help
>
> which will prints subscommand names when a user is not sure what is
> the sub command name.
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp

Re: Tatsuo Ishii 2019-03-29 <20190329.100407.1159785913847835944.t-ishii@sraoss.co.jp>
> If we were to invent new command names, what about doing similar to
> git? I mean something like:
> 
> pgsql createdb ....

That is pretty close to "psql" and it will be utterly confusing for
new users. And everyone will have a hard time when talking about the
tools, imagine someone saying "please run psql appdbname" or "please
run pgsql createdb". The difference is just too small.

What might possibly make sense is to add options to psql to
facilitate common tasks:

psql --createdb foo
psql --createuser bar --superuser
psql --reindex foo

Christoph

Christoph Berg <myon@debian.org> writes:
> What might possibly make sense is to add options to psql to
> facilitate common tasks:

> psql --createdb foo
> psql --createuser bar --superuser
> psql --reindex foo

That's a thought.  Or perhaps better, allow pg_ctl to grow new
subcommands for those tasks?

            regards, tom lane

On Friday, March 29, 2019 4:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Christoph Berg myon@debian.org writes:
>
> > What might possibly make sense is to add options to psql to
> > facilitate common tasks:
>
> > psql --createdb foo
> > psql --createuser bar --superuser
> > psql --reindex foo
>
> That's a thought. Or perhaps better, allow pg_ctl to grow new
> subcommands for those tasks?

+1 on using pg_ctl rather than psql, should we go down this path.

cheers ./daniel

On 3/29/19 11:44 AM, Daniel Gustafsson wrote:
> On Friday, March 29, 2019 4:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
>> Christoph Berg myon@debian.org writes:
>>
>> > What might possibly make sense is to add options to psql to
>> > facilitate common tasks:
>>
>> > psql --createdb foo
>> > psql --createuser bar --superuser
>> > psql --reindex foo
>>
>> That's a thought. Or perhaps better, allow pg_ctl to grow new
>> subcommands for those tasks?
> 
> +1 on using pg_ctl rather than psql, should we go down this path.


Agreed -- another +1 here

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development

Hi,

On 2019-03-29 11:41:26 -0400, Tom Lane wrote:
> Or perhaps better, allow pg_ctl to grow new subcommands for those
> tasks?

We'd need to be careful to somehow delineate commands that need access
to the data directory / run locally on the server from the ones that
just needs a client connection.

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:
> On 2019-03-29 11:41:26 -0400, Tom Lane wrote:
>> Or perhaps better, allow pg_ctl to grow new subcommands for those
>> tasks?

> We'd need to be careful to somehow delineate commands that need access
> to the data directory / run locally on the server from the ones that
> just needs a client connection.

Hmm, that's a good point: to put it in terms that make sense to a
packager, it'd no longer be clear whether pg_ctl belongs in the
server package or the client package.

I'm still not thrilled with wedging in these things as options
to psql though: its command line semantics are overly complicated
already, when you consider things like multiple -c and -f options.
I mean, somebody might think it's a feature to be able to do

    psql --createuser alice --createuser bob -c 'some command' -f somefile

but I don't.

Maybe if we want to merge these things into one executable,
it should be a new one.  "pg_util createrole bob" ?

            regards, tom lane

On 2019-Mar-29, Tom Lane wrote:

> Christoph Berg <myon@debian.org> writes:
> > What might possibly make sense is to add options to psql to
> > facilitate common tasks:
> 
> > psql --createdb foo
> > psql --createuser bar --superuser
> > psql --reindex foo
> 
> That's a thought.  Or perhaps better, allow pg_ctl to grow new
> subcommands for those tasks?

+1, as I proposed in 2016:
https://www.postgresql.org/message-id/20160826202911.GA320593@alvherre.pgsql

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Tom Lane 2019-03-29 <19517.1553876700@sss.pgh.pa.us>
> >> Or perhaps better, allow pg_ctl to grow new subcommands for those
> >> tasks?
> 
> > We'd need to be careful to somehow delineate commands that need access
> > to the data directory / run locally on the server from the ones that
> > just needs a client connection.
> 
> Hmm, that's a good point: to put it in terms that make sense to a
> packager, it'd no longer be clear whether pg_ctl belongs in the
> server package or the client package.

True, and putting end-user commands like "create database" into the
same admin tool like "stop", "promote", and "kill" feels both wrong
and dangerous to me. It would also cause people to wonder why "pg_ctl
-h remotehost stop" doesn't work.

> I'm still not thrilled with wedging in these things as options
> to psql though: its command line semantics are overly complicated
> already, when you consider things like multiple -c and -f options.
> I mean, somebody might think it's a feature to be able to do
> 
>     psql --createuser alice --createuser bob -c 'some command' -f somefile
> 
> but I don't.

Ack. (Otoh, just processing all arguments after another might be
well-defined, and not too hard?)

> Maybe if we want to merge these things into one executable,
> it should be a new one.  "pg_util createrole bob" ?

"pg" is unfortunately already taken :(

Fwiw, let's please keep supporting "createuser". Creating login roles
is more common than non-login ones, and having to type "createrole
--login bob" is cumbersome and will cause endless support requests by
confused users.

Other idea: If we don't want to reinvent a new tool, how about
supporting prepared statements in psql?

  psql -c 'create user %i' --args 'bob w. space'

Christoph

On 3/29/19 3:01 PM, Pavel Stehule wrote:
> But psql has safe escaping via :"xxx" notation. So some like
> 
> psql -c 'create role :"role"' -v role='my role' ...
> 
> But what I know the psql variables are not evaluated for -c query

You can do this:
echo "create role :\"role\"" | psql -v role='my role'
CREATE ROLE

echo "\password :\"role\"" | psql -v role='my role'
Enter new password:
Enter it again:

That said, this is kind of off the topic of this thread.
I like Tom's last suggestion of:

  pg_util <command> <options>

Of course that does not lend itself to symlinking for backward
compatibility, does it? If there is a way I am not familiar with it.

I guess the alternative would be an alias, but can packages install an
alias? Or something else I am not thinking about?

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development

Re: Pavel Stehule 2019-03-29 <CAFj8pRAFpZcDGL5i1wMQiHZ43y5Qd=22=+2vTCFOrak_mrUxjw@mail.gmail.com>
> > Other idea: If we don't want to reinvent a new tool, how about
> > supporting prepared statements in psql?
> >
> >   psql -c 'create user %i' --args 'bob w. space'
> >
> 
> Prepared statements cannot be DDL commands.

"Prepared" in the sense of what format() does. (I should have used %I.)

> But psql has safe escaping via :"xxx" notation. So some like
> 
> psql -c 'create role :"role"' -v role='my role' ...

That's totally horrible to write, get correct, and to read again
later. We need something that people can actually use.

> But what I know the psql variables are not evaluated for -c query

I hate -c. It has so many caveats.

Christoph

On 3/29/19 3:32 PM, Joe Conway wrote:
>   pg_util <command> <options>
> 
> Of course that does not lend itself to symlinking for backward
> compatibility, does it? If there is a way I am not familiar with it.

On Unix-like systems, you can have pg_util look at argv[0] to see
if it was called createuser or what not.

Not sure how translatable that is to other systems.

Regards,
-Chap

Re: Joe Conway 2019-03-29 <48e5efaf-7ea2-ed70-a803-949bbfec8f6b@joeconway.com>
> echo "\password :\"role\"" | psql -v role='my role'
> Enter new password:
> Enter it again:
> 
> That said, this is kind of off the topic of this thread.

It is on-topic because the reason we can't just tell people to replace
  createuser $foo
with
  psql -c "create user $foo"
is because $foo might need escaping.

IMHO if we find an way to do that which is acceptable for sh scripts,
the createuser/... commands could go.

> I like Tom's last suggestion of:
> 
>   pg_util <command> <options>
> 
> Of course that does not lend itself to symlinking for backward
> compatibility, does it? If there is a way I am not familiar with it.

We could symlink createuser -> pg_util. It is pretty common for
commands to act differently based on the name the were invoked as.

> I guess the alternative would be an alias, but can packages install an
> alias? Or something else I am not thinking about?

Aliases won't work for non-interactive shell scripts.

Christoph

On 3/29/19 3:43 PM, Christoph Berg wrote:
> Re: Joe Conway 2019-03-29 <48e5efaf-7ea2-ed70-a803-949bbfec8f6b@joeconway.com>
>> echo "\password :\"role\"" | psql -v role='my role'
>> Enter new password:
>> Enter it again:
>> 
>> That said, this is kind of off the topic of this thread.
> 
> It is on-topic because the reason we can't just tell people to replace
>   createuser $foo
> with
>   psql -c "create user $foo"
> is because $foo might need escaping.
> 
> IMHO if we find an way to do that which is acceptable for sh scripts,
> the createuser/... commands could go.

I think these commands *were* once (at least some of them) shell scripts
and we went to executable C in order to make them work on Windows, IIRC.

>> I like Tom's last suggestion of:
>> 
>>   pg_util <command> <options>
>> 
>> Of course that does not lend itself to symlinking for backward
>> compatibility, does it? If there is a way I am not familiar with it.
> 
> We could symlink createuser -> pg_util. It is pretty common for
> commands to act differently based on the name the were invoked as.

Yeah, I forgot about that. Does that also go for Windows?

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development

Re: Joe Conway 2019-03-29 <f579fde8-8266-f2d6-4ba1-91c6046bc2f6@joeconway.com>
> >> echo "\password :\"role\"" | psql -v role='my role'
> > 
> > It is on-topic because the reason we can't just tell people to replace
> >   createuser $foo
> > with
> >   psql -c "create user $foo"
> > is because $foo might need escaping.
> > 
> > IMHO if we find an way to do that which is acceptable for sh scripts,
> > the createuser/... commands could go.
> 
> I think these commands *were* once (at least some of them) shell scripts
> and we went to executable C in order to make them work on Windows, IIRC.

I meant the interface to these programs. It needs to be something
people can use in sh scripts without wtf'ing. The :\"weirdness\" |
cited above is IMHO not acceptable.

Christoph

On 3/29/19 11:41 AM, Tom Lane wrote:
> Christoph Berg <myon@debian.org> writes:
>> What might possibly make sense is to add options to psql to
>> facilitate common tasks:
>> psql --createdb foo
>> psql --createuser bar --superuser
>> psql --reindex foo
> That's a thought.  Or perhaps better, allow pg_ctl to grow new
> subcommands for those tasks?
>
>             



I think that's a better direction. psql is already pretty cumbersome.


cheers


andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

I think the proposal you put forward is great, and would love to see
it go ahead and get implemented.

On Fri, Mar 29, 2019 at 5:35 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>
> On 2019-Mar-29, Tom Lane wrote:
>
> > Christoph Berg <myon@debian.org> writes:
> > > What might possibly make sense is to add options to psql to
> > > facilitate common tasks:
> >
> > > psql --createdb foo
> > > psql --createuser bar --superuser
> > > psql --reindex foo
> >
> > That's a thought.  Or perhaps better, allow pg_ctl to grow new
> > subcommands for those tasks?
>
> +1, as I proposed in 2016:
> https://www.postgresql.org/message-id/20160826202911.GA320593@alvherre.pgsql
>
> --
> Álvaro Herrera                https://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 2019-03-29 16:41, Tom Lane wrote:
> Or perhaps better, allow pg_ctl to grow new
> subcommands for those tasks?

pg_ctl is a tool to control the server; the commands being complained
about are client-side things.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 2019-03-29 20:32, Joe Conway wrote:
>   pg_util <command> <options>

How is that better than just renaming to pg_$oldname?

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

It looks like this thread is featured on LWN under the article:
Program names and "pollution".
https://lwn.net/
https://lwn.net/Articles/784508/ (Subscription required)

On Sat, Mar 30, 2019 at 12:27 PM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
>
> On 2019-03-29 20:32, Joe Conway wrote:
> >   pg_util <command> <options>
>
> How is that better than just renaming to pg_$oldname?
>
> --
> Peter Eisentraut              http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

It seems we do have a clear path forward on how to accomplish this and
implement this change.

1. Rename executables to carry the pg_ prefix.
2. Create symlinks from the old names to the new names.
3. Modify the executables to read argv[0] and print a warning if the
executable is called from the old name (symlink).

This seems technically feasible and easy.

How can we proceed?

On Tue, Apr 2, 2019 at 11:24 PM Fred .Flintstone <eldmannen@gmail.com> wrote:
>
> It looks like this thread is featured on LWN under the article:
> Program names and "pollution".
> https://lwn.net/
> https://lwn.net/Articles/784508/ (Subscription required)
>
> On Sat, Mar 30, 2019 at 12:27 PM Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
> >
> > On 2019-03-29 20:32, Joe Conway wrote:
> > >   pg_util <command> <options>
> >
> > How is that better than just renaming to pg_$oldname?
> >
> > --
> > Peter Eisentraut              http://www.2ndQuadrant.com/
> > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Fred .Flintstone 2019-04-10 <CAJgfmqVQWFM7F-JogWEo6MWGA8Oa8BtB4dYAo=y7X5q=SBd35A@mail.gmail.com>
> It seems we do have a clear path forward on how to accomplish this and
> implement this change.
> 
> 1. Rename executables to carry the pg_ prefix.
> 2. Create symlinks from the old names to the new names.
> 3. Modify the executables to read argv[0] and print a warning if the
> executable is called from the old name (symlink).
> 
> This seems technically feasible and easy.
> 
> How can we proceed?

You can send a patch.

But I don't think there has been a "clear" agreement that this is a
good idea.

Christoph

> On 2019-03-29 20:32, Joe Conway wrote:
>>   pg_util <command> <options>
> 
> How is that better than just renaming to pg_$oldname?

As I already said in up thread:

> This way, we would be free from the command name conflict problem
> and plus, we could do:
>
> pgsql --help
>
> which will prints subscommand names when a user is not sure what is
> the sub command name.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

Does anyone oppose the proposal?
How can we determine consensus?
Is there any voting process?

Is there any developer who is more versed than me with C than me who
can write this patch?

On Wed, Apr 10, 2019 at 2:52 PM Christoph Berg <myon@debian.org> wrote:
>
> Re: Fred .Flintstone 2019-04-10 <CAJgfmqVQWFM7F-JogWEo6MWGA8Oa8BtB4dYAo=y7X5q=SBd35A@mail.gmail.com>
> > It seems we do have a clear path forward on how to accomplish this and
> > implement this change.
> >
> > 1. Rename executables to carry the pg_ prefix.
> > 2. Create symlinks from the old names to the new names.
> > 3. Modify the executables to read argv[0] and print a warning if the
> > executable is called from the old name (symlink).
> >
> > This seems technically feasible and easy.
> >
> > How can we proceed?
>
> You can send a patch.
>
> But I don't think there has been a "clear" agreement that this is a
> good idea.
>
> Christoph

Re: Fred .Flintstone 2019-04-10 <CAJgfmqXJA6f_JEiBP81yVxgOhCZd-SOYL0pO22nftug1W0b-Bw@mail.gmail.com>
> Does anyone oppose the proposal?

I don't think part #3 has been discussed, and I'd oppose printing
these warnings.

Christoph

The warnings would only be printed if the programs were executed with
the old file names.
This in order to inform people relying on the old names that they are
deprecated and they should move to the new names with the pg_ prefix.

On Wed, Apr 10, 2019 at 3:10 PM Christoph Berg <myon@debian.org> wrote:
>
> Re: Fred .Flintstone 2019-04-10 <CAJgfmqXJA6f_JEiBP81yVxgOhCZd-SOYL0pO22nftug1W0b-Bw@mail.gmail.com>
> > Does anyone oppose the proposal?
>
> I don't think part #3 has been discussed, and I'd oppose printing
> these warnings.
>
> Christoph

On 2019-04-10 15:15, Fred .Flintstone wrote:
> The warnings would only be printed if the programs were executed with
> the old file names.
> This in order to inform people relying on the old names that they are
> deprecated and they should move to the new names with the pg_ prefix.

Yeah, that would be annoying.  Let's not do that.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 2019-04-10 15:01, Tatsuo Ishii wrote:
>> On 2019-03-29 20:32, Joe Conway wrote:
>>>   pg_util <command> <options>
>>
>> How is that better than just renaming to pg_$oldname?
> 
> As I already said in up thread:
> 
>> This way, we would be free from the command name conflict problem

Well, whatever we do -- if anything -- we would certainly need to keep
the old names around for a while somehow.  So this doesn't really make
that issue go away.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Em sex, 29 de mar de 2019 às 13:25, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
>
> Maybe if we want to merge these things into one executable,
> it should be a new one.  "pg_util createrole bob" ?
>
+1 as I proposed in
https://www.postgresql.org/message-id/bdd1adb1-c26d-ad1f-2f15-cc52056065d4%40timbira.com.br


--
   Euler Taveira                                   Timbira -
http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

>>> On 2019-03-29 20:32, Joe Conway wrote:
>>>>   pg_util <command> <options>
>>>
>>> How is that better than just renaming to pg_$oldname?
>> 
>> As I already said in up thread:
>> 
>>> This way, we would be free from the command name conflict problem
> 
> Well, whatever we do -- if anything -- we would certainly need to keep
> the old names around for a while somehow.  So this doesn't really make
> that issue go away.

Another complain was, it's hard to remember the tool names for novice
users. I think this way would solve the problem.

I agree that command name conflicting problem will not be solved by
the idea. However I do not believe there's name conflicting problem in
the first place. So I am happy to keep the old names as they are.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

It would make the old commands more easily discoverable. Just type pg_
and press the tab key for auto-completion.

On Wed, Apr 10, 2019 at 9:46 PM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
>
> On 2019-04-10 15:01, Tatsuo Ishii wrote:
> >> On 2019-03-29 20:32, Joe Conway wrote:
> >>>   pg_util <command> <options>
> >>
> >> How is that better than just renaming to pg_$oldname?
> >
> > As I already said in up thread:
> >
> >> This way, we would be free from the command name conflict problem
>
> Well, whatever we do -- if anything -- we would certainly need to keep
> the old names around for a while somehow.  So this doesn't really make
> that issue go away.
>
> --
> Peter Eisentraut              http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Friday, April 12, 2019 2:25 PM, Fred .Flintstone <eldmannen@gmail.com> wrote:

> It would make the old commands more easily discoverable. Just type pg_
> and press the tab key for auto-completion.

There are many good reasons for the changes proposed in this thread, but I'm
not sure if discoverability is one.  Relying on autocompleting a filename to
figure out existing tooling for database maintenance and DBA type operations
seems like a fragile usecase.

If commandline discoverability is of importance, providing a summary of the
tools in "man postgresql" seems like a better option.

cheers ./daniel

I would disagree.

Discoverability is important, and having a user space that is
intuitive and predictable.
With the discoverability exposed by pg_<tab> then you immediately find
out what is available.

One shouldn't have to delve down into manuals and books. Then forget
what that darn command was next time its needed, just to have to
return to the documentation again.

Preferably a wrapper around the tools could provide a summary for all
the tools, just like git --help.

On Fri, Apr 12, 2019 at 2:56 PM Daniel Gustafsson <daniel@yesql.se> wrote:
>
> On Friday, April 12, 2019 2:25 PM, Fred .Flintstone <eldmannen@gmail.com> wrote:
>
> > It would make the old commands more easily discoverable. Just type pg_
> > and press the tab key for auto-completion.
>
> There are many good reasons for the changes proposed in this thread, but I'm
> not sure if discoverability is one.  Relying on autocompleting a filename to
> figure out existing tooling for database maintenance and DBA type operations
> seems like a fragile usecase.
>
> If commandline discoverability is of importance, providing a summary of the
> tools in "man postgresql" seems like a better option.
>
> cheers ./daniel

On 2019-Apr-12, Daniel Gustafsson wrote:

> There are many good reasons for the changes proposed in this thread, but I'm
> not sure if discoverability is one.  Relying on autocompleting a filename to
> figure out existing tooling for database maintenance and DBA type operations
> seems like a fragile usecase.
> 
> If commandline discoverability is of importance, providing a summary of the
> tools in "man postgresql" seems like a better option.

The first comment in the LWN article:
 "It's broken and obviously a bad idea but we've been doing it for so long we
  shouldn't attempt to fix it"

IMO the future is longer than the past, and has more users, so let's do
it right instead of perpetuating the mistakes.


... unless you think PostgreSQL is going to become irrelevant before
2050.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Friday, April 12, 2019 3:20 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:

> On 2019-Apr-12, Daniel Gustafsson wrote:
>
> > There are many good reasons for the changes proposed in this thread, but I'm
> > not sure if discoverability is one. Relying on autocompleting a filename to
> > figure out existing tooling for database maintenance and DBA type operations
> > seems like a fragile usecase.
> > If commandline discoverability is of importance, providing a summary of the
> > tools in "man postgresql" seems like a better option.
>
> The first comment in the LWN article:
> "It's broken and obviously a bad idea but we've been doing it for so long we
> shouldn't attempt to fix it"
>
> IMO the future is longer than the past, and has more users, so let's do
> it right instead of perpetuating the mistakes.
>
> ... unless you think PostgreSQL is going to become irrelevant before
> 2050.

Not at all, and as I said there are many good reasons for doing this.  I just
don't think "discoverability" is the driver, since I consider that a different
thing from ease of use and avoid confusion with system tools etc (my reading of
that word is "finding something new", not "how did I spell that tool again").

cheers ./daniel

I think of discoverability as as how easy it is to discover and
rediscover things.
Like rediscover commands you forgot the name of. Like "what was the
command to create a database?", just type pg_ and press tab and see
whats there.

The LWN article is now unlocked to all readers, not just paying
subscribers. It have many comments which might bring value to this
discussion.
https://lwn.net/Articles/784508/

On Fri, Apr 12, 2019 at 3:37 PM Daniel Gustafsson <daniel@yesql.se> wrote:
>
> On Friday, April 12, 2019 3:20 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>
> > On 2019-Apr-12, Daniel Gustafsson wrote:
> >
> > > There are many good reasons for the changes proposed in this thread, but I'm
> > > not sure if discoverability is one. Relying on autocompleting a filename to
> > > figure out existing tooling for database maintenance and DBA type operations
> > > seems like a fragile usecase.
> > > If commandline discoverability is of importance, providing a summary of the
> > > tools in "man postgresql" seems like a better option.
> >
> > The first comment in the LWN article:
> > "It's broken and obviously a bad idea but we've been doing it for so long we
> > shouldn't attempt to fix it"
> >
> > IMO the future is longer than the past, and has more users, so let's do
> > it right instead of perpetuating the mistakes.
> >
> > ... unless you think PostgreSQL is going to become irrelevant before
> > 2050.
>
> Not at all, and as I said there are many good reasons for doing this.  I just
> don't think "discoverability" is the driver, since I consider that a different
> thing from ease of use and avoid confusion with system tools etc (my reading of
> that word is "finding something new", not "how did I spell that tool again").
>
> cheers ./daniel

On 4/12/19 5:14 PM, Chris Travers wrote:
> 1. naming things is surprisingly hard.  How sure are we that we can do 
> this right?  Can we come up with a correct name for initdb?  Maybe 
> pg_createcluster?

The Debian packagers already use pg_createcluster for their script which 
wraps initdb, and while pg_initdb is a bit misleading (it creates a 
cluster rather than a database) it is not that bad.

Andreas

So there is no regression potential.

When and who can send the patch to rename the programs to carry the
pg_ prefixes, and create symlinks from the old names?

On Fri, Apr 12, 2019 at 5:19 PM Andreas Karlsson <andreas@proxel.se> wrote:
>
> On 4/12/19 5:14 PM, Chris Travers wrote:
> > 1. naming things is surprisingly hard.  How sure are we that we can do
> > this right?  Can we come up with a correct name for initdb?  Maybe
> > pg_createcluster?
>
> The Debian packagers already use pg_createcluster for their script which
> wraps initdb, and while pg_initdb is a bit misleading (it creates a
> cluster rather than a database) it is not that bad.
>
> Andreas

Please don't top post. It makes it unnecessarily difficult to follow the
discussion. See https://wiki.postgresql.org/wiki/Mailing_Lists

On Fri, Apr 12, 2019 at 08:56:35PM +0200, Fred .Flintstone wrote:
>So there is no regression potential.
>

I fail to understand how you came to this conclusion? Andreas pointed
out Debian already uses pg_createcluster, so there clearly is potential
for conflict and a regression.

>When and who can send the patch to rename the programs to carry the
>pg_ prefixes, and create symlinks from the old names?
>

Well, presumably that would be you, sometime in the future?

TBH I don't quite understand what are we trying to achieve in this
thread. It started with the presumption that PostgreSQL "pollutes" the
filesystem with scripts/binaries - which may or may not be true, but for
the sake of the argument let's assume that it is. How does keeping the
original stuff and adding symblinks improve the situation?

>On Fri, Apr 12, 2019 at 5:19 PM Andreas Karlsson <andreas@proxel.se> wrote:
>>
>> On 4/12/19 5:14 PM, Chris Travers wrote:
>> > 1. naming things is surprisingly hard.  How sure are we that we can do
>> > this right?  Can we come up with a correct name for initdb?  Maybe
>> > pg_createcluster?
>>
>> The Debian packagers already use pg_createcluster for their script which
>> wraps initdb, and while pg_initdb is a bit misleading (it creates a
>> cluster rather than a database) it is not that bad.
>>
>> Andreas

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services 

On Sat, Apr 13, 2019 at 3:36 PM Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> On Fri, Apr 12, 2019 at 08:56:35PM +0200, Fred .Flintstone wrote:
> >So there is no regression potential.
> >
>
> I fail to understand how you came to this conclusion? Andreas pointed
> out Debian already uses pg_createcluster, so there clearly is potential
> for conflict and a regression.
But there is no "createcluster" in PostgreSQL so that is not a problem.
I don't know if there is any other third-party programs that carry the
pg_ prefix though.

> >When and who can send the patch to rename the programs to carry the
> >pg_ prefixes, and create symlinks from the old names?
> >
>
> Well, presumably that would be you, sometime in the future?
It would be better if someone with more experienced than me did it.

> TBH I don't quite understand what are we trying to achieve in this
> thread. It started with the presumption that PostgreSQL "pollutes" the
> filesystem with scripts/binaries - which may or may not be true, but for
> the sake of the argument let's assume that it is. How does keeping the
> original stuff and adding symblinks improve the situation?
It would ease in discoverability and make the user space more coherent
and predictable which would make it easier to use.
It would also allow to move the symlinks into an optional package or
remove them in the future.

    Andreas Karlsson wrote:

> The Debian packagers already use pg_createcluster for their script which
> wraps initdb, and while pg_initdb is a bit misleading (it creates a
> cluster rather than a database) it is not that bad.

But that renaming wouldn't achieve anything in relation to the stated goal,
since initdb is not in the $PATH in Debian/Ubuntu systems.
It's part of the version-specific binaries located in
/usr/lib/postgresql/$VERSION/bin, which are not meant to be called
directly, but by the pg_*cluster* scripts that you mention, or pg_wrapper.

Moreover, aside from package-specific issues, initdb can already be
invoked through "pg_ctl initdb" since 2010 and version 9.0, as
mentioned in:
 https://www.postgresql.org/docs/9.0/app-initdb.html

This evolution was the result of discussions pretty much like
the present thread.
9 years later, who bothers to use or recommend the new form?
AFAICS nobody cares.

Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite