> > SQLite3 Decimal is an extension implementing exact decimal arithmetic > > for SQLite3. It is currently unfinished and under development. > > > I'm curious, what was your motivation for doing this? > Use cases envisioned for its use?
Mainly financial applications. Beancount’s author (http://furius.ca/beancount/) has a series of documents arguing convincingly about the need for a library like this. > > Decimals are stored as blobs and the storage format is a minor variant > > of decimalInfinite (https://arxiv.org/abs/1506.01598). > > Does it use some kind of magic cookie? No. > How can you distinguish your encoding from an arbitrary blob? I don't. In fact, you may pass any blob, but if it doesn’t have the right format, it results in a decoding error (which, currently, may not be very well tolerated by the library-I have to check that). > Unfortunately, SQLite does not support UDTs, but it did grow in recent > months > the https://www.sqlite.org/c3ref/value_subtype.html API, which plays a > poor-man's > substitute when call chaining. Thanks, I didn’t know about subtypes. I’ll read about them, although, at a quick glance, I am not sure how they might be used to enforce type checking in my case. > That OTOH has no influence on how the value will be *stored in tables*, > unfortunately, so you cannot have alternate representation of the value, > one optimized for storage, another for processing (in call chains), so maybe > it's all moot, mentioning this. > > That is a totally > > ordered encoding, so decimals can be compared directly (memcmp()) and > > also indexed (does SQLite support indexes on blobs?). > > > > Yes it does. Great! > > As I have said, I welcome any feedback, from the super-technical to the > > end-user oriented. There is no manual so far, but the code is mostly > > documented. You may find a sample session in the repository's home page. > > > > From an End-User POV, the call-chained-functions are "heavy looking”. Yes, I agree. Keep in mind that the current interface is most likely bound to be changed. > So maybe a printf-like API that parses a now-looking math expression > and replaces its placeholders with the var-arg supplied arguments to the > function > would make the "SQL" much more readable. > > Since you cannot extend the regular arithmetic expressions in SQLite to act > on your UDTs > differently than the built-in processing, that would be the next best thing > IMHO. I will think about that! > All in all, it looks very well done. You're obviously a very competent > programmer IMHO :). It looks so, because I stand on the shoulder of giants ;) > Thanks, --DD > > PS: Seems like you're using non-ascii chars in your source code, notably > the #pragma mark. > That's pretty, but asking for trouble IMHO, and likely to cause issues > for cross-platform support. Yes, that and a few other things need to be polished. My initial idea was to keep this project for myself, so I took a liberal approach style-wise. But it has grown more than I expected... Thanks for the feedback, Life. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
