27 comments

[ 2.6 ms ] story [ 28.4 ms ] thread
I have been looking for a faster alternative to pgcli [1] ( with features like auto-complete for table names and columns) and was getting excited.

Sadly this is "just" a plain old CLI.

Also: had to install with `go get -tags "no_sqlite3" -u github.com/xo/usql` since the sqlite3 package did not build.

[1] https://www.pgcli.com/

It’s at a disadvantage vs pgcli and mycli because they’re in Python and have access to the excellent Prompt Toolkit (which also powers ipython), while usql is in Go.

I started using mycli recently and it actually made me joyful about how good it was. DBeaver is really good but for most things I’d prefer a cli, and the autocomplete actually makes it faster to use for many things.

I've not used Prompt Toolkit (or usql) but am very interested in making better cli, what makes Prompt Toolkit so good?
I was really hoping for \dt but looks like they haven't implemented it yet. The number one most common thing I look up when I'm using a SQL variant is how to show the tables. I suppose there would be complications with NoSQL but you could just show available collections or whatever else it maps to in that case.
Yes, and since "show the tables" isn't in SQL itself, each CLI ends up having a different command for doing it, which makes a universal CLI appealing to me... if it can do that.
> since "show the tables" isn't in SQL itself,

Actually

    SELECT table_name FROM information_schedule.tables;
But yes, that's harder to type/remember than \d.
Does that really work for every version of SQL? This might change my life.
Also, you can see a more or less complete "contents" listing of the recent draft standard here:

https://webstore.iec.ch/preview/info_isoiec9075-11%7Bed4.0%7...

Not the actual standard though, that'll cost you a few hundred bucks.

[edit - you can see the 1992 complete version here; do a search for information_schema.

http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt

courtesy of Ian Winand - https://modern-sql.com/standard]

Awesome project! Having unified tools is a boon for those of us who work across many different dialects.

One piece of feedback though - I've never been a huge fan of using backslashes for anything that isn't escaping as it can get confusing to know when it's escaping or if it's syntactic (do I use two slashes here? Or three or four? Especially when piping input or putting stuff in text files).

Very cool though and will be keeping an eye on it!

If you're interested in this sort of thing, it's worth checking out https://drill.apache.org/

It lets you query multiple databases but also join between them. Or say, translate your mysql table to a local csv file. And if you need it to be faster you can deploy to hadoop.

worth checking out anyway, I used to use it a lot before i started on Apache Spark.

The universal CLI for my preferred database is `dig` if you're old-school, `drill` if you're not.

Some may argue that DNS isn't really a database, but by that metric, neither is Redis.

Do you do that by memory? Or do you have some text indexing tool that helps?
I use HN Search, which is linked from the bottom of most HN pages. That's definitely a text indexing tool that helps! The search company Algolia provides it for free—a major service to this community, because not only does it help users find things, we rely on it heavily for all kinds of moderation tasks.

It's particularly helpful to include "comments > N" or "points > N" if looking for old threads.

How come a standard (network) protocol for SQL RDBMS'es never came to be? Sort of JDBC, but based on TCP (HTTP?) not Java.
Because once you get beyond select and where clauses database diverge a lot in capabilities and syntax. If all you want is a common interface to send arbitrary text to an arbitrary RDBMS then ODBC mostly solves this.
If you like this, check out OctoSQL.

It not only presents a SQL interface to sql databases, NoSQL databases and files (Excel, csv, json for now), but also lets you join data between them and use multiple databases at once in queries.

Though it's definitely in an earlier stage and maturity than this, with fewer supported databases. (Though we do support redis for instance, which this does not)