LSM1 vtable extension portability

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

LSM1 vtable extension portability

Dominique Devienne
I'm reading, and
stumbled on:

** For FLOAT values, the content is the IEEE754 floating point value in
** native byte-order.  This means that FLOAT values will be corrupted when
** database file is moved between big-endian and little-endian machines.

And my immediate reaction is why? SQLite DBs are portable themselves.
Why make the decision to break that portability when using the LSM1

I strongly suspect SQLite4, which also uses LSM, uses a portable encoding
for row data (the contrary would be extremely surprising), so why go for
non-portability on that one datatype, instead of 1) encoding the endianness
in the type,
or 2) forcing a given endianness, or 3) using varints to encode the
mantissa and exponent,
therefore providing the platform portability?

Thanks, --DD

PS: typo: varaible-length

PPS: Is the SQLite4 varint encoding ( different from the
SQLite3 one?
sqlite-users mailing list
[hidden email]