Add some support for the ESCAPE operator

[ak-coram]

Hi, this is my shot for at least partially fixing issue #10. I've
added special case handling for the escape operator to ensure that
the second operand is an Emacs character. Using backslash is still not
practically possible as the values that are matched are still printed,
but now other characters (which are not escaped by printing) can be
used safely. For example this works just fine now:

[:select url
 :from [:select "http://example.com/%test" :as url] :as tmp
 :where (like url (escape "%`%%" ?`))]

As far as I recall backticks are not allowed in URLs, so this seems to
be a viable alternative for this exact use-case. You'll have to be
careful choosing your escape character, but that is already the case
when you use SQLite. This change allows you to use at least a subset
of what SQLite allows for.

Please let me know what you think!

[ak-coram]

Noticed some small mistakes and fixed them.

[skeeto]

Thanks! I didn't even know about ESCAPE before this. Not quite related, but reading your PR sparked a thought. Understatement of the whole project: It would probably be much more useful if EmacSQL did not print values before encoding them into a query. Perhaps this could be an option (a dynamic variable?) when compiling an s-exp into SQL, which defaults to the current behavior. Under this special option, it still does all the escaping, just skipping the print step. When gathering results, it would skip the read step. Only nil, strings, integers, and floats would be allowed as values. All other data types, including symbols (other than nil, which is NULL), are an error. In order for this to be consistent for all accesses to a database, this would be a property of the connection object, which is already used as context when compiling expressions. The option would be configured as a new keyword argument when opening the connection. (emacsql-sqlite "path/to/db" :print nil) ;; TODO: pick a key name better than ":print" Only the "sqlite" and "pg" backends could support this option. The "mysql" and "psql" cannot since they rely on printing/reading for unambiguously parsing database output — e.g. to accurately read values printed by the command line client. The latter is one of the main reasons EmacSQL works as it does, particularly since the original plan was to use the "sqlite3" command line program in the same exact way until I discovered how unreliable it is. If I remember correctly, EmacSQL's custom SQLite native client also relies on the printer and reader for correct operation, so it would need to be changed as well. That's probably the hardest part of implementing this idea.

[ak-coram]

@skeeto, thanks for merging the PR.

It would probably be much more useful if EmacSQL did not print
values before encoding them into a query. Perhaps this could be an
option (a dynamic variable?) when compiling an s-exp into SQL, which
defaults to the current behavior. Under this special option, it
still does all the escaping, just skipping the print step. When
gathering results, it would skip the read step.

I was thinking along the same lines, the defaults could be kept
compatible while allowing for a more broad set of use-cases.

The option would be configured as a new keyword argument when
opening the connection.

I'd allow this to be configured on multiple levels. The connection is
a good start, but for example it could also be useful to disable the
read for a single query where you want to process values via SQL
operators or functions. To go even further it might be nice to have
this on an individual value level: if you generally want to print/read
values, but need to pass a string to a SQL stored procedure verbatim
(maybe introduce our own unary operator for inhibiting printing for a
value?).

Additionally instead of only being able to disable print/read, I'd
allow for specifying your own functions. This way you could do JSON
print/read (turning alists into JSON objects), which could be useful
with PostgreSQL since it supports JSON as a datatype and has several
operators to work with it. Using the new json-serialize and
json-parse-string would make this quite efficient too. Of course you
would have to be careful about which elisp values your custom reading
/ printing can support.

If I remember correctly, EmacSQL's custom SQLite native client also
relies on the printer and reader for correct operation, so it would
need to be changed as well. That's probably the hardest part of
implementing this idea.

Yes, it does seem a bit daunting especially since I've only looked at
the compiler code so far.