Usql: v0.7.0 released | Hacker News Reader

Usql: v0.7.0 released

github.com

112 pointskenshaw31 comments

Just released the latest version of usql, which fixes issues with syntax highlighting, adds initial support for Cassandra databases via CQL, among other changes.

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

Hope others in the community can make use of usql. Glad to answer any questions if anyone has any.

100% native Go support for Oracle sounds amazing (I'm reading that as meaning no instantclient sdk requirement, just to confirm (which might be wrong...)).

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 :-)

Yes, I've been working on a 100% native Go driver for Oracle. It is not even alpha or beta quality at this time.

Hi, can I see the code, and can I help? I have a beta SAP ASE driver that should come out soon, BTW.

It's more of a passionate side project at the moment, as I am still reverse engineering the protocols involved. It's not close to completion, but I'm hoping to have it done sometime in the next few months. It's not a high priority, as there are other ways to connect to Oracle.

My goal is to get rid of all the non-Go dependencies, which would (for the first time, ever) finally make it a reality to have a single, small binary that can connect to "every" database and that can be freely distributed. If you'd like to help, please feel free to start an implementation. While I'm not following a specific development routine for the native Oracle driver, I do have a repository with a bunch of (non-building) code that I made to assist with inspecting the raw protocol captures.

Someone has already been there, the protocol is very.. rich, I would say:

https://blog.pythian.com/repost-oracle-protocol/

Hell, if that lead to Oracle drivers for other languages, that could be amazing too. It's nearly incomprehensible to me why Oracle hasn't documented their protocol.

Then it would difficult to change.

For instance to support clusters and failover.

MSSQL server protocol is documented and failover is handled. Protocol are usually versioned, or the initial handshake allows client/server capabilities negociation. Oracle has copyrighted a poem that the clients needs to send to make sure reverse engineered drivers are not possible: https://noss.github.io/2009/04/28/reverse-engineering-oracle...

Business as usual for Oracle and their horrible ethics...

ODBC isn't a "database" per se, but a standard interface that can access any database with an ODBC driver.

...and although I'm not familiar with all of the others in that list, the ones that I do recognise have ODBC drivers.

I read that has the client having specific support for these DB but a fallback to generic ODBC otherwhise

Yes and no. ODBC on Windows may (or may not) be provided by the Microsoft JET driver, which can be considered a database unto itself. Specifically, there is a separate ODBC driver for Go that usql supports, which is what this is reflective of. I actually edited the above after posting to remove a double entry for PostgreSQL and MySQL, as there are two different Go drivers for each of those databases (4 in total) that are well supported by the community.

No Db2

When I type help, the characters aren't echoed to the screen, but backslash commands are:

    $ ./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
    $

Is this expected?

Edit: I'm using the binary package on macOS 10.12.6.

This is a syntax highlighting issue, most likely. The \ commands are not highlighted. Are you using a white or light colored background? Likely the contrast isn't high enough. I just updated the documentation with more information on controlling syntax highlighting.

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.

How would this compare to DBCLI?

http://www.dbcli.com/

pgcli

https://www.pgcli.com/

mycli

https://www.mycli.net/

I'm the creator of dbcli. I can give you my perspective.

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.

As a data point, it seems to be reasonably common for people to use both SQLite + <some other database> (eg PG).

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. :)

Up until very recently I used to regularly hop between sqlite3, Informix (don't hear much about that these days), MySQL (or compatible) and some key/value stores like Redis and memcache. Occasionally used to dip into MSSQL too but that wasn't often.

As what amjith said -- however, I personally find myself working with upwards of 3+ different databases in a single day. I may not be the use case, but eventually I realized it would have been easier to write a single, consistent client that works across all databases the same, as opposed to learning yet another broken, random client.

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.

> is usually broken on many systems that I've been an admin on. Also, good luck getting pip working properly on Windows.

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.

usql != U-SQL. One is a database client, the other a database language. This could become confusing.

Usql != Transoft U/SQL either

SQL is an initialism. Please capitalize it, as it should be. It stands for Standard Query Language.

A very large portion of developers I speak to pronounce it as 'seekwol'. Some of them also prefer tabs.

Acronyms should also be capitalized.

You mean like laser, radar and scuba?

I think they're saying "SEQUEL", which is the widely accepted/recognized pronounced mononym for "SQL".

S = structured, not standard

Indeed. There's definitely nothing standard about sql (intentionally lower cased for fun) what with every DB out there adopting their own set of features. Even the core syntax of sql can vary significantly eg joining tables in Oracle's PL/SQL vs ANSI SQL (eg MySQL). When something as basic to the concept of sql as table joins can very so significantly, you have to question what the GP was smoking to assume the "S" in SQL stood for "Standard" :P

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.

psql is not capitalized; this is modeled on that.

Reply on news.ycombinator.com