For no especially good reason, I decided to turn off all SQLite features I?m not using now and which I have no plans to use in the future.
My current DB doesn?t use any FP columns, so I rebuild SQLite with SQLITE_OMIT_FLOATING_POINT and ran ran into a bunch of breakage: 1. The (double) cast on line 66942 of the current amalgamation in valueFromExpr() produces a warning. Most of that block probably should go away if FP is disabled. 2. Similar problem on 138811 in FTS3: the cost estimator uses FP. 3. Setting this implicitly defines SQLITE_OMIT_TRACE, which removes sqlite3_profile(), even though that interface doesn?t use FP. I didn?t look deeply into it, but apparently it does use FP internally. At minimum, this should be documented. It would be better if SQLite decoupled the two reasons to disable FP: a. My processor has no FPU, so I don?t want *any* FP code in sqlite3.o; and b. I don?t use FP in my DB, so I want to disable REAL and related things, but it?s fine if SQLite uses it internally. (Profiling, FTS3, etc.) It?s actually the latter I was expecting when I set this build option. 4. If the current all-or-nothing approach to FP continues, setting this should probably implicitly set SQLITE_RTREE_INT_ONLY. Currently, you get a complaint due to use of double on lines and 156404 and 158887 of the current amalgamation. 5. #4 happens whether you have SQLITE_ENABLE_RTREE defined or not. I couldn?t work out why, but this tells me the r*tree code is being compiled in despite being unasked-for.
