> From: Lassi Kortela <xxxxxx@lassi.io>
> Subject: Re: RDBMS data types and NULL representation
> Date: Wednesday, September 11, 2019 3:53 AM
>
> Thanks for the detailed remarks Peter!
>
>> In the CHICKEN ecosystem, we have a few DB eggs that people enjoy
>> using.  The one that comes up most is sql-de-lite[1], which is
>> indeed a delight to work with, very elegant and high-level.  It
>> offers a rather "functional" approach with fold and map and such
>> over rows.  I've modeled the postgresql[2] egg on it.  I think
>> these APIs are very Schemely and not so "object-oriented" as you
>> see in some other libraries.
>
> Some lesser-known Schemes have GDBM and ODBC support. Some SRFIs
> might make sense in this area. We could try to come up with a good
> partitioning of the problem domain to SRFIs before starting work on
> any of them. I only know basic SQL myself, so I'll leave this to
> others....

At the bottom, I'm envisioning a "plumbing" SRFI.  It's remit besides
basic plumbing could include:

Hiding the concept of prepared statements, which I'm not sure are so
important nowadays, but I've got to research this, its been decades
since I had to deal with this issue, and the world has fundamentally
changed.  "Cache is the new RAM, RAM is the new disk, disk is the new
tape", or at least this is true of hard disks, and of course flash
has also fundamentally changed the game.

Preventing statement injection in data; while this violates the
plumbing focus, I believe it should be enforced at the lowest level
so every use of this set of SRFIs and libraries benefits from it.

Standardization of errors, which would include its own ones like
reporting the refusal to allow an injection attack.  Probably
includes a disjoint type, so like the system errors in SRFI 170,
would be its own SRFI to get around the library sharing issue.

Ignoring the above injection prevention promise, an escape which
allows executing arbitrary statements supplied as strings.  Not sure
if or how this could or would include returning data other than
success or failure.

It's remit should not include:

Data types to the degree possible.

SQL *per se* as a query and update language, most especially the
differences between what the various databases support and how.

To be determined:

Transactions.

- Harold