available for testing. The test cases work on all other 64-bit and 32-bit
platforms that we have at hand. So there is no way for us to debug this
problem. Better to disable the test.
[forum:/forumpost/ffcbf789b5386573|forum post ffcbf789b5386573].
FossilOrigin-Name: fed4d6e90baecca716429f95e1fab7930297afa2a191a87a0a87cb93910d1bce
parameters that provide the name of the table being checked and
a flag to indicate a "quick_check". Based on feedback in
[forum:/forumpost/965c0d02ea|forum post 965c0d02ea].
FossilOrigin-Name: bc8afa3f15954bb35f65dbf940bf069de5e14d333036676c24430cf17b658d05
faster, at the expense of having a slightly less dense and hence larger index
(example: 33 entries/node versus 34 entries/node).
FossilOrigin-Name: b3049a1d3dbdd63c471499c2f6b417655defe9ad90228e7cc722f5be877aae01
of a node looking for solutions that involve no cell enlargement. Only look
for the minimum cell enlargement if the enlargement is non-zero for all cells.
This results in a performance improvement by reducing the number of calls
to cellUnion().
FossilOrigin-Name: 59f0e239d19393190911ea3bd89b5a24be0d85d64ccf51906efc9537ad5d7298
an integer error code and writes the error message into a parameter.
FossilOrigin-Name: f1d4024a8ca06cf954aaf1f612684d1a5d28492bde757695db3f22c50c649709
method in RTREE, FTS3/4, and FTS5 so that "PRAGMA integrity_check" also
verifies the correctness of shadow tables associated with those virtual
tables.
FossilOrigin-Name: 17bede8cdefd968210dd8a5a2617acbe12ba2c99fdd5e88c5def8665e7bec2d7
integers that are too big to be represented exactly by a float - then take
extra steps to ensure that all possibly relevant entries in the RTREE are
returned, even in boundary cases. Fix for the problem identified by
[forum:/forumpost/da70ee0d0d|forum post da70ee0d0d].
FossilOrigin-Name: bfd8d9100015f3e3fb011698963d670bd89b64ec8a8ab931e0c6c3076b029377
values are duplicated in the byte-code so that the comparisons are done
using 64-bit floats and consistent results are always obtained.
[forum:/forumpost/da61c4a1b5b4af19|Forum post da61c4a1b5b4af19].
FossilOrigin-Name: 4ec0f0a31b0df93ad15545fe1db117c933e28c75ad3cbc8475b56fecdb084905
extension so that it is aligned with the latest enhancements in the core.
FossilOrigin-Name: 122431d3a7267ec83768316ab146c0557fb6c0577a4a47ac6ed3d7aa6811ca9a
number of updated columns does not exceed the underlying implementation, even
if the virtual table object records an excess number of column in the nAux
field due to table constraints in the table definition.
Fix for the problem reported by
[forum:/forumpost/a096ab7d96bb057a|forum post a096ab7d96bb057a].
FossilOrigin-Name: a04dd475c2c8afdded0afecfd34c6c4c2f48cce520e09b7fa5172ff30f09209e
RIGHT or LEFT join anywhere in the query. Other RDBMSes prohibit this always,
but SQLite must allow ON clauses to reference tables to their right for legacy
compatibility, unless there is a RIGHT or LEFT join someplace in the query,
in which case there is no legacy to support.
FossilOrigin-Name: e615dbe02ca949252d1526ed5c48f8ce08159773ea2008ce666484379d0d9854
[forum:/forumpost/57bdf2217d|forum post 57bdf2217d]. This check-in
should complete the fix.
FossilOrigin-Name: fb0a23b6789da8e934562ce9ebd9d58ea13a10fd10dee5cbfc7ac8f394e1aeec
error was in test logic only, not in the SQLite library itself.
[forum:/forumpost/35470a0a72a005e1|forum post 35470a0a72a005e1]
FossilOrigin-Name: 7e3c9594390ac8defaf9825e14b4c19ef8c123b747971dd3d4df16110f443d3b
Add the -DSQLITE_OMIT_AUXILIARY_SAFETY_CHECKS compile-time option to cause
ALWAYS() and NEVER() macros to be omitted from the build.
FossilOrigin-Name: 1c67f957fc77e37ce8f0d447c41ca975e8e79a35d332739c24a633649b5b0387
