This is behind the `i128_blob` feature.
Blobs are stored as 16 byte big-endian values, with their most significant bit
flipped. This is so that sorting, comparison, etc all work properly, even with
negative numbers. This also allows the representation to be stable across
different computers.
It's possible that the `FromSql` implementation should handle the case that the
real value is stored in an integer. I didn't do this, but would be willing to
make the change. I don't think we should store them this way though, since I
don't think users would be able to sort/compare them sanely.
Support for `u128` is not implemented, as comparison with i128 values would work
strangely. This also is consistent with `u64` not being allowed, not that I
think that would be reason enough on it's own.
The `byteorder` crate is used if this feature is flipped, as it's quite small
and implements things more or less optimally. If/when `i128::{to,from}_be_bytes`
gets stabilized (https://github.com/rust-lang/rust/issues/52963), we should
probably use that instead.
We implement `ToSql` and `FromSql` for `time::Timespec` values. Our
documentation indicates that we store the value in the same format
used by SQLite's built-in date/time functions, but this was not
correct.
We were using the format:
%Y-%m-%d %H:%M:%S:%f %Z
This format cannot be interpreted at all by SQLite's built-in
date/time functions. There are three reasons for this:
- SQLite supports only two timezone formats: `[+-]HH:MM` and the
literal character `Z` (indicating UTC)
- SQLite does not support a space before the timezone indicator
- SQLite supports a period (`.`) between the seconds field and the
fractional seconds field, but not a colon (`:`)
SQLite does support the RFC 3339 date/time format, which is standard
in many other places. As we're always storing a UTC value, we'll
simply use a trailing `Z` to indicate the timezone, as allowed by RFC
3339. The new format is:
%Y-%m-%dT%H:%M:%S.%fZ
To avoid breaking applications using databases with values in the old
format, we'll continue to support it as a fallback for `FromSql`.
[1] https://www.sqlite.org/lang_datefunc.html
[2] https://tools.ietf.org/html/rfc3339
Recent versions of bindgen use `std::os::raw` over `libc`, but currently
`libsqlite3-sys` is overriding that. `std::os::raw` is a subset of
`libc` that exports only the relevant type definitions, but not any
functions which require additional linking. This enables
`libsqlite3-sys` to be more easily used on targets that may not have a
libc available (presumably sqlite itself would have been compiled with
musl in that case)
