-
-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add some support for the ESCAPE operator #50
Conversation
ad2e77e
to
19f2ba9
Compare
19f2ba9
to
5ebd12b
Compare
Noticed some small mistakes and fixed them. |
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.
|
@skeeto, thanks for merging the PR.
I was thinking along the same lines, the defaults could be kept
I'd allow this to be configured on multiple levels. The connection is Additionally instead of only being able to disable print/read, I'd
Yes, it does seem a bit daunting especially since I've only looked at |
Hi, this is my shot for at least partially fixing issue #10. I've
added special case handling for the
escape
operator to ensure thatthe 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:
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!