All of those can be done in the CLI and quickly.

CLI has a learning curve but what many will say is that we are SO GLAD we learned to not use our mouse to work with our data base and especially our SQL code.

The reason why I like using CLI is I can use GIT or any version control and make sure I have a clear history of my SQL commands and everything I did.

TL:DR Database Vendor with a Windows Server product screw with the logs and put the blame on me. I had a version control of all our history of CLI commands. Vendor employee or manager changed our log files externally. We won big court case (Before trial of course). Wouldn't have happened if I used the GUI tools.

Long story short. The vendor at the library I want was 100% evil. I asked by phone about two things. I emailed the engineer after the phone call for the two questions. BOOM I lost one month of work unless my backups work. Boom I lost half a day of work for 2 librarians. Vendor tells my boss and my school it will cost us $5,000 due to my mistake for them to fix something (Took them 15 minutes work on the phone due to their error).

My boss and college have a good relationship with me and we go on a conference call. Vendor tells a very convincing story and logs how I screwed up. They don't have records of my phone call and have 100% confidence that their employee would never okay both those things. I call them on the table. I have the email with the answers that the engineer gave me. BOOM their Engineer VP jumps in and says see if you did what he told you nothing bad would have happened and our logs show ... I than email my version controlled CLI commands for the past 6 months and show my commands that I did that day and that if the logs on their end our different they have a serious problem internally.

Long story short we won the court case and we got over hundreds of thousands of dollars back from that vendor.

Nice example of how learning the language has some intrinsic advantages that quickly outweigh the inconvenience of having to learn the language. It took me awhile to learn SQL myself and so I dread a bit having to teach it...but while I love spreadsheets...it is incredibly tiring having to create tutorials in which you explain which button to click and where and in what specific sequence and to make sure you've dragged the mouse so far and held Ctrl (or Cmd depending on what OS you are)...nevermind the problem of troubleshooting (what did you click before you clicked that button and did you left-click or right-click it and, btw, what version of Windows are you on?).

SQL is difficult to learn for new programmers...but I find that that hurdle quickly pays off...no one ever keeps track of how much time they lose to struggling with the GUI because, well, doing things with the GUI are generally very hard to track. And it's a useful revelation, that being explicit, that having the ability to express exactly what you want, has a certain power to it. It's like teaching how to read and write to people who've so far learned only how to communicate in emoji

> All of those can be done in the CLI and quickly.

I'd love to know how.

I use psql exclusively but I think those are good questions and I'd love to see someone give you an answer. Personally I don't feel much friction using psql even for "exploration", but I can see how a GUI would let you more easily follow data from one table to another.

EDIT: I've just barely tried it, but it looks like you could say `\g |vim -` (with a csv plugin) or `\g |csvlook` (not great) and then browse/sort/aggregate the data from there. You probably need to change the output formatting though, because it looks like \g doesn't automatically give you something easy to parse. I have a feeling an interactive command-line CSV reader (less(1) for csv files) would be really useful to a lot of people, but I don't know of anything like that. csvkit isn't interactive as far as I know. csvtool dies on big files. Any alternatives? It would be the perfect thing to combine with \g.

EDIT EDIT: Or just \pset pager and you don't need \g at all. . . .

I would try: First One Hour: https://www.khanacademy.org/computing/hour-of-code/hour-of-s...

Also these two seem decent: http://sol.gfxile.net/galaxql.html

http://sql.learncodethehardway.org/

The Hard Way has semi-decient issues.

I would say SQL is easy to learn and would take only a few days to get the basics and than just learn as you come to stuff your missing. SQL is a very tiny language.

So, when you read these parts of my post:

> Edit your query to add an ORDER BY clause?

> Check the primary key and write an UPDATE query? Hope not to make a typo when writing the key.

> write a SELECT query?

did you think that I was saying: "I think this is how I would do it in SQL, if only I knew SQL. Won't you please point me to somewhere I can learn SQL so that all my problems will be solved"?

Because what I was going for was: "here is how I would do it in the CLI, but I much prefer how I would do it in PMA. Please tell me if there's a better way to do it in the CLI". I know SQL, I thought it was obvious that I knew SQL, and pointing me towards SQL tutorials is super unhelpful.

Go to Stack Overflow. Yes the reason why no one gave you your SQL code is we know that the GUI is just making SQL code for you. Sorry we probably have the mindset of we pointed you to the answer and we are not going to give you specific answer to your questions.

I googled searched by copy and paste your question for 5 seconds for each question:

> Edit your query to add an ORDER BY clause? http://www.techonthenet.com/sql/order_by.php

> Check the primary key and write an UPDATE query? http://stackoverflow.com/questions/3930338/sql-server-get-ta...

> write a SELECT query http://www.w3schools.com/sql/sql_select.asp

I think your issue is you are biased against CLI and think you get more benefit from a GUI. We can convince you what is best for you. We are just saying everything you pointed out is easily done in CLI with SQL commands. We believe everyone who works with databases should use CLI for a number of benefits because of our own experience.

...what part of

> I know SQL, I thought it was obvious that I knew SQL, and pointing me towards SQL tutorials is super unhelpful.

makes you think that I just need really basic SQL tutorials?

I get the impression that you're glancing at my posts, picking out a few words, making up a question that someone else might have asked using those words, and answering that question instead of the one I'm actually asking.

This is incredibly frustrating for me. As such, I decline to continue this conversation.

No I am being super Ironic. You are listing EASY to do SQL commands as things that you don't know how to do. You than ask use to show you.

What is your question besides show me how to do 1, 2, 3?

If you think that a click is "easier" than the CLI because, presumably, a click is just a click...then the features of the CLI are not for you. The point of a CLI, and programming in general, is the ability to be explicit with the software and the machine, rather than learning to use the buttons laid out for you by a front-end designer. Sometimes, the latter is good enough, of course.

I think a click is easier than the CLI in some situations, such as when I'm looking at a table and I want to edit a specific value in it. (A curses interface would also be better than a classical CLI for that.)

Note that jperras said "Stop using web-based admin tools". I think the CLI isn't good enough to fully replace them, but I don't think that one should stop using the CLI. I use both.

I apologize for coming off as unnecessarily snooty...however, I interpreted your challenge as kind of broad and, at first glance, missing the point of a CLI...("I'm skeptical that the CLI can do everything I'd want")

The CLI is supposed to let you do more of everything you want, versus a GUI, at the cost of being more complicated...but that's programming in general...programming is always harder and more tedious than the pre-designed solution, but people go the programming route when they need to ability to go beyond anticipated use cases. But if by "everything I'd want" you're referring to not just functionality, but overall usability...no argument, the CLI doesn't provide that. Although I'd argue that at a certain point, the CLI is easier when you need performance and peace of mind that something happened even if it is not easily visible via the GUI.

> View the extreme values of a result set? I.e. I run a query which returns 200 results, and I want to look at the first few and the last few. (PMA: home and end. CLI: scroll?)

Well, you could do that; if you know you are interested in extremes to start with, use ORDER BY and LIMIT to just get the extremes in the first place (or, for more refined concepts of "extremes", consider the use of window functions.)

> I'm skeptical that the CLI can do everything I'd want

You do understand the phpXAdmin's are built on top of the CLI and the same API?

If anything, you can do more with the CLI than with a higher-level abstraction tool someone has to build logic paths/workflows into.

I do understand that, but I want a tool that works with me, not just with an API.

>- View the extreme values of a result set? I.e. I run a query which returns 200 results, and I want to look at the first few and the last few. (PMA: home and end. CLI: scroll?)

SELECT TOP ORDER BY ?

You mean, run the (possibly expensive) query twice with different sort orders, and not see the middle ones at all?

If that is what you mean, I think the advantage remains with PMA.

Edit to clarify: I'm thinking here in terms of data exploration. I want to look at the whole result set, but the most interesting ones are likely to be at the top and bottom. With PMA, I can get the whole result set, and nothing else, on a single page. So I just scroll to the top or bottom of the page to see the extreme values.

With a CLI, it can be difficult to find where the output of that specific query started. (This is a trade-off, because the CLI allows you to see results from your previous queries.)

If there was a CLI feature like 'view the previous result set in less, without re-running it', I think that would satisfy me on this point. If you have to re-run it, that's less good, but it would beat scrolling.

If a default pager isn't set for you, you could set it. http://stackoverflow.com/questions/14474138/customize-pager-...

Thank you! This is a pretty good solution, and it turns out it exists in mysql too. (`pager less`)

> You mean, run the (possibly expensive) query twice with different sort orders, and not see the middle ones at all?

Or run it once into a temporary table, and then query the temporary table however you want to get subsets of interest. Which, if you are doing data exploration on the potentially large results of a potentially expensive query, is probably what you should be doing, no matter what tool you are using. Because it lets you do a lot more than just check the top and bottom easily.

Common Table Expressions: http://www.postgresql.org/docs/9.4/static/queries-with.html

I'm not a DB/pg guy but I think you want SELECT INTO TEMP which will create a temp table from your query (gets dropped at the end of the session).