You can store any big-number representation you like as TEXT or BLOB
values.  The main issue is that you'll lose syntactic sugar: SQLite3
won't be able to treat those as numeric values, therefore it won't be
able to compare numerically nor use arithmetic with such values.  You
can get some of that back with user-defined functions, but not
automatic conversions.  Just pick a decent bignum library,
canonicalize bignums before binding such values to any statements, and
add user-defined functions and collations via which to invoke the
bignum library from SQL.

To do better than this would probably require significant surgery on
SQLite3.  (Though it might not be a bad idea anyways, but who would do
it?)

If you can manage to live with integers and use those to represent
floating point values, then that's by far your best option.  (The
typical example on this list is money.  For something like U.S.
dollars you'd store numbers as integer counts of tenths of a cent, so
that $2.599 becomes 2599, allowing you to count over $9,000 trillion,
which will be enough for a while, but is already on the low side.)
For scientific, mathematical, or other purposes where you really need
huge numbers, you may want to pursue the bignum shoehorn approach.

Nico
--
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to