The query is just passed as-is to sqlite, so you can do inserts (and create tables, too): $ cq t:=- -q ' insert into t values (2,3); select * from t;

The query is just passed as-is to sqlite, so you can do inserts (and create tables, too): $ cq t:=- -q ' insert into t values (2,3); select * from t; ' <<EOF foo,bar 1,2 EOF foo,bar 1,2 2,3 I can't think of a good use-case to do create table from this tool, though. It would always be simpler to just create the CSV file. Also, I can't see the point of interpreting "commit" in the SQL to do a git commit. This tool just passes the SQL to an established SQL engine (only SQLite for now). I don't think I want to get into interpreting my own version of SQL. It doesn't sound KISS. In the same vein, interpreting "create table" to create a schema.csv also sounds out of scope just from having to interpret that instead of passing it to an SQL engine, and I can't see the point either. Ultimately, my aim is for this tool to be more analogous to jq than to sqlite. It's not so much an RDBMS, although you can query a directory of CSVs by globbing like it's a database. It's mainly an ad-hoc querying tool. EDIT: I don't know anymore. I'm growing to like your idea, and thinking of how it can be supported. I'll keep it in consideration. Does anyone have a concrete use-case for a human readable database with automatic git commits like that? It wouldn't be fast enough for anything intensive. I can only see it as a CLI version of Excel. It may also be nice to be able to use that to export a DB to SQL and then use cq to turn that into a set of CSV files. Would anyone really find something like that useful, though? Maybe that's pointless.