|12:15||• Ticket [8bf76328] NOT NULL auxiliary column in rtree table malfunctions status still Fixed with 3 other changes (artifact: 062a7b57 user: drh)|
|12:13||Ignore type affinity for auxiliary columns in RTREE as it is too error-prone to try to parse out the type from other constraints. Ticket [8bf76328ac940d52] (check-in: 7fa664ea user: drh tags: trunk)|
|11:12||• Ticket [8bf76328] NOT NULL auxiliary column in rtree table malfunctions status still Fixed with 3 other changes (artifact: 72e38425 user: mrigger)|
|09:39||• Ticket [8bf76328]: 3 changes (artifact: 4a116ea8 user: mrigger)|
|03:04||• Fixed ticket [8bf76328]. (artifact: 8dcf669c user: drh)|
|00:15||• New ticket [8bf76328]. (artifact: 8ae69a63 user: mrigger)|
|Title:||NOT NULL auxiliary column in rtree table malfunctions|
|Last Modified:||2019-12-07 12:15:01|
|Version Found In:||3.30.0|
mrigger added on 2019-12-06 00:15:58:
Consider the following example:
CREATE VIRTUAL TABLE rt0 USING rtree(c0, c1, c2, +c3 NOT NULL); INSERT INTO rt0(c3) VALUES(NULL); -- unexpected: inserting NULL succeeds
It seems that the NOT NULL constraint is neither enforced, nor rejected. This can result in incorrect results since the constraint still seems to be used for optimization:
SELECT SUM(count) FROM (SELECT 0 IN (rt0.c3) ISNULL as count FROM rt0); -- expected: 0, actual: 1
drh added on 2019-12-06 03:04:27:
Documentation enhanced here: https://www.sqlite.org/docsrc/info/c3ab325994a8f495
The expectation that "SELECT SUM(count) FROM (SELECT 0 IN (rt0.c3) ISNULL as count FROM rt0);" should return 0 is incorrect.
mrigger added on 2019-12-06 09:39:22:
Thanks for clarifying that constraints are ignored! I should have reported that the following is unexpected:
SELECT 0 in (rt0.c3) ISNULL FROM rt0; -- expected: 1, actual: 0
Only when removing the NOT NULL constraint, does the query compute TRUE.
mrigger added on 2019-12-07 11:12:51:
A follow up on this: I think that the documentation change is misleading, since it suggests that NOT NULL is currently ignored in every context. However, the updated test case above demonstrates that it actually influences the query's result. If this cannot be addressed easily, it might be an option to change "are silently ignored" to explaining that queries operating on such columns have an undefined result.
drh added on 2019-12-07 12:15:01:
Auxiliary columns now also ignore type affinity. This fixes the problem. The documentation has been suitably updated.