On 4 Apr 2019, at 10:12pm, Lifepillar <lifepil...@icloud.com> wrote: > This is essentially a pragmatic choice, as the semantics of NULLs is > unspecified and ambiguous.
The way SQL handles NULLs may sometimes appear inconsistent, but is the result of SQL handling rows as sets. Some of the behaviour is, carefully designed, with the knowledge that the NULL that results from one step of an expression is going to be fed into the next step of the expression. For those purposes, NULL means one of two things: "no value" or "value unknown". For instance, the sum of a result which includes a NULL value is NULL. But the sum of a result with zero rows is not NULL, it's zero. For the purposes of a decimal extension to SQLite, I would imitate what SQLite3 does with REAL values. If you have a question about how SQLite sees NULL it might be answered here: <https://sqlite.org/nulls.html> It's especially important that the test script at the end of that page, behaves the same if you run it as is, and if you substitute the 'int' type with your decimal type. If you have any questions, please don't hesitate to ask. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
