if( doMakeRec ){
    const char *zAff;
    if( pTab->pSelect || (pParse->db->flags & SQLITE_IdxRealAsInt)!=0 ){
      zAff = 0;
    }else{
      zAff = sqlite4IndexAffinityStr(v, pIdx);
    }
    sqlite4VdbeAddOp1(v, OP_MakeKey, iIdxCur);
    sqlite4VdbeAddOp3(v, OP_MakeRecord, regBase, nCol+1, regOut);
    sqlite4VdbeChangeP4(v, -1, zAff, P4_TRANSIENT);
  }
  sqlite4ReleaseTempRange(pParse, regBase, nCol+1);
  return regBase;
}

  if( doMakeRec ){
    const char *zAff;
    if( pTab->pSelect || (pParse->db->flags & SQLITE_IdxRealAsInt)!=0 ){
      zAff = 0;
    }else{
      zAff = sqlite4IndexAffinityStr(v, pIdx);
    }
    sqlite4VdbeAddOp2(v, OP_MakeKey, iIdxCur, regOut+1);
    sqlite4VdbeAddOp3(v, OP_MakeRecord, regBase, nCol+1, regOut);
    sqlite4VdbeChangeP4(v, -1, zAff, P4_TRANSIENT);
  }
  sqlite4ReleaseTempRange(pParse, regBase, nCol+1);
  return regBase;
}

**
*************************************************************************
**
** This header file defines the interface to the KV storage engine(s).
**
** Notes on the storage subsystem interface:
** 
** The storage subsystem is a key/value store.  All keys and values are
** binary with arbitrary content.  Keys are unique.  Keys compare in
** memcmp() order.  Shorter keys appear first.
** 
** The xBegin, xCommit, and xRollback methods change the transaction level
** of the store.  The transaction level is a non-negative integer that is
** initialized to zero.  The transaction level must be at least 1 in order
** for content to be read.  The transaction level must be at least 2 for 
** content to be modified.
** 
** The xBegin method increases transaction level.  The increase may be no
** more than 1 unless the transaction level is initially 0 in which case
** it can be increased immediately to 2.  Increasing the transaction level
** to 1 or more makes a "snapshot" of the complete store such that changes
** made by other connections are not visible.  An xBegin call may fail
** with SQLITE_BUSY if the initial transaction level is 0 or 1.
** 
** A read-only store will fail an attempt to increase xBegin above 1.  An
** implementation that does not support nested transactions will fail any
** attempt to increase the transaction level above 2.
** 
** The xCommitPhaseOne and xCommitPhaseTwo methods implementat a 2-phase
** commit that lowers the transaction level to the value given in the
** second argument, and makes all the changes made at higher transaction levels
** permanent.  A rollback is still possible following phase one.  If
** possible, errors should be reported during phase one so that a
** multiple-database transaction can still be rolled back if the
** phase one fails on a different database.  Implementations that do not
** support two-phase commit can implement xCommitPhaseOne as a no-op function
** returning SQLITE_OK.
** 
................................................................................
** its argument and reverts or undoes all changes made at higher transaction
** levels.  An xRollback to level N causes the database to revert to the state
** it was in on the most recent xBegin to level N+1.
** 
** The xRevert(N) method causes the state of the database file to go back
** to what it was immediately after the most recent xCommit(N).  Higher-level
** subtransactions are cancelled.  This call is equivalent to xRollback(N-1)
** followed by xBegin(N) but might be more efficient.
** 
** The xReplace method replaces the value for an existing entry with the
** given key, or creates a new entry with the given key and value if no
** prior entry exists with the given key.  The key and value pointers passed
** into xReplace will likely be destroyed when the call to xReplace returns
** so the xReplace routine must make its own copy of that information.
** 
** The xDelete method delets an existing entry with the given key.  If no
** such entry exists, xDelete is a no-op.
** 
** A cursor is at all times pointing to ether an entry in the store or
** to EOF.  EOF means "no entry".  Cursor operations other than xCloseCursor 
** will fail if the transaction level is less than 1.
** 
** The xSeek method moves a cursor to a point in the store that matches
** the supplied key as closely as possible.  If the dir argument is 0, then
** the match must be exact or else the seek fails and the cursor is left
** pointing to EOF.  If dir is negative, then an exact match is
** found if it is available, otherwise the cursor is positioned at the largest
** entry that is less than the search key or to EOF if the store contains no
** entry less than the search key.  If dir is positive, then an exist match
** is found if it is available, otherwise the cursor is left pointing the
** the smallest entry that is larger than the search key, or to EOF if there
** are no entries larger than the search key.
**
** The xSeek return code might be one of the following:
**
**    SQLITE_OK        The cursor is left pointing to any entry that
**                     exactly matchings the probe key.
**
**    SQLITE_INEXACT   The cursor is left pointing to the nearest entry
**                     to the probe it could find, either before or after
**                     the probe, according to the dir argument.
**
**    SQLITE_NOTFOUND  No suitable entry could be found.  Either dir==0 and
**                     there was no exact match, or dir<0 and the probe is
**                     smaller than every entry in the database, or dir>0 and
**                     the probe is larger than every entry in the database.
** 



** The xNext method may only be used following an xSeek with a positive dir,
** or another xNext.  The xPrev method may only be used following an xSeek with
** a negative dir or another xPrev.



** 
** Values returned by xKey and xData are guaranteed to remain stable until
** the next xSeek, xNext, xPrev, xReset, or xCloseCursor on the same cursor.  
** This is true even if the transaction level is reduced to zero, or if the
** content of the entry is changed by xInsert, xDelete, or xRollback.  The
** content returned by repeated calls to xKey and xData is allowed (but is not
** required) to change if xInsert, xDelete, or xRollback are invoked in between
** the calls, but the content returned by every call must be stable until 
** the cursor moves, or is reset or closed.


** 



** It is acceptable to xDelete an entry out from under a cursor.  Subsequent
** xNext or xPrev calls on that cursor will work the same as if the entry
** had not been deleted.



*/

/* Typedefs of datatypes */
typedef struct KVStore KVStore;
typedef struct KVStoreMethods KVStoreMethods;
typedef struct KVCursor KVCursor;
typedef unsigned char KVByteArray;

**
*************************************************************************
**
** This header file defines the interface to the KV storage engine(s).
**
** Notes on the storage subsystem interface:
** 
** The storage subsystem is a key/value database.  All keys and values are
** binary with arbitrary content.  Keys are unique.  Keys compare in
** memcmp() order.  Shorter keys appear first.
** 
** The xBegin, xCommit, and xRollback methods change the transaction level
** of the store.  The transaction level is a non-negative integer that is
** initialized to zero.  The transaction level must be at least 1 in order
** for content to be read.  The transaction level must be at least 2 for 
** content to be modified.
** 
** The xBegin method increases transaction level.  The increase may be no
** more than 1 unless the transaction level is initially 0 in which case
** it can be increased immediately to 2.  Increasing the transaction level
** to 1 or more makes a "snapshot" of the database file such that changes
** made by other connections are not visible.  An xBegin call may fail
** with SQLITE_BUSY if the initial transaction level is 0 or 1.
** 
** A read-only database will fail an attempt to increase xBegin above 1.  An
** implementation that does not support nested transactions will fail any
** attempt to increase the transaction level above 2.
** 
** The xCommitPhaseOne and xCommitPhaseTwo methods implement a 2-phase
** commit that lowers the transaction level to the value given in the
** second argument, making all the changes made at higher transaction levels
** permanent.  A rollback is still possible following phase one.  If
** possible, errors should be reported during phase one so that a
** multiple-database transaction can still be rolled back if the
** phase one fails on a different database.  Implementations that do not
** support two-phase commit can implement xCommitPhaseOne as a no-op function
** returning SQLITE_OK.
** 
................................................................................
** its argument and reverts or undoes all changes made at higher transaction
** levels.  An xRollback to level N causes the database to revert to the state
** it was in on the most recent xBegin to level N+1.
** 
** The xRevert(N) method causes the state of the database file to go back
** to what it was immediately after the most recent xCommit(N).  Higher-level
** subtransactions are cancelled.  This call is equivalent to xRollback(N-1)
** followed by xBegin(N) but is atomic and might be more efficient.
** 
** The xReplace method replaces the value for an existing entry with the
** given key, or creates a new entry with the given key and value if no
** prior entry exists with the given key.  The key and value pointers passed
** into xReplace belong to the caller will likely be destroyed when the
** call to xReplace returns so the xReplace routine must make its own
** copy of that information.


** 
** A cursor is at all times pointing to ether an entry in the database or
** to EOF.  EOF means "no entry".  Cursor operations other than xCloseCursor 
** will fail if the transaction level is less than 1.
** 
** The xSeek method moves a cursor to an entry in the database that matches
** the supplied key as closely as possible.  If the dir argument is 0, then
** the match must be exact or else the seek fails and the cursor is left
** pointing to EOF.  If dir is negative, then an exact match is
** found if it is available, otherwise the cursor is positioned at the largest
** entry that is less than the search key or to EOF if the store contains no
** entry less than the search key.  If dir is positive, then an exist match
** is found if it is available, otherwise the cursor is left pointing the
** the smallest entry that is larger than the search key, or to EOF if there
** are no entries larger than the search key.
**
** The return code from xSeek might be one of the following:
**
**    SQLITE_OK        The cursor is left pointing to any entry that
**                     exactly matchings the probe key.
**
**    SQLITE_INEXACT   The cursor is left pointing to the nearest entry
**                     to the probe it could find, either before or after
**                     the probe, according to the dir argument.
**
**    SQLITE_NOTFOUND  No suitable entry could be found.  Either dir==0 and
**                     there was no exact match, or dir<0 and the probe is
**                     smaller than every entry in the database, or dir>0 and
**                     the probe is larger than every entry in the database.
**
** xSeek might also return some error code like SQLITE_IOERR or
** SQLITE_NOMEM.
** 
** The xNext method will only be called following an xSeek with a positive dir,
** or another xNext.  The xPrev method will only be called following an xSeek
** with a negative dir or another xPrev.  Both xNext and xPrev will return
** SQLITE_OK on success and SQLITE_NOTFOUND if they run off the end of the
** database.  Both routines might also return error codes such as
** SQLITE_IOERR, SQLITE_CORRUPT, or SQLITE_NOMEM.
** 
** Values returned by xKey and xData are guaranteed to remain stable until
** the next xSeek, xNext, xPrev, xReset, xDelete, or xCloseCursor on the same
** cursor.  This is true even if the transaction level is reduced to zero,
** or if the content of the entry is changed by xInsert, xDelete on a different
** cursor, or xRollback.  The content returned by repeated calls to xKey and
** xData is allowed (but is not required) to change if xInsert, xDelete, or
** xRollback are invoked in between the calls, but the content returned by
** every call must be stable until the cursor moves, or is reset or closed.
** The cursor owns the values returned by xKey and xData and will take
** responsiblity for freeing memory used to hold those values when appropriate.
** 
** The xDelete method deletes the entry that the cursor is currently
** pointing at.  However, subsequent xNext or xPrev calls behave as if the
** entries is not actually deleted until the cursor moves.  In other words
** it is acceptable to xDelete an entry out from under a cursor.  Subsequent
** xNext or xPrev calls on that cursor will work the same as if the entry
** had not been deleted.  Two cursors can be pointing to the same entry and
** one cursor can xDelete and the other cursor is expected to continue
** functioning normally, including responding correctly to subsequent
** xNext and xPrev calls.
*/

/* Typedefs of datatypes */
typedef struct KVStore KVStore;
typedef struct KVStoreMethods KVStoreMethods;
typedef struct KVCursor KVCursor;
typedef unsigned char KVByteArray;

    pKeyOut = &aMem[keyReg];
    memAboutToChange(p, pKeyOut);
    assert( pC!=0 );
    assert( pC->pKeyInfo!=0 );
    pc++;
    pOp++;
    assert( pOp->opcode==OP_MakeRecord );



  }else{
    pC = 0;
  }
  nField = pOp->p1;
  zAffinity = pOp->p4.z;
  assert( nField>0 && pOp->p2>0 && pOp->p2+nField<=p->nMem+1 );
  pData0 = &aMem[nField];
................................................................................
  if( rc==SQLITE_OK ){
    rc = sqlite4VdbeSorterWrite(db, pC, pIn2);
  }
  break;
}


/* Opcode: IdxInsert P1 P2 * * P5
**
** Register P2 holds an SQL index key made using the
** MakeRecord instructions.  This opcode writes that key
** into the index P1.  Data for the entry is nil.
**
** P3 is a flag that provides a hint to the b-tree layer that this
** insert is likely to be an append.
**
** This instruction only works for indices.  The equivalent instruction
** for tables is OP_Insert.
*/
case OP_IdxInsert: {        /* in2 */






  assert( 0 );











  break;
}

/* Opcode: IdxDelete P1 P2 P3 * *
**
** The content of P3 registers starting at register P2 form
** an unpacked index key. This opcode removes that entry from the 

    pKeyOut = &aMem[keyReg];
    memAboutToChange(p, pKeyOut);
    assert( pC!=0 );
    assert( pC->pKeyInfo!=0 );
    pc++;
    pOp++;
    assert( pOp->opcode==OP_MakeRecord );
#ifdef SQLITE_DEBUG
    if( p->trace ) sqlite4VdbePrintOp(p->trace, pc, pOp);
#endif
  }else{
    pC = 0;
  }
  nField = pOp->p1;
  zAffinity = pOp->p4.z;
  assert( nField>0 && pOp->p2>0 && pOp->p2+nField<=p->nMem+1 );
  pData0 = &aMem[nField];
................................................................................
  if( rc==SQLITE_OK ){
    rc = sqlite4VdbeSorterWrite(db, pC, pIn2);
  }
  break;
}


/* Opcode: IdxInsert P1 P2 P3 * P5
**
** Register P2 holds the data and register P3 holds the key for an
** index record.  Write this record into the index specified by the
** cursor P1.
**
** P5 is a flag that provides a hint to the storage layer that this
** insert is likely to be an append.
**
** This instruction only works for indices.  The equivalent instruction
** for tables is OP_Insert.
*/
case OP_IdxInsert: {        /* in2 */
  VdbeCursor *pC;
  Mem *pKey;
  Mem *pData;

  assert( pOp->p1>=0 && pOp->p1<p->nCursor );
  pC = p->apCsr[pOp->p1];
  assert( pC );
  assert( pC->pKVCur );
  assert( pC->pKVCur->pStore );
  pKey = &aMem[pOp->p3];
  assert( pKey->flags & MEM_Blob );
  pData = &aMem[pOp->p2];
  assert( pData->flags & MEM_Blob );
  rc = sqlite4KVStoreReplace(
     pC->pKVCur->pStore,
     pKey->z, pKey->n,
     pData->z, pData->n
  );
  break;
}

/* Opcode: IdxDelete P1 P2 P3 * *
**
** The content of P3 registers starting at register P2 form
** an unpacked index key. This opcode removes that entry from the