> Ctrl-c kills the whole shell. great, but not what I expect.

That is actually exactly what you should expect. SIGINT cancels most things you run in the CLI.

Interrupt a ping because you forgot a count parameter? Ctrl+C

Honestly, the reason I don't use Postgres has nothing to do with the CLI and everything to do with the ecosystem for Multi-Master being inferior to Galera. But yeah, I'm happy with mysql-cli as well and don't really see the Postgres equivalent as a noteworthy improvement.

Ping isn't a CLI, its a single command that expects no further input. A database shell is more like bash than ping. And Ctrl-C does not exit out of bash.

Many language REPLs don't exit on ctrl+c either, at least I know Ruby and Python don't. Node will, but it will make you do it twice.

Ctrl-C conventionally does not kill shell-like things. This is, technically, of course because of cooperation of those shell-like things and their handling of SIGINT, but that's not actually relevant.

The following things (off the top of my head, and quickly verified) all handle Ctrl-C so that it kills only the current command and not the containing process:

bash, zsh, csh, ksh, mail, gnuplot, gdb, psql, vsql, python (interactive), ghci

While I object to captive user interfaces in general, if you're going to have one then handling ctrl-c inside it is the right thing to do.

In Postgres' psql, Ctrl-C cancels the current statement. That's a more useful behavior than killing the entire psql process, IMO.

In MySQL type \e and you can edit your query just the same.

https://dev.mysql.com/doc/refman/5.6/en/mysql-commands.html

I love that earlier up in this same thread people are complaining about the magic \x sequences in postgres and this is how you do query edits in the mysql cli :)

I've got my biases, but whenever something like this comes up, I just make some popcorn and enjoy the show.

The complaint was that in psql the backslash sequences are a combination of client operations (\copy, \html) and database metadata operations (\d) [0], which while extremely rich, are a huge list and are not very intuitive to learn. Many differ on case (\df vs \dF). \des and \deu mention the mnemonics for why these are named that way. "External servers" listing "foreign servers" I can understand, but it seems that "external users" are not actually "external".

In MySQL the backslash sequences are commands to the mysql client for things that are implemented in the client and have to do solely with the command line client software. These things are not available using other clients. Vs things like listing columns and databases and functions have their own DDL language constructs entries and are queries in their own right that can be sent by any client software to the server and return iteratable results. MySQL is more like Oracle in this regard.

That distinction isn't obvious in psql and that contributes to a larger hurdle when using the command line client. This makes psql attractive to power users, as there are a lot of shortcuts for things that might require longer DDL statements to be typed or queries against information_schema.

[0] http://www.postgresql.org/docs/9.0/static/app-psql.html

It's not really possible to implement "edit the query I'm already partway through" with anything other than a magic sequence. Doesn't mean magic sequences are the right way to do everything.

Whenever I do anything more than a oneoff SQL statement (and often even then) I'll use emacs with sql-mode. It supports all the major SQL dialects and cli utilities.

> In psql you can just edit your last command in your $EDITOR.

Cool! How?

`\e` will edit whatever is in the query buffer (`\p` shows the content of the query buffer)

Just type \e [ENTER]

Autocomplete is in MySQL you might just need to enable it with -A or in the config comment out no-auto-rehash.