Re: Unboxed package manager

[Lynn Winebarger <owinebar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]

On Wed, Mar 22, 2023, 7:17 AM Jonas Bernoulli <jonas@bernoul.li> wrote:

> 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

[-- Attachment #2: Type: text/html, Size: 3001 bytes --]