SQLite

Check-in [50312273ff]
Login

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

Overview
Comment:Do not scan indexes that have the integer primary key as their left-most column. This fixes the crash of ticket [16c9801ceba] but it seems like the wrong fix. More investigation needed.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | ticket-16c9801ce
Files: files | file ages | folders
SHA1: 50312273ffaf1bd4bfdc73865fa0b19166968429
User & Date: drh 2016-05-06 11:31:10.902
Context
2016-05-06
16:06
In the WHERE generator, when building code for a DELETE operation, make sure that seeks to the main table are not deferred. This is a better fix for the [16c9801ceba49] bug than the previous. (Closed-Leaf check-in: 150dd09ebd user: drh tags: ticket-16c9801ce)
11:31
Do not scan indexes that have the integer primary key as their left-most column. This fixes the crash of ticket [16c9801ceba] but it seems like the wrong fix. More investigation needed. (check-in: 50312273ff user: drh tags: ticket-16c9801ce)
2016-05-05
11:53
Renumber internal constants in the printf() implemention for a small performance improvement. (check-in: 69d11447f4 user: drh tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Changes to src/where.c.
︙︙
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299

  pScan->pOrigWC = pWC;
  pScan->pWC = pWC;
  pScan->pIdxExpr = 0;
  if( pIdx ){
    j = iColumn;
    iColumn = pIdx->aiColumn[j];
    if( iColumn==XN_EXPR ) pScan->pIdxExpr = pIdx->aColExpr->a[j].pExpr;
    if( iColumn==pIdx->pTable->iPKey ) iColumn = XN_ROWID;
  }
  if( pIdx && iColumn>=0 ){
    pScan->idxaff = pIdx->pTable->aCol[iColumn].affinity;
    pScan->zCollName = pIdx->azColl[j];
  }else{
    pScan->idxaff = 0;
    pScan->zCollName = 0;








|








285
286
287
288
289
290
291
292
293
294
295
296
297
298
299

  pScan->pOrigWC = pWC;
  pScan->pWC = pWC;
  pScan->pIdxExpr = 0;
  if( pIdx ){
    j = iColumn;
    iColumn = pIdx->aiColumn[j];
    if( iColumn==XN_EXPR ) pScan->pIdxExpr = pIdx->aColExpr->a[j].pExpr;
    if( iColumn==pIdx->pTable->iPKey && j>0 ) iColumn = XN_ROWID;
  }
  if( pIdx && iColumn>=0 ){
    pScan->idxaff = pIdx->pTable->aCol[iColumn].affinity;
    pScan->zCollName = pIdx->azColl[j];
  }else{
    pScan->idxaff = 0;
    pScan->zCollName = 0;
︙︙
Changes to test/intpkey.test.
︙︙
610
611
612
613
614
615
616





617







618
619

do_execsql_test intpkey-16.0 {
  CREATE TABLE t16a(id "INTEGER" PRIMARY KEY AUTOINCREMENT, b [TEXT], c `INT`);
} {}
do_execsql_test intpkey-16.1 {
  PRAGMA table_info=t16a;
} {0 id INTEGER 0 {} 1 1 b TEXT 0 {} 0 2 c INT 0 {} 0}















finish_test








>
>
>
>
>
|
>
>
>
>
>
>
>



610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631

do_execsql_test intpkey-16.0 {
  CREATE TABLE t16a(id "INTEGER" PRIMARY KEY AUTOINCREMENT, b [TEXT], c `INT`);
} {}
do_execsql_test intpkey-16.1 {
  PRAGMA table_info=t16a;
} {0 id INTEGER 0 {} 1 1 b TEXT 0 {} 0 2 c INT 0 {} 0}

# 2016-05-06 ticket https://www.sqlite.org/src/tktview/16c9801ceba4923939085
# When the schema contains an index on the IPK and no other index
# and a WHERE clause on a delete uses an OR where both sides referencing
# the IPK, then it is possible that the OP_Delete will fail because there
# deferred seek of the OP_Seek is not resolved prior to reaching the OP_Delete.
#
do_execsql_test intpkey-17.0 {
  CREATE TABLE t17(x INTEGER PRIMARY KEY, y TEXT);
  INSERT INTO t17(x,y) VALUES(123,'elephant'),(248,'giraffe');
  CREATE INDEX t17x ON t17(x);
  DELETE FROM t17 WHERE x=99 OR x<130;
  SELECT * FROM t17;
} {248 giraffe}

finish_test