If you wanted to store it as purple tree smoke signals you could do that too. However, the fact of the matter is that SQLite3 does not perform conversions to and from purple tree smoke signals, and the OP was not trying to store the value as a "hex or decimal representation of the number", or as a blob, or anything else. He was trying to store it as a signed integer. And it was clearly too large a magnitude for a signed integer. Of the numeric formats available that it could be stored as in the current version of SQLite3, that leaves an IEEE-754 binary64 as the only other option. Thus that is what was done.
--- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: sqlite-users [mailto:sqlite-users- >boun...@mailinglists.sqlite.org] On Behalf Of Nathan Wagner >Sent: Thursday, 27 September, 2018 11:50 >To: SQLite mailing list >Subject: Re: [sqlite] storing unsigned 64 bit values > >On Thu, Sep 27, 2018 at 11:05:24AM -0600, Keith Medcalf wrote: > >> so the only way to store something [larger than a signed 64-bit >int] >> is as a double-precision float. > >I'd like to point out that you could *store* it as the hex or decimal >text representation of the integer. If you included leading zeros, >it >would even sort correctly. If you actually need to do arithmetic on >it >within sqlite, that's another matter. > >(Or any non-weird base representation, for that matter.) > >-- >nw >_______________________________________________ >sqlite-users mailing list >sqlite-users@mailinglists.sqlite.org >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
