module has disconnected.
[forum:/forumpost/b68391eb71fdff73|Forum post b68391eb71fdff73].
FossilOrigin-Name: 1ab122289fe6ac4cb3b0c47d17ac22627fcdfed80c941a57e6e6cc4d9dbd9273
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
[forum:forumpost/e3f72e9291189925|Forum post e3f72e9291189925]. The code
was legal and correct. The revised code is actually less clear in its intent.
But at least now there will (hopefully) be no warning.
FossilOrigin-Name: 48bb7c88787bf5de1d70cf3cc81ada38c6c02e476dbdff12c8676c6d5ee19aed
just read transactions if the operation is read-only and the
SQLITE_MAX_ATTACHED macro is set to 31 or more. This was due to a misuse
of the writeMask field of Parse, pointed out by
[forum:/forumpost/aa173c18d5|forum post aa173c18d5].
FossilOrigin-Name: 8760566893b64325874c7ec0aff8014026ce525e7fff1489027d2ce698495e76
iColumn field is set correctly, as otherwise the "IS NULL" operator might
be incorrectly optimized. Fix for the problem described by
[forum:/forumpost/d010a26798915b53|forum post d010a26798915b53].
FossilOrigin-Name: 0819a1869a39d54a405259ea323365506a182962a02affdef16a03446005da64
N-th call to sqlite3ProgressCheck(), where N is the progress handler step
count. Also fix faulty asserts exposed by the ability to interrupt in the
middle of sqlite3_prepare().
FossilOrigin-Name: 05461651599bb490ac6cfd893645dabab9cccedc6adcce15aee2487b2ea6027a
statement preparation by invoking the progress handler at strategic points
during sqlite3_parpare(). This experiment shows that sqlite3_prepare() might
leave the resulting prepared statement uninitialized following an interrupt.
FossilOrigin-Name: 79636f2d80aee70832913a78933da2a7e30cc037810b93903ebbc1925ea93fef
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
app-defined functions and similar to see if they need to exit early due to
an sqlite3_interrupt() call.
FossilOrigin-Name: d030f341369b7f32789cbcf3d0ad9a2ac5cad99a56dac7dfe68b7f06dc339b17
as the underlying table if such is available and is consistent with
the computed affinity of the column.
[forum:/forumpost/7fb1fe9dcf310ef5|Forum thread 7fb1fe9dcf310ef5].
FossilOrigin-Name: 497a98363fd1ed079544620ec5d0883f987ed03013131542741c93d7568e8568
stored in indexes are byte-for-byte identical to the values in the table, and
not just equivalent according to the collating sequence.
dbsqlfuzz 686e2e205e0c0594d3fb524bea0c25e621d1a870.
FossilOrigin-Name: 9302e4bfdce5905576b8f0af7d6b3a864e1dcd58ed89bb303010a1c4f826e915
drh