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
statement itself fails, rather than generating an error on the first attempted
use of the created table.
FossilOrigin-Name: 348fa7aaf7958b3fb689ed023d946064ae8d92718a497a346e95114a2410cbf5
table that has a generated column loop. Legacy allows the table to be
created but the table would not be usable for anything.
FossilOrigin-Name: 3237bf964117c1ef71143042837ef21872bb3d04bfd682075672e768953ec802
tables so that the sqlite3_context contains a valid but NULL user data pointer.
FossilOrigin-Name: 15ffd932fecc82a5791b2024f55d2ec80887e8eb7345de68d6f5cac4912cfbe8
a bad assert() in FTS3 that was found by the new xIntegrity method.
FossilOrigin-Name: 52bbf44f2d9addc2b5f68b0fe33542470852310ce3a283e2c7ff4c52831d0ed1
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
(merged to trunk at [771fe35074b50b8d]) is unsound. This check-in fixes
the issue. Had to give back a little performance, the optimization is still
a overall win.
FossilOrigin-Name: ec95e970fb737adf0fab3cb4363040b036949e5eb966fc2d030a20f95e2bde60
property of TEXT values. Avoid unnecessary copying of text values destined
to become function parameters. All changes help improve performance of
doing UPDATEs on large JSON values that are indexed multiple ways.
FossilOrigin-Name: d0278cdedfa04fb0b61838ab9622be8a2c462f58d5c3ebc4c5f802a727d0974e
string representation. Fix for
[forum:/forumpost/5c74a3bc4a|forum post 5c74a3bc4a].
FossilOrigin-Name: 3e2da8a7e35c839128d26aac575605e1e34889e8ab3484440bdd65c4d752c6bb
contains a NaN value and report that as an error.
dbsqlfuzz f144b642fe6f1a1c196f258ac6e60118a0cb59b2.
FossilOrigin-Name: 7638d9755dc90fd353b874d03ed418fa8aaee4440290ff69b1b552eae84e5baa
Problem reported by [forum:/forumpost/8cc1dc0fe9|forum post 8cc1dc0fe9].
FossilOrigin-Name: 651a13fcd16f03e89eb6228c9f3250e25910b9bbe2637f627f65ff78f8ba2059
value, because we do not know if two different strings might compare equal
even if they have different byte sequences, due to collating functions.
Formerly, the hash of a string or blob was just its length. This could
all be improved. Fix for the issue reported by
[forum:/forumpost/0846211821|forum post 0846211821].
FossilOrigin-Name: 090304b870419acb5b05205a07fc75830b556928149f76a843cda526f77a6fc0
that they reliably return SQLITE_ERROR (and not SQLITE_MISUSE) if they are
invoked on a parameter that did not have multi-value IN processing enabled
via a prior call to sqlite3_vtab_in(). See
[forum:/forumpost/a823d4a3d5f73def|forum thread a823d4a3d5f73def].
FossilOrigin-Name: 144326dc171025dc8b5a77bebd8de3c19d5244ab807f5aa41f95313a25b880bc
empty. This fixes a false-positive in the out-of-subroutine jump detection
logic added in version 3.39.0, and which was causing the assertion on the
previous check-in.
FossilOrigin-Name: 33fd9997ebb88f0d78522c036e75aef08015d31d28b1cbee08ae7c4cd5ecc6aa
is invoked with SQLITE_INTERNAL. This causes the RIGHT JOIN error
"Opcode jumps to ... which is outside the subroutine ..." to fail immediately,
causing it to come more readily to tester's attention. There is at least
one testcase in test/fuzzdata8.db that asserts due to this change.
FossilOrigin-Name: b8f994414285264f4f7c472dfad646a061fc3580b754eac0f20080c24ecc256d
