Simon Slavin wrote: > One would probably do it not by changing any existing datatype but by > introducing one or more new ones
The existing double could be repurposed. This would all depend on compatibility and other stuff - ie DRH and Jacob would be far better arbiters between them of the best approach. > No reason why sqlite3 shouldn't support REAL, INTEGER and IEEd and IEEb > types, What about people who care about complex numbers? Or those that do astronomy? And of course we all known about currency. And some people would like to be able to record any date in Earth's past and future. A case can be made for many data types even just trying to represent "numbers". > I assume one would use an existing Open C library for doing math on that new type of data, That would be considerably slower than builtin CPU instructions. You also have the issue of type conversions - eg adding one type of number to another involves conversion plus semantics (over/underflow, precision, various other pedantries). [In case it isn't clear I am referring to processors that implement the -2008 flavoured instructions in addition to -1985 ones.] > to save time developing one's own, and to ensure compatibility with other apps. Surely you mean compatibility with the standard :-) I wouldn't expect SQLite to contain a home made library for this stuff, but there certainly would have to be conditional code for choosing between CPU instructions and emulating them plus various type conversions when the operands don't have matching types. > But I can see the point in commonly used standards like that. XML is a commonly used standard - how about that in SQLite. Kidding :-) Adding new types to SQLite is hard as it affects so much code. Other databases do support adding your own types - maybe this is one area you get to pick "Lite" or "heavy". Roger _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
