On Wed, Mar 22, 2023, 7:17 AM Jonas Bernoulli wrote: > Lynn Winebarger 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