This is interesting, but I note that if you allow that first row of primary keys to also be numbers, this API will be able to manipulate some number of existing database schema.  I can't remember a single OLTP schema I've designed or used that didn't follow that convention, but there weren't all that many, and I'm not sure about the ones many years ago.  But I gather it's a pretty standard convention, even if the database also maintains its own row id column.

Question: if you allow updates, why not deletes?

- Harold

----- Original message -----

From: John Cowan <xxxxxx@ccil.org>

Date: Saturday, September 21, 2019 8:03 PM

This is not a proposal, just an old idea that might be of some interest.  The idea was to provide access to an RDBMS with a minimalistic library that just about anybody could use.  The host language is statically typed without GC (essentially C for this purpose).  There are only four functions:

1. Given a relation name, return the primary keys of all rows.  It's a requirement of the library that the primary key of a table is the first column and that its type is string, though it may have any name.  Views also must expose a primary key in the first column.

2. Fetch a row by primary key.

3. Upsert a row (update if the key already exists, insert if not). Probably views can't be upserted, though I don't know for sure.

4.  Fetch all rows in no particular order.

For 1 and 4, you specify how many you will accept and are told how many you got.  If you need more, try again with a bigger limit; probably this rarely happens.