The in-tree SQLite3 is used for HDB and ccache -- these should have
0600 permissions.
Of course, if we're using an out-of-tree SQLite3, then we need to rely
on the process' umask, but we use SQLite3 in libraries, where we can't
set the umask...
What to do?
TBD:
- On Windows: nothing to do.
- On Unix: if SQLite3 is out of tree then [v]fork() to create the
connection then close, then connect again after??
Or... maybe make sure to create an intermediate directory with 0700
permissions?
The deprecated OSAtomicCompareAndSwapPtrBarrier() function is used by a code
path only taken on macOS systems with a single CPU. As very few Macs have a
single CPU today, remove this optimization. (Replacing it with <stdatomic.h> as
suggested would break compatability with macOS prior to 10.12.)
Newer versions of SQLite3 have a number of new features that are
desirable to users who host other DBs in the same file as the HDB (for
example), as well as performance and bug fixes.
We should consider switching the SQLite3 backend for HDB to WITHOUT
ROWID tables for performance reasons. We should also consider using
foreign keys instead of triggers. Making any such changes requires care
to permit both, upgrade and downgrade.
We might want to use the SQLite3 session extension for a SQLite3-
specific, low-level replication (iprop). Given conflict resultion code,
or a sufficiently normalized schema, the session extension would make it
easy to create a multi-master replication system, not unlike what one
would expect of an LDAP setup, though with none of the atomicity that
LDAP is supposed to provide (specifically, O_EXCL semantics for creates
and predicates for updates) unless we were to add a locking protocol.
Note that as of 3.14, the session extension is mutually exclusive of
WITHOUT ROWID tables.
