Re: [GENERAL] initdb createuser commands
> 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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb createuser commands
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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb createuser commands
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 OwnerData directory Log file 9.3 main5432 down postgres /var/lib/postgresql/9.3/main /var/log/postgresql/postgresql-9.3-main.log 9.4 main5434 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 OwnerData directory Log file 9.3 main5432 online postgres /var/lib/postgresql/9.3/main /var/log/postgresql/postgresql-9.3-main.log 9.4 main5434 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 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.kla...@aklaver.com -- Sent via pgsql-general mailing
Re: [GENERAL] initdb createuser commands
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 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb createuser commands
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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb createuser commands
On 31 October 2016 at 15:50, Christofer C. Bell 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.
Re: [GENERAL] initdb createuser commands
On Mon, Oct 31, 2016 at 10:50 AM, Christofer C. Bell < christofer.c.b...@gmail.com> wrote: > On Sun, Oct 30, 2016 at 11:10 PM, Melvin Davidson > wrote: > >> >> >> >> >> On Sun, Oct 30, 2016 at 8:08 PM, Samuel Williams < >> space.ship.travel...@gmail.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 >>> 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_) 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 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@postgresql.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
Re: [GENERAL] initdb createuser commands
On Sun, Oct 30, 2016 at 11:10 PM, Melvin Davidson wrote: > > > > > On Sun, Oct 30, 2016 at 8:08 PM, Samuel Williams < > space.ship.travel...@gmail.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 >> 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_) 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 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@postgresql.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
Re: [GENERAL] initdb createuser commands
On Sun, Oct 30, 2016 at 8:08 PM, Samuel Williams < space.ship.travel...@gmail.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 > 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_) 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 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@postgresql.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.
Re: [GENERAL] initdb createuser commands
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 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_) 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 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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb createuser commands
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_) 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 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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb createuser commands
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)
Re: [GENERAL] initdb createuser commands
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 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. 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.kla...@aklaver.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb createuser commands
> 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 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 >> 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.kla...@aklaver.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your sub
Re: [GENERAL] initdb createuser commands
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 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.kla...@aklaver.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb createuser commands
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 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.kla...@aklaver.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb createuser commands
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 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb createuser commands
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
Re: [GENERAL] initdb createuser commands
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 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb createuser commands
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
Re: [GENERAL] initdb createuser commands
On Sat, Oct 29, 2016 at 6:25 PM, 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. > > > -- > 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 > I *'d like to put my two cents in at this point. IMHO, the whole concept of renaming commands "to make it easier for beginners to learn" is ludicrous.If we rename a saw to woodcutter, or drill to holemaker, it would do nothing to make someone learn carpentry easier. Likewise, renaming commands would not make it easier to learn PostgreSQL. If someone truly wants to learn to be a PostgreSQL DBA, there are many fine books already in existence that guide them step by step how to do so. In addition, as others have already pointed out, the PostgreSQL documentation clearly describes how to use all commands in question and renaming (or prefixing )them would do little to add to that. In fact, I'm pretty sure, existing DBA's like myself would be quite upset if commands were arbitrarily renamed.* *So as a wise man once said, If it ain't broke, don't fix it!* -- *Melvin Davidson* I reserve the right to fantasize. Whether or not you wish to share my fantasy is entirely up to you.
Re: [GENERAL] initdb createuser commands
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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb createuser commands
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.kla...@aklaver.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb createuser commands
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 :) -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb createuser commands
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 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 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb createuser commands
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 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 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 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 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.kla...@aklaver.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb createuser commands
(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 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 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 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 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb createuser commands
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
Re: [GENERAL] initdb createuser commands
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 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_) 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.kla...@aklaver.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb createuser commands
> 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 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_) 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb createuser commands
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_) 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.kla...@aklaver.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb createuser commands
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_) 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
