SQLite

Check-in [c9f0b9cb]
Login

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

Overview
Comment:Make a deep copy of the result of a subquery in case the subquery is reused. Fix for the problem reported by forum post 28216b36ac and introduced by check-in [f30fb19ff763a7cb]. Further changes to try to optimize the new OP_Copy opcode back into either OP_SCopy or OP_Move will be attempted separately. A test case will be in TH3.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: c9f0b9cb0aef107265435e22c164dd3c974eadfd00abf7cfd4fc7ec95c0dd7d0
User & Date: drh 2021-05-28 12:48:31
Context
2021-05-29
21:50
Fix a subtle error in an assert(). dbsqlfuzz eefbd0215c0c1b4bcc32b8141b48b35f7b431300 (check-in: a5ec81eb user: drh tags: trunk)
2021-05-28
14:28
If a subquery is used to drive an index, this change avoids making an extra copy of the result of that subquery. But, such situations are probably sufficiently unusual that the added complexity of this enhancement is not worth the performance gain. So I'm going to park this check-in on a branch. If we later find a use case to justify it, we can merge it to trunk then. This is the "further change" that was promised by the prior check-in comment. (Leaf check-in: 4488cb88 user: drh tags: copy-optimization)
12:48
Make a deep copy of the result of a subquery in case the subquery is reused. Fix for the problem reported by forum post 28216b36ac and introduced by check-in [f30fb19ff763a7cb]. Further changes to try to optimize the new OP_Copy opcode back into either OP_SCopy or OP_Move will be attempted separately. A test case will be in TH3. (check-in: c9f0b9cb user: drh tags: trunk)
12:15
Fix a potential memory leak in json_group_object() following an error. dbsqlfuzz cd32630de3ff039d97089592b63cb3616f8ec9dd (check-in: 21676731 user: drh tags: trunk)
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to src/wherecode.c.

︙︙
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766

    testcase( pTerm->wtFlags & TERM_VIRTUAL );
    r1 = codeEqualityTerm(pParse, pTerm, pLevel, j, bRev, regBase+j);
    if( r1!=regBase+j ){
      if( nReg==1 ){
        sqlite3ReleaseTempReg(pParse, regBase);
        regBase = r1;
      }else{
        sqlite3VdbeAddOp2(v, OP_SCopy, r1, regBase+j);
      }
    }
    if( pTerm->eOperator & WO_IN ){
      if( pTerm->pExpr->flags & EP_xIsSelect ){
        /* No affinity ever needs to be (or should be) applied to a value
        ** from the RHS of an "? IN (SELECT ...)" expression. The 
        ** sqlite3FindInIndex() routine has already ensured that the 








|








752
753
754
755
756
757
758
759
760
761
762
763
764
765
766

    testcase( pTerm->wtFlags & TERM_VIRTUAL );
    r1 = codeEqualityTerm(pParse, pTerm, pLevel, j, bRev, regBase+j);
    if( r1!=regBase+j ){
      if( nReg==1 ){
        sqlite3ReleaseTempReg(pParse, regBase);
        regBase = r1;
      }else{
        sqlite3VdbeAddOp2(v, OP_Copy, r1, regBase+j);
      }
    }
    if( pTerm->eOperator & WO_IN ){
      if( pTerm->pExpr->flags & EP_xIsSelect ){
        /* No affinity ever needs to be (or should be) applied to a value
        ** from the RHS of an "? IN (SELECT ...)" expression. The 
        ** sqlite3FindInIndex() routine has already ensured that the
︙︙