Feature request: modification of files

[vi]

$ q "INSERT INTO a VALUES (44, 55)"
query error: no such table: a
$ q "DELETE FROM a"
$ cat a
1 2
3 4
5 6

Alternatively, if modification is never going to be implemented then SELECT may be omitted and maybe q renamed/aliased to SELECT.

[harelba]

I have been thinking about adding modification queries, and this is part of the reason why the command is q and not select. In addition, I didn't want select to be case sensitive, which would have been the case if the command itself would have been called "SELECT".

One of the reasons adding modification commands is stalled is because this requires much smarter parsing of the queries, for which I haven't found a good solution yet.

What do you think about the popularity of such a feature?

Harel

[vi]

I didn't want select to be case sensitive, which would have been the case if the command itself would have been called "SELECT".

When I see select, I first think about the select(2) syscall. When I see SELECT, I immediately think about SQL.

[vi]

What do you think about the popularity of such a feature?

Maybe the presence of such feature can be taken for granted, but absence seen as an disappointing moment... I don't know.

One of the reasons adding modification commands is stalled is because this requires much smarter parsing of the queries, for which I haven't found a good solution yet.

Much smarter? Means handling UPDATE ([^ ]*) and DELETE FROM ([^ ]*) and INTO ([^ ]*) in addition to FROM ([^ ]*)? Why parsing of the queries for updating can be smarter than for selecting?

[bitti]

When I see select, I first think about the select(2) syscall. When I see SELECT, I immediately think about SQL.

But SQL is case insensitive, so harelba has a point. I also don't like the idea of spoiling the namespace with all kinds of common keywords. ImageMagick did that mistake and we get annoyed dearly by that to this day.

[webmaven]

What do you think about the popularity of such a feature?

I think it would be very popular. I would like to build and distribute small example apps with example data, and having SQLAlchemy immediately able to call into CSV data via q (or qtextasdata) instead of having to first load the example data into a db like SQLite would make for a much nicer experience out of the box.

[harelba]

I've released version 1.5.0, which internally is a full python API.

Doesn't support any modification of files, but might be relevant for some of the use cases. Your input on the API will be most welcome (Take a look at the API development branch in https://github.com/harelba/q/blob/expose-as-python-api/README.markdown)

Please note that providing a full-blown modification API is not a small feat... :)