Search Postgresql Archives

Re: initdb createuser commands

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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 best and 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 administrative utility 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 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."

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 more commands instead of fewer - when they run into a problem or if they bought the book, the commands they'll encounter will be 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 command named 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 only 3 characters to type). ISTR some argument against using underscores because they would be hard to type, but I can't understand why.

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 proportion IMHO. I remember learning those commands (when pg 7.4.7 was a big deal) and it certainly did not cost me the majority of 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 popular for 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.


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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux