LSM1 vtable extension portability

Previous Topic Next Topic
 
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 https://www.sqlite.org/src/artifact/529255dc70428900, 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
extension?

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 (
https://sqlite.org/src4/doc/trunk/www/varint.wiki) different from the
SQLite3 one?
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users