Re: initdb createuser commands

[Melvin Davidson <melvin6925@xxxxxxxxx>]

On Mon, Oct 31, 2016 at 10:50 AM, Christofer C. Bell <christofer.c.bell@xxxxxxxxx> wrote:

On Sun, Oct 30, 2016 at 11:10 PM, Melvin Davidson <melvin6925@xxxxxxxxx> wrote:

On Sun, Oct 30, 2016 at 8:08 PM, Samuel Williams <space.ship.traveller@xxxxxxxxm> wrote:

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@xxxxxxxxm> 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@xxxxxxxxxx> 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)


--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Samuel,

I believe you are over simplifying things. Simply renaming a command does not make it easier to learn or clarify it's use.

That is the purpose of documentation. A beginner does not get a better understanding of command usage by the name of a command,

they get it by actually using the command. In addition, I don't know any DBA that is in favor of longer  command names (as you

propose prefixing with pg_ ). The fact is, the commands are already self explanatory. The _only_ way to learn how to be a good DBA

is to actually use the commands, and that also includes pg_ctl and psql commands. I agree that GUI tools make it easier to learn,

but is essential to learn the command line tools and how to use. So again, it is not the name that is important, but the actual usage.

--

Melvin Davidson
I reserve the right to fantasize.  Whether or not you
wish to share my fantasy is entirely up to you.

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

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

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

--

Chris

"If you wish to make an apple pie from scratch, you must first invent the Universe." -- Carl Sagan

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

As I have already pointed out, they are already documented well:
https://www.postgresql.org/docs/9.6/static/reference-client.html

>giving them a prefix that shows they're related to "the PostgreSQL database." 
I would think that the fact they are bundled in /usr/lib/postgresql/<version>/bin/
would be a big hint. Likewise in windows <C>:\<postgresql>\bin\.

>He's getting a lot of pushback that really feels it's coming from the wrong direction....
>That said, there's nothing wrong with just saying, "we're not going to change it because we don't want to."
No, what I am saying is "There is no need to change it".  It's working, it's documented, it is an existing standard.

--

Melvin Davidson
I reserve the right to fantasize.  Whether or not you
wish to share my fantasy is entirely up to you.