(Note, I'm replying to a message that John accidentally only replied to me to. Shouldn't these lists default to replying to the list??)
Subject: Re: ODBC mostly a dry hole for (non-Windows) FOSS, and little or no *BSDs??
Date: Friday, September 13, 2019 10:42 AM
Whereas I'm pretty sure we as a group are dedicated to giving SQLite and PostgreSQL first class support,
I'm still trying to catch up with list traffic, but although I know people who have had bad experiences with MySQL and its relatives, I also know people who have had bad experiences with PostgreSQL.
As far as I know, the bad experiences are largely of different natures. MySQL started out as a thin SQL layer over a non-transnational but fast ISAM engine which fit the web read-mostly model (until you had to recover a database), and for some time they bad mouthed the very idea of transactions. It's big advantages over PostgreSQL today probably include having multiple database back ends, including one MVCC that might not have PostgreSQL's vacuum issue, and accumulated infrastructure, especially to get around its initial limits. PostgreSQL issues I know of are less maturity in the ecosystem, especially when you go beyond one server, and the back end that requires vacuuming to recover space from deleted rows.
I think it's right to treat SQLite specially because it is in-process and zero-admin, and is essentially a new data structure (tables and ACID) for Scheme that happens to be persistent to the file system. And for SRFI purposes, we certainly can support just one database as a POC, which is all a SRFI needs.
I *strongly* disagree when it comes to interfacing to complex external systems like a database, or a POSIX provider, thus the useful exercise of my getting my Chibi Scheme SRFI 170 example implementation to run on OpenBSD, but Windows would have been a lot better. Ideally, I'd like a matrix of two Scheme implementations on two wildly different systems like a UNIX/Linux and Windows, and two external systems (databases here, operating systems for SRFI 170), but only the latter is really important.
But I wouldn't want to see one SRFI per database either. In short, "think globally, act locally."
I think it would be entirely pointless to elevate single database libraries to SRFIs; as I've previously argued, you can't depend on a single database system remaining viable for the period the SRFI should (and SQLite is a pretty small outfit). And anyway, whatever database interface SRFI you come up with, I'm going to make it work with PostgreSQL by hook or by crook ^_^.
I agree that ODBC is probably not the way to go.
[...] how's Scheme support for [ the Windows ] platform?
There aren't as many Schemes that run on Windows, but it's definitely more than a minimally supported platform (even excluding Cygwin). I should probably write out a list of which Schemes have native Windows implementations....
Actually, for system level database interfaces, it would be nice to include a native Windows implementation in the mix. But I'd guess that's not a big deal, SQLlite writes to a single file and handles the lies of systems (I would bet non-trivial money less lying than in Linux) and hardware, PostgreSQL has a TCP/IP interface, as I'd assume most other multi-user databases we'd want to support also have.
Or the JDBC kludge ought to work for the "second class" level of support databases, Windows still being a first class JVM server I assume, certainly officially supported on the download pages of Azul's Zulu and and Amazon's Corretto. Both companies that have Java Technology Compatibility Kit (TCK) licenses to vet their builds, and anything Azul supplies they'll support for money (much less than Oracle, and almost certainly much better support).
- Harold