On 21 Dec 2009, at 1:09am, Roger Binns wrote: > Not only do you need the type but every arithmetic operation would also need > to be updated. It will be even more fun if you also want to support the > - -1985 representations (eg normal SQLite database format) since you'll have > both semantics in the same program at the same time. Are you going to be > using a CPU that has native -2008 instructions?
One would probably do it not by changing any existing datatype but by introducing one or more new ones (yes, I have an idea how much work this would take). No reason why sqlite3 shouldn't support REAL, INTEGER and IEEd and IEEb types, besides bloat. I assume one would use an existing Open C library for doing math on that new type of data, to save time developing one's own, and to ensure compatibility with other apps. As for how these numbers are stored in the database file, I suspect one would just straight to b128 and d128. People who didn't want to waste 128 bits could use REAL and INTEGER as before. There are certain things I don't want to see in SQLite3 (not that anyone cares what I want). Users & privilages, for instance. But I can see the point in commonly used standards like that. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
