Re: initdb createuser commands

On Mon, Oct 31, 2016 at 10:50 AM, Christofer C. Bell <
christofer(dot)c(dot)bell(at)gmail(dot)com> wrote:

> On Sun, Oct 30, 2016 at 11:10 PM, Melvin Davidson <melvin6925(at)gmail(dot)com>
> wrote:
>
>>
>>
>>
>>
>> On Sun, Oct 30, 2016 at 8:08 PM, Samuel Williams <
>> space(dot)ship(dot)traveller(at)gmail(dot)com> 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(dot)ship(dot)traveller(at)gmail(dot)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(at)runbox(dot)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)
>>>
>>>
>>> --
>>> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
>>> 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
<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.