Thread: initdb createuser commands

Hello,

Perhaps I'm missing something.

However, it seems to me that there are several "generically" named
commands, e.g. initdb, createuesr which come as part of postgresql. In
my mind, these commands are sufficiently generic that they might clash
with other commands. It's also not obvious they are part of
postgresql.

Wouldn't it make more sense to make them subcommand, of, say, a top
level pga (postgres admin) command, a bit like how `mysqladmin` works?

Just wondering as the naming of these commands seems overly generic
and for a new user it's hard to know what commands are available since
there is no common prefix (e.g. pg_<tab>) for these commands.

Thanks
Samuel

On 10/28/2016 4:31 PM, Samuel Williams wrote:
> Just wondering as the naming of these commands seems overly generic
> and for a new user it's hard to know what commands are available since
> there is no common prefix (e.g. pg_<tab>) for these commands.

as these commands have been around for like 20 years, its kinda late to
change them


--
john r pierce, recycling bits in santa cruz

On 10/28/2016 04:31 PM, Samuel Williams wrote:
> Hello,
>
> Perhaps I'm missing something.
>
> However, it seems to me that there are several "generically" named
> commands, e.g. initdb, createuesr which come as part of postgresql. In
> my mind, these commands are sufficiently generic that they might clash
> with other commands. It's also not obvious they are part of
> postgresql.

See here:
https://www.postgresql.org/docs/9.5/static/reference-client.html
https://www.postgresql.org/docs/9.5/static/reference-server.html

>
> Wouldn't it make more sense to make them subcommand, of, say, a top
> level pga (postgres admin) command, a bit like how `mysqladmin` works?
>
> Just wondering as the naming of these commands seems overly generic
> and for a new user it's hard to know what commands are available since
> there is no common prefix (e.g. pg_<tab>) for these commands.

Other then initdb the commands(AFAIK) that do not have pg or postgres in
the name are just wrappers around the SQL commands of the same
name(roughly) eg dropdb = DROP DATABASE.

initdb is now accessible from pg_ctl:

https://www.postgresql.org/docs/9.5/static/app-pg-ctl.html


>
> Thanks
> Samuel
>
>


--
Adrian Klaver
adrian.klaver@aklaver.com

> as these commands have been around for like 20 years, its kinda late to change them

I understand your position.

For new documentation, it should be better to say `pg_ctl init` rather
than `initdb`. I think that would guide users in the right direction
from the start. Even if maintaining the old commands, they could print
out to stderr "This command is deprecated and now wraps `pg_ctl init`.
Please use that command in the future".

> initdb is now accessible from pg_ctl:

Thanks Adrian, that's really helpful and exactly what I was looking for.

Should we update the Arch Linux documentation to prefer these
commands? What is the recommendation here?

On 29 October 2016 at 12:39, John R Pierce <pierce@hogranch.com> wrote:
> On 10/28/2016 4:31 PM, Samuel Williams wrote:
>>
>> Just wondering as the naming of these commands seems overly generic
>> and for a new user it's hard to know what commands are available since
>> there is no common prefix (e.g. pg_<tab>) for these commands.
>
>
> as these commands have been around for like 20 years, its kinda late to
> change them
>
>
> --
> john r pierce, recycling bits in santa cruz
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

On 10/28/2016 04:55 PM, Samuel Williams wrote:
>> as these commands have been around for like 20 years, its kinda late to change them
>
> I understand your position.
>
> For new documentation, it should be better to say `pg_ctl init` rather
> than `initdb`. I think that would guide users in the right direction
> from the start. Even if maintaining the old commands, they could print
> out to stderr "This command is deprecated and now wraps `pg_ctl init`.
> Please use that command in the future".

It does:

https://www.postgresql.org/docs/9.5/static/creating-cluster.html

>
>> initdb is now accessible from pg_ctl:
>
> Thanks Adrian, that's really helpful and exactly what I was looking for.
>
> Should we update the Arch Linux documentation to prefer these
> commands? What is the recommendation here?

Given that pg_ctl initdb is in all current community supported versions
I would say that is alright. Probably better to just point folks at the
Postgres docs, a great deal of effort is done to keep them current. Also
you have the version selection at the top of each page that allows you
to walk back and forth through time.

>
> On 29 October 2016 at 12:39, John R Pierce <pierce@hogranch.com> wrote:
>> On 10/28/2016 4:31 PM, Samuel Williams wrote:
>>>
>>> Just wondering as the naming of these commands seems overly generic
>>> and for a new user it's hard to know what commands are available since
>>> there is no common prefix (e.g. pg_<tab>) for these commands.
>>
>>
>> as these commands have been around for like 20 years, its kinda late to
>> change them
>>
>>
>> --
>> john r pierce, recycling bits in santa cruz
>>
>>
>>
>> --
>> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general
>
>


--
Adrian Klaver
adrian.klaver@aklaver.com

On 10/28/2016 4:55 PM, Samuel Williams wrote:
> Even if maintaining the old commands, they could print
> out to stderr "This command is deprecated and now wraps `pg_ctl init`.
> Please use that command in the future".

except its the other way around.   pg_ctl initdb invokes initdb, not the
other way around.


--
john r pierce, recycling bits in santa cruz

(For some reason the first time I sent this message it was blocked due
to the keyword "sub-". So, I've changed that and am re-sending.)

I think there is an opportunity here to make the experience for new
users better.

Firstly, I think having one or two top level commands, perhaps pga
[postgres admin], and pg [postgres client], with well documented
subcommands. Ideally `man pg` would tell you all the client commands
and `man pga` would tell you all the server commands. It could even be
implemented in the same way git is implemented with subcommands (e.g.
git foo maps to git-foo internally).

When I see a bare command like `initdb` I wonder where that comes
from, how it relates to postgres and it also concerns me that it
doesn't seem to be obviously part of postgres. The same, when I saw
`createuser` I wondered if that was a postgres command, or an OS level
user creation command, or something else. It's one more thing that I
have to look up.

This is a cognitive load during the time when a new user is already
struggling to come to grips with all the other facets of the system. 7
+/- 2.

It's hard for a new user to know what commands are available because
the naming of commands doesn't follow any consistent structure. I
can't type pg<tab> and see something. In contrast `mysqladmin` has a
really good summary (similar to pg_ctl). Additionally, I'd gently
suggest that underscore in commonly used commands can be a pain for
certain keyboard layouts, even for me I have to use the shift key to
get type the command. `pgctl` would be easier to type.

While this may seem really trivial, to a new user it's not a great
experience out of the box.

I think these things could be really easy to improve (low hanging
fruit) and make the experience a lot better. Given how awesome
postgres is in other areas, it's disappointing that the command line
tools don't reflect the same level of engineering and thoughtfulness.

On 29 October 2016 at 16:36, Samuel Williams
<space.ship.traveller@gmail.com> wrote:
> I think there is an opportunity here to make the experience for new
> users better.
>
> Firstly, I think having one or two top level commands, perhaps pga
> [postgres admin], and pg [postgres client], with well documented
> sub-commands. Ideally `man pg` would tell you all the client commands
> and `man pga` would tell you all the server commands. It could even be
> implemented in the same way git is implemented with sub-commands (e.g.
> git foo maps to git-foo internally).
>
> When I see a bare command like `initdb` I wonder where that comes
> from, how it relates to postgres and it also concerns me that it
> doesn't seem to be obviously part of postgres. The same, when I saw
> `createuser` I wondered if that was a postgres command, or an OS level
> user creation command, or something else. It's one more thing that I
> have to look up.
>
> This is a cognitive load during the time when a new user is already
> struggling to come to grips with all the other facets of the system. 7
> +/- 2.
>
> It's hard for a new user to know what commands are available because
> the naming of commands doesn't follow any consistent structure. I
> can't type pg<tab> and see something. In contrast `mysqladmin` has a
> really good summary (similar to pg_ctl). Additionally, I'd gently
> suggest that underscore in commonly used commands can be a pain for
> certain keyboard layouts, even for me I have to use the shift key to
> get type the command. `pgctl` would be easier to type.
>
> While this may seem really trivial, to a new user it's not a great
> experience out of the box.
>
> I think these things could be really easy to improve (low hanging
> fruit) and make the experience a lot better. Given how awesome
> postgres is in other areas, it's disappointing that the command line
> tools don't reflect the same level of engineering and thoughtfulness.
>
>
>
> On 29 October 2016 at 13:46, John R Pierce <pierce@hogranch.com> wrote:
>> On 10/28/2016 4:55 PM, Samuel Williams wrote:
>>>
>>> Even if maintaining the old commands, they could print
>>> out to stderr "This command is deprecated and now wraps `pg_ctl init`.
>>> Please use that command in the future".
>>
>>
>> except its the other way around.   pg_ctl initdb invokes initdb, not the
>> other way around.
>>
>>
>>
>> --
>> john r pierce, recycling bits in santa cruz
>>
>>
>>
>> --
>> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general

On 10/29/2016 03:31 AM, Samuel Williams wrote:
> (For some reason the first time I sent this message it was blocked due
> to the keyword "sub-". So, I've changed that and am re-sending.)
>
> I think there is an opportunity here to make the experience for new
> users better.
>
> Firstly, I think having one or two top level commands, perhaps pga
> [postgres admin], and pg [postgres client], with well documented
> subcommands. Ideally `man pg` would tell you all the client commands
> and `man pga` would tell you all the server commands. It could even be
> implemented in the same way git is implemented with subcommands (e.g.
> git foo maps to git-foo internally).
>
> When I see a bare command like `initdb` I wonder where that comes
> from, how it relates to postgres and it also concerns me that it
> doesn't seem to be obviously part of postgres. The same, when I saw
> `createuser` I wondered if that was a postgres command, or an OS level
> user creation command, or something else. It's one more thing that I
> have to look up.
>
> This is a cognitive load during the time when a new user is already
> struggling to come to grips with all the other facets of the system. 7
> +/- 2.
>
> It's hard for a new user to know what commands are available because
> the naming of commands doesn't follow any consistent structure. I
> can't type pg<tab> and see something. In contrast `mysqladmin` has a
> really good summary (similar to pg_ctl). Additionally, I'd gently
> suggest that underscore in commonly used commands can be a pain for
> certain keyboard layouts, even for me I have to use the shift key to
> get type the command. `pgctl` would be easier to type.
>
> While this may seem really trivial, to a new user it's not a great
> experience out of the box.
>
> I think these things could be really easy to improve (low hanging
> fruit) and make the experience a lot better. Given how awesome
> postgres is in other areas, it's disappointing that the command line
> tools don't reflect the same level of engineering and thoughtfulness.
>
> On 29 October 2016 at 16:36, Samuel Williams
> <space.ship.traveller@gmail.com> wrote:
>> I think there is an opportunity here to make the experience for new
>> users better.
>>
>> Firstly, I think having one or two top level commands, perhaps pga
>> [postgres admin], and pg [postgres client], with well documented
>> sub-commands. Ideally `man pg` would tell you all the client commands
>> and `man pga` would tell you all the server commands. It could even be
>> implemented in the same way git is implemented with sub-commands (e.g.
>> git foo maps to git-foo internally).
>>
>> When I see a bare command like `initdb` I wonder where that comes
>> from, how it relates to postgres and it also concerns me that it
>> doesn't seem to be obviously part of postgres. The same, when I saw
>> `createuser` I wondered if that was a postgres command, or an OS level
>> user creation command, or something else. It's one more thing that I
>> have to look up.
>>
>> This is a cognitive load during the time when a new user is already
>> struggling to come to grips with all the other facets of the system. 7
>> +/- 2.

These are the commands a new user will need:

pg_ctl
psql
pg_dump
pg_dumpall
pg_restore



>>
>> It's hard for a new user to know what commands are available because
>> the naming of commands doesn't follow any consistent structure. I
>> can't type pg<tab> and see something. In contrast `mysqladmin` has a
>> really good summary (similar to pg_ctl). Additionally, I'd gently
>> suggest that underscore in commonly used commands can be a pain for
>> certain keyboard layouts, even for me I have to use the shift key to
>> get type the command. `pgctl` would be easier to type.
>>
>> While this may seem really trivial, to a new user it's not a great
>> experience out of the box.
>>
>> I think these things could be really easy to improve (low hanging
>> fruit) and make the experience a lot better. Given how awesome
>> postgres is in other areas, it's disappointing that the command line
>> tools don't reflect the same level of engineering and thoughtfulness.
>>
>>
>>
>> On 29 October 2016 at 13:46, John R Pierce <pierce@hogranch.com> wrote:
>>> On 10/28/2016 4:55 PM, Samuel Williams wrote:
>>>>
>>>> Even if maintaining the old commands, they could print
>>>> out to stderr "This command is deprecated and now wraps `pg_ctl init`.
>>>> Please use that command in the future".
>>>
>>>
>>> except its the other way around.   pg_ctl initdb invokes initdb, not the
>>> other way around.
>>>
>>>
>>>
>>> --
>>> john r pierce, recycling bits in santa cruz
>>>
>>>
>>>
>>> --
>>> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>>> To make changes to your subscription:
>>> http://www.postgresql.org/mailpref/pgsql-general
>
>


--
Adrian Klaver
adrian.klaver@aklaver.com

I think there is an opportunity here to make the experience for new
users better.

Firstly, I think having one or two top level commands, perhaps pga
[postgres admin], and pg [postgres client], with well documented
sub-commands. Ideally `man pg` would tell you all the client commands
and `man pga` would tell you all the server commands. It could even be
implemented in the same way git is implemented with sub-commands (e.g.
git foo maps to git-foo internally).

When I see a bare command like `initdb` I wonder where that comes
from, how it relates to postgres and it also concerns me that it
doesn't seem to be obviously part of postgres. The same, when I saw
`createuser` I wondered if that was a postgres command, or an OS level
user creation command, or something else. It's one more thing that I
have to look up.

This is a cognitive load during the time when a new user is already
struggling to come to grips with all the other facets of the system. 7
+/- 2.

It's hard for a new user to know what commands are available because
the naming of commands doesn't follow any consistent structure. I
can't type pg<tab> and see something. In contrast `mysqladmin` has a
really good summary (similar to pg_ctl). Additionally, I'd gently
suggest that underscore in commonly used commands can be a pain for
certain keyboard layouts, even for me I have to use the shift key to
get type the command. `pgctl` would be easier to type.

While this may seem really trivial, to a new user it's not a great
experience out of the box.

I think these things could be really easy to improve (low hanging
fruit) and make the experience a lot better. Given how awesome
postgres is in other areas, it's disappointing that the command line
tools don't reflect the same level of engineering and thoughtfulness.



On 29 October 2016 at 13:46, John R Pierce <pierce@hogranch.com> wrote:
> On 10/28/2016 4:55 PM, Samuel Williams wrote:
>>
>> Even if maintaining the old commands, they could print
>> out to stderr "This command is deprecated and now wraps `pg_ctl init`.
>> Please use that command in the future".
>
>
> except its the other way around.   pg_ctl initdb invokes initdb, not the
> other way around.
>
>
>
> --
> john r pierce, recycling bits in santa cruz
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

FYI, https://wiki.archlinux.org/index.php/PostgreSQL mentions initdb,
createuser, createdb and several others. I think my suggestion is
still relevant and something that would improve the system for new
users :)

On 10/29/2016 03:02 PM, Samuel Williams wrote:
> FYI, https://wiki.archlinux.org/index.php/PostgreSQL mentions initdb,
> createuser, createdb and several others. I think my suggestion is
> still relevant and something that would improve the system for new
> users :)

Seems to me the solution would be to change the above docs to reflect a
simpler procedure. In other words:

[postgres]$ initdb --locale $LANG -E UTF8 -D '/var/lib/postgres/data'

becomes

[postgres]$ pg_ctl initdb -D '/var/lib/postgres/data' -o '--locale $LANG
-E UTF8 '

Remove 'Create your first database/user' and incorporate that into
'Access the database shell' where the database you connect to is
postgres instead of myDatabaseName and you create the user and database
using SQL commands.







--
Adrian Klaver
adrian.klaver@aklaver.com

On 10/29/2016 3:02 PM, Samuel Williams wrote:
> FYI,https://wiki.archlinux.org/index.php/PostgreSQL  mentions initdb,
> createuser, createdb and several others. I think my suggestion is
> still relevant and something that would improve the system for new
> users

and it would break it for the existing community that has up to 20 years
of experience with it, as well as breaking virtually all existing
documentation, books, howto articles, etc, including the one you linked.


--
john r pierce, recycling bits in santa cruz

On 30/10/16 11:25, John R Pierce wrote:
> On 10/29/2016 3:02 PM, Samuel Williams wrote:
>> FYI,https://wiki.archlinux.org/index.php/PostgreSQL mentions initdb,
>> createuser, createdb and several others. I think my suggestion is
>> still relevant and something that would improve the system for new
>> users
>
> and it would break it for the existing community that has up to 20
> years of experience with it, as well as breaking virtually all
> existing documentation, books, howto articles, etc, including the one
> you linked.
>
>
I think it would be good to have all the postgresql utilities prefixed
by pg_ to keep them together, but have aliases so existing scripts &
documentation (especially 3rd party) were still relevant.

However, I wouldn't consider it the highest priority.


Cheers,
Gavin

Adrian, I like the idea of teaching the appropriate SQL to achieve the
same thing. It makes a lot of sense, it's a pity the majority of
documentation doesn't do this.

John, if you read my earlier email you'd see that I proposed including
deprecation notices and aliasing the commands. I appreciate the need
for existing documentation to continue being relevant.

Melvin, I think you are blowing things out of proportion. I didn't
propose to rename the commands entirely such as "createuser" to
"prepareaccount". But, I think having "pg_createuser" or, preferrably,
"pg createuser". It's tidier, respectful of a limited global namespace
of command names, and potentially easier for everyone.

Gavin, I appreciate this is a low priority. But I think it's also
really easy to do by someone who is experienced. Perhaps a day or two
of work? So, it's low priority but also not that difficult and it's an
opportunity to improve the command line experience in a very
fundamental way for new users and experienced users alike.

In my mind, making Postgresql approachable by new users should be a
high priority.

This is really just my 2c, I'd be happy to submit a PR but can you
confirm intention to work on it to acceptance? Otherwise I'm just
wasting everyone's time including my own :)

On 30 October 2016 at 13:31, Gavin Flower <GavinFlower@archidevsys.co.nz> wrote:
> On 30/10/16 11:25, John R Pierce wrote:
>>
>> On 10/29/2016 3:02 PM, Samuel Williams wrote:
>>>
>>> FYI,https://wiki.archlinux.org/index.php/PostgreSQL mentions initdb,
>>> createuser, createdb and several others. I think my suggestion is
>>> still relevant and something that would improve the system for new
>>> users
>>
>>
>> and it would break it for the existing community that has up to 20 years
>> of experience with it, as well as breaking virtually all existing
>> documentation, books, howto articles, etc, including the one you linked.
>>
>>
> I think it would be good to have all the postgresql utilities prefixed by
> pg_ to keep them together, but have aliases so existing scripts &
> documentation (especially 3rd party) were still relevant.
>
> However, I wouldn't consider it the highest priority.
>
>
> Cheers,
> Gavin
>
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

On 10/30/2016 12:15 AM, Samuel Williams wrote:
> But, I think having "pg_createuser" or, preferrably, "pg createuser".

psql -c "create user ...."



--
john r pierce, recycling bits in santa cruz

John - that's an interesting example. If it's that easy, why isn't
that the approach given in tutorials and other documentation? What was
the motivation for the createuser command?

On 30 October 2016 at 20:20, John R Pierce <pierce@hogranch.com> wrote:
> On 10/30/2016 12:15 AM, Samuel Williams wrote:
>>
>> But, I think having "pg_createuser" or, preferrably, "pg createuser".
>
>
> psql -c "create user ...."
>
>
>
> --
> john r pierce, recycling bits in santa cruz
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

On 10/30/2016 02:19 AM, Samuel Williams wrote:
> John - that's an interesting example. If it's that easy, why isn't
> that the approach given in tutorials and other documentation? What was
> the motivation for the createuser command?

psql was less user friendly in the past?

Compare:

https://www.postgresql.org/docs/7.1/static/app-psql.html

to

https://www.postgresql.org/docs/9.5/static/app-psql.html

>
> On 30 October 2016 at 20:20, John R Pierce <pierce@hogranch.com> wrote:
>> On 10/30/2016 12:15 AM, Samuel Williams wrote:
>>>
>>> But, I think having "pg_createuser" or, preferrably, "pg createuser".
>>
>>
>> psql -c "create user ...."
>>
>>
>>
>> --
>> john r pierce, recycling bits in santa cruz
>>
>>
>>
>> --
>> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general
>
>


--
Adrian Klaver
adrian.klaver@aklaver.com

On 10/30/2016 12:15 AM, Samuel Williams wrote:
> Adrian, I like the idea of teaching the appropriate SQL to achieve the
> same thing. It makes a lot of sense, it's a pity the majority of
> documentation doesn't do this.
>
> John, if you read my earlier email you'd see that I proposed including
> deprecation notices and aliasing the commands. I appreciate the need
> for existing documentation to continue being relevant.
>
> Melvin, I think you are blowing things out of proportion. I didn't
> propose to rename the commands entirely such as "createuser" to
> "prepareaccount". But, I think having "pg_createuser" or, preferrably,
> "pg createuser". It's tidier, respectful of a limited global namespace
> of command names, and potentially easier for everyone.
>
> Gavin, I appreciate this is a low priority. But I think it's also
> really easy to do by someone who is experienced. Perhaps a day or two
> of work? So, it's low priority but also not that difficult and it's an
> opportunity to improve the command line experience in a very
> fundamental way for new users and experienced users alike.
>
> In my mind, making Postgresql approachable by new users should be a
> high priority.

A given the number of new users I see showing up and the number of those
using a GUI like pgAdmin I am not seeing the priority.

What it comes down to is adapting to your environment. In my day job I
work in a variety of different disciplines(plumbing, electrical,
equipment control, landscaping and so on) and I run into this context
shift all the time. In a perfect world everyone would agree on a common
way of doing things. This is not a perfect world so I have to adapt when
I move from one field to another and even within a field when dealing
with different people. I used to fight this, and still do when provoked,
but at some time point I realized I generally expended less energy just
learning 'the  way' and getting on with my job. Not to say you do not
have some valid points, but you are pushing against something that has
significant inertia.

>
> This is really just my 2c, I'd be happy to submit a PR but can you
> confirm intention to work on it to acceptance? Otherwise I'm just
> wasting everyone's time including my own :)

I do not see anyone pre-approving a PR that they have not seen.

>
> On 30 October 2016 at 13:31, Gavin Flower <GavinFlower@archidevsys.co.nz> wrote:
>> On 30/10/16 11:25, John R Pierce wrote:
>>>
>>> On 10/29/2016 3:02 PM, Samuel Williams wrote:
>>>>
>>>> FYI,https://wiki.archlinux.org/index.php/PostgreSQL mentions initdb,
>>>> createuser, createdb and several others. I think my suggestion is
>>>> still relevant and something that would improve the system for new
>>>> users
>>>
>>>
>>> and it would break it for the existing community that has up to 20 years
>>> of experience with it, as well as breaking virtually all existing
>>> documentation, books, howto articles, etc, including the one you linked.
>>>
>>>
>> I think it would be good to have all the postgresql utilities prefixed by
>> pg_ to keep them together, but have aliases so existing scripts &
>> documentation (especially 3rd party) were still relevant.
>>
>> However, I wouldn't consider it the highest priority.
>>
>>
>> Cheers,
>> Gavin
>>
>>
>>
>>
>> --
>> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general
>
>


--
Adrian Klaver
adrian.klaver@aklaver.com

> A given the number of new users I see showing up and the number of those using a GUI like pgAdmin I am not seeing the
priority.

Well, maybe the reason for this is that the command line tools are not
well thought out and people reach for alternatives.

> but you are pushing against something that has significant inertia.

I understand where you are coming from. However, I don't think I'm
pushing against it. I'm just providing feedback and ideas. The ideas I
did provide don't really push, but are incremental improvements which
preserve backwards compatibility.

As a community I'd think that having feedback from a new user would be
valuable since as you say, sometimes when you get ingrained into the
"way of doing things" that you don't see how they could be improved or
different.

> I do not see anyone pre-approving a PR that they have not seen.

I'm not suggesting anyone to pre-approve anything. I'm suggesting that
there is no point investing the effort if there is no desire to fix
the problem. If the problem would be acknowledged by a core dev and a
"Let's improve this" attitude were espoused, I'd feel more confident
to invest the time and effort required to improve things.

But so far, I'm getting the opposite.

Kind regards,
Samuel



On 31 October 2016 at 04:30, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
> On 10/30/2016 12:15 AM, Samuel Williams wrote:
>>
>> Adrian, I like the idea of teaching the appropriate SQL to achieve the
>> same thing. It makes a lot of sense, it's a pity the majority of
>> documentation doesn't do this.
>>
>> John, if you read my earlier email you'd see that I proposed including
>> deprecation notices and aliasing the commands. I appreciate the need
>> for existing documentation to continue being relevant.
>>
>> Melvin, I think you are blowing things out of proportion. I didn't
>> propose to rename the commands entirely such as "createuser" to
>> "prepareaccount". But, I think having "pg_createuser" or, preferrably,
>> "pg createuser". It's tidier, respectful of a limited global namespace
>> of command names, and potentially easier for everyone.
>>
>> Gavin, I appreciate this is a low priority. But I think it's also
>> really easy to do by someone who is experienced. Perhaps a day or two
>> of work? So, it's low priority but also not that difficult and it's an
>> opportunity to improve the command line experience in a very
>> fundamental way for new users and experienced users alike.
>>
>> In my mind, making Postgresql approachable by new users should be a
>> high priority.
>
>
> A given the number of new users I see showing up and the number of those
> using a GUI like pgAdmin I am not seeing the priority.
>
> What it comes down to is adapting to your environment. In my day job I work
> in a variety of different disciplines(plumbing, electrical, equipment
> control, landscaping and so on) and I run into this context shift all the
> time. In a perfect world everyone would agree on a common way of doing
> things. This is not a perfect world so I have to adapt when I move from one
> field to another and even within a field when dealing with different people.
> I used to fight this, and still do when provoked, but at some time point I
> realized I generally expended less energy just learning 'the  way' and
> getting on with my job. Not to say you do not have some valid points, but
> you are pushing against something that has significant inertia.
>
>>
>> This is really just my 2c, I'd be happy to submit a PR but can you
>> confirm intention to work on it to acceptance? Otherwise I'm just
>> wasting everyone's time including my own :)
>
>
> I do not see anyone pre-approving a PR that they have not seen.
>
>
>>
>> On 30 October 2016 at 13:31, Gavin Flower <GavinFlower@archidevsys.co.nz>
>> wrote:
>>>
>>> On 30/10/16 11:25, John R Pierce wrote:
>>>>
>>>>
>>>> On 10/29/2016 3:02 PM, Samuel Williams wrote:
>>>>>
>>>>>
>>>>> FYI,https://wiki.archlinux.org/index.php/PostgreSQL mentions initdb,
>>>>> createuser, createdb and several others. I think my suggestion is
>>>>> still relevant and something that would improve the system for new
>>>>> users
>>>>
>>>>
>>>>
>>>> and it would break it for the existing community that has up to 20 years
>>>> of experience with it, as well as breaking virtually all existing
>>>> documentation, books, howto articles, etc, including the one you linked.
>>>>
>>>>
>>> I think it would be good to have all the postgresql utilities prefixed by
>>> pg_ to keep them together, but have aliases so existing scripts &
>>> documentation (especially 3rd party) were still relevant.
>>>
>>> However, I wouldn't consider it the highest priority.
>>>
>>>
>>> Cheers,
>>> Gavin
>>>
>>>
>>>
>>>
>>> --
>>> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>>> To make changes to your subscription:
>>> http://www.postgresql.org/mailpref/pgsql-general
>>
>>
>>
>
>
> --
> Adrian Klaver
> adrian.klaver@aklaver.com

On 10/30/2016 03:42 PM, Samuel Williams wrote:
>> A given the number of new users I see showing up and the number of those using a GUI like pgAdmin I am not seeing
thepriority. 
>
> Well, maybe the reason for this is that the command line tools are not
> well thought out and people reach for alternatives.
>
>> but you are pushing against something that has significant inertia.
>
> I understand where you are coming from. However, I don't think I'm
> pushing against it. I'm just providing feedback and ideas. The ideas I
> did provide don't really push, but are incremental improvements which
> preserve backwards compatibility.
>
> As a community I'd think that having feedback from a new user would be
> valuable since as you say, sometimes when you get ingrained into the
> "way of doing things" that you don't see how they could be improved or
> different.
>
>> I do not see anyone pre-approving a PR that they have not seen.
>
> I'm not suggesting anyone to pre-approve anything. I'm suggesting that
> there is no point investing the effort if there is no desire to fix
> the problem. If the problem would be acknowledged by a core dev and a
> "Let's improve this" attitude were espoused, I'd feel more confident
> to invest the time and effort required to improve things.

I would suggest bringing this up on --hackers then:

https://www.postgresql.org/list/pgsql-hackers/

You will probably get a better sense of what is considered possible there.

>
> But so far, I'm getting the opposite.
>
> Kind regards,
> Samuel
>



--
Adrian Klaver
adrian.klaver@aklaver.com

Mike, I agree with "the postgres way of doing things". I'm suggesting that

>  these commands are sufficiently generic that they might clash
with other commands.

> It's also not obvious they are part of postgresql.

> Wouldn't it make more sense to make them subcommand, of, say, a top
level pga (postgres admin) command, a bit like how `mysqladmin` works

and finally

> the naming of these commands seems overly generic
and for a new user it's hard to know what commands are available since
there is no common prefix (e.g. pg_<tab>) for these commands

Just because things are working how they currently are doesn't mean
they can't be improved.

> If someone isn’t skilled in sql, the requests you’ve made won’t assist them at all.

This isn't just about someone who is or isn't skilled. I work with
MySQL, CouchDB, Redis, and various other technologies. Out of those
three, I'd say that Postgres has the worst and most inconsistently
named command line tools. It's a large overhead for day to day
operation to deal with inconsistency at any level.

It's not a particularly hard problem to fix and thus I think it's
worthy of some attention.

On 31 October 2016 at 12:51, Mike Sofen <msofen@runbox.com> wrote:
> From: Samuel Williams  Sent: Sunday, October 30, 2016 3:42 PM
> As a community I'd think that having feedback from a new user would be
> valuable since as you say, sometimes when you get ingrained into the "way of
> doing things" that you don't see how they could be improved or different.
>
> Samuel
>
>                ------------------------
>
> I’d take a different tack.  I spent 20 years with SQL Server and easily
> (almost gleefully) hopped over to Postgres and especially pgplsql and
> PgAdmin III, from using SqlServer Management Studio (SSMS – their
> admin/coding app).
>
>
>
> Sure, I had to learn the PG way of doing things, but really, it was a
> no-brainer.  I had to spend a few extra cycles learning the PG best
> practices and particular way of doing things but it was trivial…google and
> done.  The vast community has created massive amounts of examples for nearly
> everything imaginable – and some things I would never have imagined anyone
> would try to do – such that I don’t have to Lewis and Clark it but just dive
> right in and write code.
>
>
>
> IMO, nothing major needs changing in the language or command syntax – it’s
> logical and easy for anyone skilled in sql.  If someone isn’t skilled in
> sql, the requests you’ve made won’t assist them at all.
>
>
>
> Mike Sofen (Synthetic Genomics)

Sorry, just to clarify, b "worst" I don't mean functionality, I mean
the way the commands are named and organised.

On 31 October 2016 at 13:07, Samuel Williams
<space.ship.traveller@gmail.com> wrote:
> Mike, I agree with "the postgres way of doing things". I'm suggesting that
>
>>  these commands are sufficiently generic that they might clash
> with other commands.
>
>> It's also not obvious they are part of postgresql.
>
>> Wouldn't it make more sense to make them subcommand, of, say, a top
> level pga (postgres admin) command, a bit like how `mysqladmin` works
>
> and finally
>
>> the naming of these commands seems overly generic
> and for a new user it's hard to know what commands are available since
> there is no common prefix (e.g. pg_<tab>) for these commands
>
> Just because things are working how they currently are doesn't mean
> they can't be improved.
>
>> If someone isn’t skilled in sql, the requests you’ve made won’t assist them at all.
>
> This isn't just about someone who is or isn't skilled. I work with
> MySQL, CouchDB, Redis, and various other technologies. Out of those
> three, I'd say that Postgres has the worst and most inconsistently
> named command line tools. It's a large overhead for day to day
> operation to deal with inconsistency at any level.
>
> It's not a particularly hard problem to fix and thus I think it's
> worthy of some attention.
>
> On 31 October 2016 at 12:51, Mike Sofen <msofen@runbox.com> wrote:
>> From: Samuel Williams  Sent: Sunday, October 30, 2016 3:42 PM
>> As a community I'd think that having feedback from a new user would be
>> valuable since as you say, sometimes when you get ingrained into the "way of
>> doing things" that you don't see how they could be improved or different.
>>
>> Samuel
>>
>>                ------------------------
>>
>> I’d take a different tack.  I spent 20 years with SQL Server and easily
>> (almost gleefully) hopped over to Postgres and especially pgplsql and
>> PgAdmin III, from using SqlServer Management Studio (SSMS – their
>> admin/coding app).
>>
>>
>>
>> Sure, I had to learn the PG way of doing things, but really, it was a
>> no-brainer.  I had to spend a few extra cycles learning the PG best
>> practices and particular way of doing things but it was trivial…google and
>> done.  The vast community has created massive amounts of examples for nearly
>> everything imaginable – and some things I would never have imagined anyone
>> would try to do – such that I don’t have to Lewis and Clark it but just dive
>> right in and write code.
>>
>>
>>
>> IMO, nothing major needs changing in the language or command syntax – it’s
>> logical and easy for anyone skilled in sql.  If someone isn’t skilled in
>> sql, the requests you’ve made won’t assist them at all.
>>
>>
>>
>> Mike Sofen (Synthetic Genomics)

    Samuel Williams wrote:

> John - that's an interesting example. If it's that easy, why isn't
> that the approach given in tutorials and other documentation? What was
> the motivation for the createuser command?

initdb, createdb and createuser existed even before Postgres
adopted SQL, back when it was developed by the University of
Berkeley.

You can find references to these commands in the doc here:
http://db.cs.berkeley.edu/postgres-v4r2/postgres-setup.ps
which dates back from 1994.
(fun fact: there was no psql yet, the equivalent command was called
"monitor". How about that for a name that has seemingly nothing
to do with postgres? :)

According to these old instructions, commands are installed
by default into /usr/local/postgres/bin,
so that was their namespace. They were not supposed to be mixed
with other non-postgres commands.

That's still the case today if you run ./configure and
"make install" from the current postgresql sources:
these commands end up in /usr/local/pgsql/bin
Some installers such as the EDB installers for Windows or Unix
typically use a dedicated directory for PostgreSQL, so again its
commands don't get mixed with other stuff.

As for the Postgresql pre-compiled packages that come with Linux
distributions, they need to respect the policy of their distros,
meaning that all user-callable commands should be in the default $PATH.
That implies that, for instance, postgresql's "createuser" ends up
in $PATH along with the system's "adduser", even though they have
hardly anything to do with each other, so yes, that's somehow
unfortunate.
But these decisions are made by packagers and distributions, not
by the PostgreSQL developers.

Some of these commands are already documented as deprecated,
for example "createlang", which I find in Ubuntu 14.04 /usr/bin:
$ man createlang
      [...]
      Caution
       createlang is deprecated and may be removed in a future PostgreSQL
       release. Direct use of the CREATE EXTENSION command is recommended
       instead.

The same could theorically be done to createuser/dropuser or
createdb/dropdb, but there's the question of whether this would create
more harm that good, because they're much widely used in
existing scripts and tutorials.

Note that in any case your proposal to use "pg" as an
umbrella-command wouldn't fly with these systems because pg is a
pager from the Debian's util-linux package.

$ which pg
/usr/bin/pg

$ man pg
PG(1)                 User Commands
PG(1)

NAME
       pg - browse pagewise through text files

SYNOPSIS
       pg [-number] [-p string] [-cefnrs] [+line] [+/pattern/] [file...]
...

Also, the same Debian/Ubuntu systems don't have initdb or pg_ctl
in the default $PATH, as these commands are superseded
by different distro-specific pg_* commands . This is also
something that should be considered if thinking of unifying
the binaries.


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

Daniel, your reply is awesome :) I love the historical context and it
brings much clarity to the discussion!

It's now understandable why the commands were named the way they were.

I'm surprised that distros are making their own commands for
postgres.. isn't that a bit invasive?



On 1 November 2016 at 06:50, Daniel Verite <daniel@manitou-mail.org> wrote:
>         Samuel Williams wrote:
>
>> John - that's an interesting example. If it's that easy, why isn't
>> that the approach given in tutorials and other documentation? What was
>> the motivation for the createuser command?
>
> initdb, createdb and createuser existed even before Postgres
> adopted SQL, back when it was developed by the University of
> Berkeley.
>
> You can find references to these commands in the doc here:
> http://db.cs.berkeley.edu/postgres-v4r2/postgres-setup.ps
> which dates back from 1994.
> (fun fact: there was no psql yet, the equivalent command was called
> "monitor". How about that for a name that has seemingly nothing
> to do with postgres? :)
>
> According to these old instructions, commands are installed
> by default into /usr/local/postgres/bin,
> so that was their namespace. They were not supposed to be mixed
> with other non-postgres commands.
>
> That's still the case today if you run ./configure and
> "make install" from the current postgresql sources:
> these commands end up in /usr/local/pgsql/bin
> Some installers such as the EDB installers for Windows or Unix
> typically use a dedicated directory for PostgreSQL, so again its
> commands don't get mixed with other stuff.
>
> As for the Postgresql pre-compiled packages that come with Linux
> distributions, they need to respect the policy of their distros,
> meaning that all user-callable commands should be in the default $PATH.
> That implies that, for instance, postgresql's "createuser" ends up
> in $PATH along with the system's "adduser", even though they have
> hardly anything to do with each other, so yes, that's somehow
> unfortunate.
> But these decisions are made by packagers and distributions, not
> by the PostgreSQL developers.
>
> Some of these commands are already documented as deprecated,
> for example "createlang", which I find in Ubuntu 14.04 /usr/bin:
> $ man createlang
>           [...]
>           Caution
>            createlang is deprecated and may be removed in a future PostgreSQL
>            release. Direct use of the CREATE EXTENSION command is recommended
>            instead.
>
> The same could theorically be done to createuser/dropuser or
> createdb/dropdb, but there's the question of whether this would create
> more harm that good, because they're much widely used in
> existing scripts and tutorials.
>
> Note that in any case your proposal to use "pg" as an
> umbrella-command wouldn't fly with these systems because pg is a
> pager from the Debian's util-linux package.
>
> $ which pg
> /usr/bin/pg
>
> $ man pg
> PG(1)                            User Commands
> PG(1)
>
> NAME
>        pg - browse pagewise through text files
>
> SYNOPSIS
>        pg [-number] [-p string] [-cefnrs] [+line] [+/pattern/] [file...]
> ...
>
> Also, the same Debian/Ubuntu systems don't have initdb or pg_ctl
> in the default $PATH, as these commands are superseded
> by different distro-specific pg_* commands . This is also
> something that should be considered if thinking of unifying
> the binaries.
>
>
> Best regards,
> --
> Daniel Vérité
> PostgreSQL-powered mailer: http://www.manitou-mail.org
> Twitter: @DanielVerite

On 10/31/2016 05:15 PM, Samuel Williams wrote:
> Daniel, your reply is awesome :) I love the historical context and it
> brings much clarity to the discussion!
>
> It's now understandable why the commands were named the way they were.
>
> I'm surprised that distros are making their own commands for
> postgres.. isn't that a bit invasive?

No, actually it is quite handy:

https://wiki.debian.org/PostgreSql

It allows you to handle multiple instances  of Postgres easily:

aklaver@arkansas:~$ lsb_release -a
                                     
No LSB modules are available.
                                     
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.5 LTS
Release:        14.04
Codename:       trusty


aklaver@arkansas:~$ pg_lsclusters

Ver Cluster Port Status Owner    Data directory               Log file
9.3 main    5432 down   postgres /var/lib/postgresql/9.3/main /var/log/postgresql/postgresql-9.3-main.log
9.4 main    5434 online postgres /var/lib/postgresql/9.4/main /var/log/postgresql/postgresql-9.4-main.log

aklaver@arkansas:~$ sudo pg_ctlcluster 9.3 main start

aklaver@arkansas:~$ pg_lsclusters

Ver Cluster Port Status Owner    Data directory               Log file
9.3 main    5432 online postgres /var/lib/postgresql/9.3/main /var/log/postgresql/postgresql-9.3-main.log
9.4 main    5434 online postgres /var/lib/postgresql/9.4/main /var/log/postgresql/postgresql-9.4-main.log




>
>
>
> On 1 November 2016 at 06:50, Daniel Verite <daniel@manitou-mail.org> wrote:
>>         Samuel Williams wrote:
>>
>>> John - that's an interesting example. If it's that easy, why isn't
>>> that the approach given in tutorials and other documentation? What was
>>> the motivation for the createuser command?
>>
>> initdb, createdb and createuser existed even before Postgres
>> adopted SQL, back when it was developed by the University of
>> Berkeley.
>>
>> You can find references to these commands in the doc here:
>> http://db.cs.berkeley.edu/postgres-v4r2/postgres-setup.ps
>> which dates back from 1994.
>> (fun fact: there was no psql yet, the equivalent command was called
>> "monitor". How about that for a name that has seemingly nothing
>> to do with postgres? :)
>>
>> According to these old instructions, commands are installed
>> by default into /usr/local/postgres/bin,
>> so that was their namespace. They were not supposed to be mixed
>> with other non-postgres commands.
>>
>> That's still the case today if you run ./configure and
>> "make install" from the current postgresql sources:
>> these commands end up in /usr/local/pgsql/bin
>> Some installers such as the EDB installers for Windows or Unix
>> typically use a dedicated directory for PostgreSQL, so again its
>> commands don't get mixed with other stuff.
>>
>> As for the Postgresql pre-compiled packages that come with Linux
>> distributions, they need to respect the policy of their distros,
>> meaning that all user-callable commands should be in the default $PATH.
>> That implies that, for instance, postgresql's "createuser" ends up
>> in $PATH along with the system's "adduser", even though they have
>> hardly anything to do with each other, so yes, that's somehow
>> unfortunate.
>> But these decisions are made by packagers and distributions, not
>> by the PostgreSQL developers.
>>
>> Some of these commands are already documented as deprecated,
>> for example "createlang", which I find in Ubuntu 14.04 /usr/bin:
>> $ man createlang
>>           [...]
>>           Caution
>>            createlang is deprecated and may be removed in a future PostgreSQL
>>            release. Direct use of the CREATE EXTENSION command is recommended
>>            instead.
>>
>> The same could theorically be done to createuser/dropuser or
>> createdb/dropdb, but there's the question of whether this would create
>> more harm that good, because they're much widely used in
>> existing scripts and tutorials.
>>
>> Note that in any case your proposal to use "pg" as an
>> umbrella-command wouldn't fly with these systems because pg is a
>> pager from the Debian's util-linux package.
>>
>> $ which pg
>> /usr/bin/pg
>>
>> $ man pg
>> PG(1)                            User Commands
>> PG(1)
>>
>> NAME
>>        pg - browse pagewise through text files
>>
>> SYNOPSIS
>>        pg [-number] [-p string] [-cefnrs] [+line] [+/pattern/] [file...]
>> ...
>>
>> Also, the same Debian/Ubuntu systems don't have initdb or pg_ctl
>> in the default $PATH, as these commands are superseded
>> by different distro-specific pg_* commands . This is also
>> something that should be considered if thinking of unifying
>> the binaries.
>>
>>
>> Best regards,
>> --
>> Daniel Vérité
>> PostgreSQL-powered mailer: http://www.manitou-mail.org
>> Twitter: @DanielVerite
>
>


--
Adrian Klaver
adrian.klaver@aklaver.com

On 10/31/16 9:50 AM, Christofer C. Bell wrote:
> He's getting a lot of pushback that really feels it's coming from the
> wrong direction.  "Just learn it."  "It's always been this way."  "No
> one agrees with you."  These arguments are unconvincing.  That said,
> there's nothing wrong with just saying, "we're not going to change it
> because we don't want to."

The community often does a horrible job of viewing things through the
eyes of a new user. This is why mysql became so popular for a while.
Comments like "just learn it" are unproductive and push new users away.

And we wonder why we're having trouble attracting new developers...

This has actually been discussed recently on -hackers as well[1], and
there is some general consensus that simplification in this area would
be a good idea.

1:
https://www.postgresql.org/message-id/20160826202911.GA320593@alvherre.pgsql
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461

> Really? So naming them pg_initdb and pg_createdb would help to clarify their use?

Yes.

> Perhaps you missed: https://www.postgresql.org/docs/9.6/static/app-pg-ctl.html

I meant a man page that details the ENTIRE Postgres command line tools.

> Command line aliases and other stuff

I've been using Linux since kernels were 1.x - come on, I know what an
alias is. You've missed the forest for the trees.

> I think the OP's point is that having a hodgepodge of (on their face) unrelated commands smells kinda unorganized at
bestand unprofessional at worst.  Wether or not he's right is up to the reader.  For me, I agree with his sentiment. 

Yes exactly.

> The solution he's suggesting is to bring all of these commands under one umbrella either by bundling them in an
administrativeutility or by giving them a prefix that shows they're related to "the PostgreSQL database." 

Correct.

> He's getting a lot of pushback that really feels it's coming from the wrong direction.  "Just learn it."  "It's
alwaysbeen this way."  "No one agrees with you."  These arguments are unconvincing.  That said, there's nothing wrong
withjust saying, "we're not going to change it because we don't want to." 

I'm okay with any of those options. But I just wanted to raise this
from the POV of a new user. However, I'm not a "beginner" as such.

> There is the issue that by introducing new commands that are better organised, the new user will get introduced to
morecommands instead of fewer - when they run into a problem or if they bought the book, the commands they'll encounter
willbe the "old" commands. 

Can be solved with time and backwards aliases/deprecated commands
which are maintained for a few more releases.

> There's also the learning curve of having a single wrapper-command that can do anything pg-related. The purpose of a
commandnamed pg_createuser is obvious, the purpose of a command named pg or pga is not so obvious. 

I agree this is a valid POV. But I think the opposite is also true. I
have command line tools that when run with no arguments give a very
nice succinct description of the tool and sub-commands.

> I do think however that having the pg-commands prefixed with pg_ is actually helpful to both new and experienced
users.One reason is that it limits the number of commands matched for command completion after typeing pg_ (which is
only3 characters to type). ISTR some argument against using underscores because they would be hard to type, but I can't
understandwhy. 

TAB completion is a really good point and a big one. It helps you
discover related commands. It's good for all users. W.r.t. underscores
- to type _ one must press shift... I have to stretch my pinky :D It's
uncomfortable and a bit slower than just.. say, any other letter or a
dash.

> That said, renaming the commands provides a rather minor benefit at best. Having this much fuss about it is out of
proportionIMHO. I remember learning those commands (when pg 7.4.7 was a big deal) and it certainly did not cost me the
majorityof time that I needed to learn to use pg, and once I did learn them I knew where to find at least the
documentation.

I'm not the one really fussing, I'm just answering people's objections
where I think they are incorrect or misunderstanding my original
statements. I think that's polite to do so - I made an investment of
time to bring attention to what I feel is an issue and I'm prepared to
invest the time to see it through.

I think that the benefit is probably more than minor, if the command
line interface is crappy people will struggle with the tool as you've
mentioned. But if it's good, people will love it. What kind of feeling
do you want to invoke in users of Postgresql?

> It allows you to handle multiple instances  of Postgres easily

This is awesome, but I feel like it would be better if this was
bundled as part of Postgres so it would work on all platforms
consistently, not just Debian. The fact they are doing it shows that
there is a need for it.

> In this list, the convention is to post replies at the end (with some rare exceptions),
or interspersed when appropriate, and to omit parts no longer relevant.

My apologies, Gmail is a heap of crap and hides everything by default. Bleh :)

> The community often does a horrible job of viewing things through the eyes of a new user. This is why mysql became so
popularfor a while. Comments like "just learn it" are unproductive and push new users away. 

I'd agree with this and I agree that this is the feeling I'm getting
from the replies here.

Thanks everyone for your thoughtful replies.