If you've not seen usql before, it's a universal command-line client for SQL databases (and now also Cassandra), modeled on psql. usql makes it easy to work from the command-line, in a simple and consistent way across any database and on any platform (Windows, macOS, Linux). usql is written in Go, and provides things like syntax highlighting and compatibility with databases other than PostgreSQL (see below for the list of the supported databases).
Progress is moving at a decent clip towards a v1.0, which I expect to include 100% native Go support for Oracle databases, tab-completion, full compatibility with psql's \pset (and other output formatting) commands.
usql supports the following databases:
Microsoft SQL Server
MySQL
PostgreSQL
SQLite3
Oracle
Apache Avatica
Cassandra
ClickHouse
Couchbase
Cznic QL
Firebird SQL
Microsoft ADODB (Windows only)
ODBC
Presto
SAP HANA
VoltDB
Is there an issue/pr/library for that work? It will very much enter the toolbox for all situations if that can happen :-) (Looking for something better than sqlplus is always why I end up looking into usql...)
usql is super cool, thank you for all the work you've done with it :-)
$ ./usql
Type "help" for help.
(not connected)=>
You are using usql, ...
Type: \copyright for distribution terms
\? for help with usql commands
\g or terminate with semicolon ...
\q to quit
(not connected)=> \q
$
Edit: I'm using the binary package on macOS 10.12.6.
You can either try disabling syntax highlighting completely ( \set SYNTAX_HL false ) or change the Chroma style used ( \set SYNTAX_HL_STYLE paraiso-light )
See this page: https://xyproto.github.io/splash/docs/all.html for an example of what the various Chroma styles should look like.
...and although I'm not familiar with all of the others in that list, the ones that I do recognise have ODBC drivers.
As an aside, I also love the fact he presumed the author of usql - someone who has been reverse engineering undocumented drivers to bring support to Go(lang) - was unaware of what the name of his own tool and the language it exposes stood for, is just laughable.
pgcli
mycli
usql is a great tool if you're familiar with Postgres' psql client and wish you could use it for other databases like MySQL, Cassandra etc.
dbcli tools are designed to preserve the usage semantics of the existing tools but improve on them by providing auto-completion. For instance you can use `\d` in pgcli and `SHOW TABLES` in mycli. This was a conscious decision to make pgcli and mycli drop in replacements for of MySQL and psql. I was also working under the assumption that people rarely use multiple databases, you're either a postgres shop or a MySQL shop. If you have a mix of both, there is a good chance that not a single person is interacting with both of them on a daily basis. You have different teams using different databases. But my reasoning there could be flawed.
There is nothing stopping someone from adding an adapter to the usql tool to make it behave like MySQL (because they like the mysql client better) based on a command line argument, for instance.
Probably because they have different use cases that don't overlap too much. eg SQLite is great for single file info storage and passing around. The others - being competing multi user servers - don't do that. :)
Since usql is written in Go, it compiles to a single static executable, and as such you don't need any extra dependencies. {pg,my,db}cli requires pip + python, which is usually broken on many systems that I've been an admin on. Also, good luck getting pip working properly on Windows. Also, since its written in Go, its likely significantly faster.
I appreciate your point, but your experiences with pip + Python sound unusual and does not track with mine. I manage Windows and Linux machines with the Anaconda distribution, and pip works almost all the time. I don't think that argument should be deployed in this context.