I can only suppose that neither feature was thought unnecessary, though they make plenty of sense to me.  The library does have to know the type of each column in order to populate the user-level row data structure correctly.

On Sat, Sep 21, 2019 at 9:30 PM <xxxxxx@ancell-ent.com> wrote:

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.