What are the various levels of Scheme data types we want to support, and how, for databases?

For "lowest level", I perhaps exclude things like s-expressions which have no direct corresponding general database data type, general portable Scheme procedures will be required to convert them to and from something "lower level".  Those conversions will I assume in part come from the current text and binary encoding work being done, but I use the preceding weasel wording because conversions to something searchable by a query language should be seriously considered.

So for lowest level, text and numbers are obvious, and whatever else databases natively do.  Both JSON and XML have direct SQL standards adoption, and PostgreSQL supports both, but not really usefully for XML (from a quick skim, validates on input, but has no comparison operations).  SQLite3 has a JSON module of library functions.  Etc.

Another critical category is dates and times, we should plan to finalize SRFIs for them before we finish database SRFIs that need them.

Text is messy, although as I remember from our previous discussions databases tend to be set to one encoding, e.g. I normally use UTF8 for PostgreSQL, but SQLite3 is more flexible.  Suggestions on precisely what to do here are solicited, this is not a thing I know very well.

At the database side, I need to construct something that contains all the types a column (or whatever for e.g. graph databases) can have, which are supported by which databases, and with what quirks.  This will eventually become architecture and code to Do The Right Thing in the middle of the sdbi stack, automagically, or at the direction of the user.

If anyone has a collection of the last drafts for the latest SQL standards, especially SQL:2016, I would appreciate copies so I don't have to hunt them down on the web.

Thanks in advance, and for all the support you all have provided to date.

- Harold