On 22 Aug 2018, at 6:04pm, Jens Alfke <j...@mooseyard.com> wrote: > Bignums make unsigned types irrelevant, if the only reason you need unsigned > is to store 64-bit positive integers. As others have said, "unsigned" is a > constraint, not a type.
Agreed. > Bignums would be nice; but you could implement them yourself by storing them > as blobs and defining functions to operate on them, which would call into > some available C bignum library. What seems to be needed here is not BIGNUM but would better be called BIGINT. However, IMHO SQLite should not complicate itself by incorporating a new datatype. That would lead to a lot of extra CAST() programming and testing. Instead it should expand the capabilities of the existing INTEGER type. Looking at section 2.1 of <https://www.sqlite.org/datatype3.html> suggests using a new Serial Type code of, for the sake of argument, 10 to mean "Value is a big-endian 128-bit twos-complement integer.". This would create schema format 5, and introduce a possible compatibility problem if a database with a big integer was presented to an earlier version of SQLite. But I think it would represent the minimum of backward compatibility problems. But I haven't read the source code so I don't know for sure. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
