Re: initdb createuser commands

From: Alban Hertroys <haramrae(at)gmail(dot)com>
To: "Christofer C(dot) Bell" <christofer(dot)c(dot)bell(at)gmail(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: initdb createuser commands
Date: 2016-10-31 15:36:09
Message-ID: CAF-3MvNpzmm8ZZWWPKmsZADLKn8LxSr3KPETA3jfgmZJqOp9Kg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 31 October 2016 at 15:50, Christofer C. Bell <christofer(dot)c(dot)bell(at)gmail(dot)com
> wrote:

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

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.

Personally, I sometimes work with Firebird for educational purposes and I
can't make heads or tails of their command-line tools (with the exception
of isql, but only when I remember it was based on Interbase). To me, the pg
tools are much easier to remember, even though their naming isn't always
consistent.

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.

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.

My few cents.
--
If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Alexander Farber 2016-10-31 15:46:14 Re: How to optimize SELECT query with multiple CASE statements?
Previous Message Geoff Winkless 2016-10-31 15:27:37 Re: How to optimize SELECT query with multiple CASE statements?