Lynn Winebarger <owinebar@gmail.com> writes:
> It seems like a method for
> compiling sexpr-type representations of sql queries into statements
> usable with the builtin support would still be useful, and not limited
> in the same way - since the returned values do not require serializing
> as text by the sqlite shell then parsing them in Elisp.
Of course "SQL as vectors" and "store everything as a string" are not
tied to each other per se, but with EmacSQL you get both.
The whole SQL as vectors conceit isn't something I've given a lot of thought to. As long as it's a syntax tree and not a pile of strings. Vectors or conses - both can be analyzed by pcase, so I start at a point of indifference.
> [ Digression...]
> Just looking at the src/sqlite.c in master, as there is no other
> documentation of the sqlite support I can see, only a simplified form
> of the core API is supported - not unreasonable for an initial
> release. The only noticeable absence I see, based on a cursory review
> of the sqlite3 API spec, is that a select query cannot be reset.
> Maybe because each db connection is associated with at most one
> prepared statement at a time by the design of the Lisp_Sqlite
> pseudovector?
>
> Other than that, I note that rows are returned as lists rather than
> arrays, which makes the semantics more incompatible with emacsql than
> it really has to be. Can that be changed before 29 is released?
Why is that a problem? What would we gain if the DSL and the output
both used vectors or both lists?
It's not the SQL expressions I'm concerned about. I'm just thinking of the existing sql-using code base expects rows to be represented with arrays, why add the cost of remarshalling them from lists?
It just seems like a gratuitous incompatibility to me, unless there's a strong reason to prefer lists. I have no other reason to prefer either representation. The die is cast now, anyway.
Lynn