SQLite

Timeline
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

28 events for the month beginning 2024-05-01 by user drh

2024-05-20
19:59
Omit a capi3 test from 2007 that depends upon undefined behavior (UAF). (Leaf check-in: a60a0b75 user: drh tags: trunk)
17:52
Improvements to the documentation of sqlite3_vtab_distinct(). Do not allow sqlite3_vtab_distinct() to return 2 or 3 if the rowid column of the virtual table is used, as doing so might lead to an incorrect answer. (check-in: 08058d66 user: drh tags: trunk)
16:00
Improvements to the sqlite3_vtab_distinct() documentation. (Closed-Leaf check-in: 6ee041d3 user: drh tags: vtab-distinct-fix)
2024-05-18
20:00
Fix the definition of sqlite3_vtab_distinct() such that return codes 2 and 3 mean that all rows must be distinct over "colUsed" which is a superset of "aOrderBy". Also, disallow return codes 2 and 3 if the rowid of the virtual table is accessed. (check-in: 922731ce user: drh tags: vtab-distinct-fix)
2024-05-17
22:51
Improvements to a VDBE comment. No changes to anything that affects queries. (check-in: c2188da8 user: drh tags: trunk)
2024-05-16
15:57
The sqlite3_declare_vtab() interface should return SQLITE_ERROR, not SQLITE_MISUSE when a nonsense SQL input is provided, for legacy compatibility. Forum post 4b875d7b2a. (check-in: 1ec2961a user: drh tags: trunk)
00:20
Fix a case where an error in the ORDER BY clause of an aggregate function that is part of a trigger body might cause an assert() to fail in an ALTER TABLE command. dbsqlfuzz 899d9255555a07f1fe11a0bb51a2fe197b3150cd (check-in: 953271f2 user: drh tags: trunk)
2024-05-15
23:36
Back out the assert() fixes from [a9443dbfbe25e588] and [3afaeac56dff58db] (but keep the corresponding test cases) because they are both made obsolete by the previous fix on this branch. (Closed-Leaf check-in: 3120c7c8 user: drh tags: alter-table-fix)
2024-05-12
00:26
Optimization in the implementation of OP_OpenRead and OP_OpenWrite (Closed-Leaf check-in: 3a256a16 user: drh tags: faster-openread)
2024-05-10
18:24
Fix aggregate function processing to correctly deal with OOMs inside of sqlite3ParserAddCleanup(). (dbsqlfuzz b2d11ca70e55ee8bde48ae0b53fa3e9355812f95). Also add improved testing support by causing sqlite3FaultSim(300) to simulate an OOM inside of sqlite3ParserAddCleanup() and by adding improved fault-sim support to the CLI. (check-in: c6fd70b3 user: drh tags: trunk)
18:10
The sqlite3FaultSim(300) error from [1e8863909ac369e5] must be treated as an OOM, since it simulates an OOM. Also fix deferred deletion of Expr objects from [a53bdd311c4154fd] so that it does not corrupt the AST if an OOM occurs. (check-in: c623d9a5 user: drh tags: cleanup-testing)
17:05
Improvements to the ".testctrl fault_install" command in the CLI. (check-in: 48b34ded user: drh tags: cleanup-testing)
16:28
Add an sqlite3FaultSim(300) call to the sqlite3ParserAddCleanup() routine for more precise simulation of OOM errors in that routine. (check-in: 1e886390 user: drh tags: cleanup-testing)
2024-05-08
17:42
Allow arbitrary expressions as the second argument to RAISE(). (Closed-Leaf check-in: 003e1c8c user: drh tags: enhanced-raise)
11:51
Fix a hyperlink typo in session documentation. (check-in: 42d67c6f user: drh tags: trunk)
2024-05-06
20:18
Omit redundant unary + operators from the AST. (check-in: f81cc149 user: drh tags: trunk)
19:04
Avoid unnecessary recursion in sqlite3ExprDeleteNN(). This complicates the code, but it is needed to prevent nuisance "stack overflow" reports from OSSFuzz while it is running the latest ASAN. (check-in: 70abc144 user: drh tags: trunk)
2024-05-05
10:00
Add comment to the test/lemon-test01.y file indicating that it does not work and is for historical reference only. (check-in: 9bdf73a8 user: drh tags: trunk)
2024-05-04
15:10
Assume that an SQL function is able to return a subtype if any of its arguments are SQL functions that are able to return subtypes. This closes a corner-case hole in the patch at [ba789a7804ab96d8]. (check-in: b36d499e user: drh tags: trunk)
15:06 Edit [cdd1610c44876623|cdd1610c]: Edit check-in comment. (artifact: 5f0a651e user: drh)
15:04
Assume that a function is able to return a subtype if either (1) it is itself marked with SQLITE_RESULT_SUBTYPE, or (2) one of its arguments is a function that is able to return a subtype. This check-in backs out the code changes from the previous two on this same branch, but keeps the test cases from the previous two. (Closed-Leaf check-in: f16b200f user: drh tags: func-rw-subtype)
14:56 Edit [cdd1610c44876623|cdd1610c]: Move to branch func-rw-subtype. (artifact: ba0d1d65 user: drh)
11:31
Functions that pass through the sqlite3_value of one of their arguments must also be marked as SQLITE_RESULT_SUBTYPE, in case one of their arguments has a subtype. (check-in: 2f9fba93 user: drh tags: func-rw-subtype)
2024-05-03
19:35
The coalesce(), ifnull(), and iif() functions pass through subtype values from their arguments, and hence need to have the SQLITE_RESULT_SUBTYPE flag set. (check-in: cdd1610c user: drh tags: func-rw-subtype)
2024-05-02
12:14
Fix the CREATE TABLE performance issue described by forum thread 4cf69794d9dfff7c in two different ways: (1) Omit the call to PRAGMA integrity_check('X') that was being done after CREATE TABLE "X" because the result was being ignored and the integrity_check was not doing anything other than burning CPU cycles. (2) Do not interpret the argument to PRAGMA integrity_check as a number if it is in fact a string that looks like a number. (check-in: 71f08b91 user: drh tags: trunk)
12:00
Add a test case to the fix to PRAGMA integrity_check in the previous check-in. (Closed-Leaf check-in: 39a57b59 user: drh tags: faster-create)
11:52
Do not accept a string that looks like a number used as an argument to PRAGMA integrity_check as a number. Treat it as a table name that just happens to look like a number. (check-in: b04e7a23 user: drh tags: faster-create)
11:51
Omit the OP_SqlExec to "PRAGMA integrity_check" added by [348fa7aaf7958b3f] because it is a no-op. Even if the integrity_check failes, the CREATE TABLE is stull successful. The OP_SqlExec just burns CPU cycles for no reason. (check-in: 532795ac user: drh tags: faster-create)
Previous month ↓