On Thu, Sep 19, 2019 at 06:35:45PM +0300, Lassi Kortela wrote:
> > > (sql-read result-set) -> list
> >
> > > Returns a list of Scheme objects representing the next available row of the result-set.
>
> Is there a particular reason we are representing a row as a list instead of
> a vector? Vectors have the advantage that it's fast to get a given column by
> index, and all rows from a given query ought to have the same number of
> columns.

I think I've mentioned this before: I think it's better to return an
opaque result-set object which is random access.  As far as I know, all
database libraries actually read from the protocol until it's empty
and store the entire result set in memory.

These opaque result set objects can include metadata like type
information about the columns in the result set, which this API lacks
completely.

> > > NULL is represented by the symbol nil.
>
> Is there a particular reason to use nil instead of null? null is native in
> SQL, and we are also planning to use it  for JSON so it'd be nice to be able
> to standardize on it.

I would like to reiterate that I think it's a shame to use the symbol
datatype for this, as it basically means you can't encode anything
else as symbols.  For instance, symbols would be a good match for enum
values or as references to SQL variables for those dialects that support
them.  By encoding null as 'nil, this would create an ambiguity if one
wanted to use symbols for something else.

A special distinct object type would be best, IMO.

> > > (sql-read-all result-set) -> list of lists
> >
> > > Returns all available rows in this result-set.
>
> This is nice to have, and the name is good.

True, except that I would prefer an opaque object like I mentioned
above.  And streaming results only happen in case of server-side cursors
and those are not common.

Cheers,
Peter