** CAPI3REF: Virtual Table Configuration Options
**
** These macros define the various options to the
** [sqlite3_vtab_config()] interface that [virtual table] implementations
** can use to customize and optimize their behavior.
**
** <dl>
**   <dt>SQLITE_VTAB_CONSTRAINT_SUPPORT
**   <dd>If the second argument to [sqlite3_vtab_config()] is
**       SQLITE_VTAB_CONSTRAINT_SUPPORT, then SQLite expects this function to
**       have been called with three arguments, the third of which being of
**       type 'int'. If the third argument is zero, then the virtual table
**       is indicating that it does not support constraints. In this case if
**       a call to the [xUpdate] method returns [SQLITE_CONSTRAINT], the entire
**       statement is rolled back as if [ON CONFLICT | OR ABORT] had been
**       specified as part of the users SQL statement, regardless of the actual
**       ON CONFLICT mode specified.
**
**       If the third argument passed is non-zero, then the virtual table
**       implementation must guarantee that if [xUpdate] returns 
**       [SQLITE_CONSTRAINT], it does so before any modifications to internal
**       or persistent data structures have been made. If the [ON CONFLICT]
**       mode is ABORT, FAIL, IGNORE or ROLLBACK, SQLite is able to roll back
**       a statement or database transaction, and abandon or continue processing
**       the current SQL statement as appropriate. If the ON CONFLICT mode is
**       REPLACE and the [xUpdate] method returns [SQLITE_CONSTRAINT], SQLite
**       handles this as if the ON CONFLICT mode had been ABORT.

**
**       Virtual table implementations that are required to handle OR REPLACE
**       must do so within the xUpdate method. If a call to the 
**       [sqlite3_vtab_on_conflict()] function indicates that the current ON 
**       CONFLICT policy is REPLACE, the virtual table implementation should 
**       silently replace the appropriate rows within the xUpdate callback and
**       return SQLITE_OK. Or, if this is not possible, it may return
**       SQLITE_CONSTRAINT, in which case SQLite falls back to OR ABORT 
**       constraint handling.
** </dl>
** 
*/
#define SQLITE_VTAB_CONSTRAINT_SUPPORT 1

/*
** CAPI3REF: Determine The Virtual Table Conflict Policy
**
** This function may only be called from within a call to the [xUpdate] method

** CAPI3REF: Virtual Table Configuration Options
**
** These macros define the various options to the
** [sqlite3_vtab_config()] interface that [virtual table] implementations
** can use to customize and optimize their behavior.
**
** <dl>
** <dt>SQLITE_VTAB_CONSTRAINT_SUPPORT
** <dd>Calls of the form
** [sqlite3_vtab_config](db,SQLITE_VTAB_CONSTRAINT_SUPPORT,X) are supported,
** where X is an integer.  If X is zero, then the [virtual table] whose
** [xCreate] or [xConnect] method invoked [sqlite3_vtab_config()] does not
** support constraints.  In this configuration (which is the default) if
** a call to the [xUpdate] method returns [SQLITE_CONSTRAINT], then the entire
** statement is rolled back as if [ON CONFLICT | OR ABORT] had been
** specified as part of the users SQL statement, regardless of the actual
** ON CONFLICT mode specified.
**
** If X is non-zero, then the virtual table implementation guarantees
** that if [xUpdate] returns [SQLITE_CONSTRAINT], it will do so before

** any modifications to internal or persistent data structures have been made.
** If the [ON CONFLICT] mode is ABORT, FAIL, IGNORE or ROLLBACK, SQLite 
** is able to roll back a statement or database transaction, and abandon
** or continue processing the current SQL statement as appropriate. 
** If the ON CONFLICT mode is REPLACE and the [xUpdate] method returns
** [SQLITE_CONSTRAINT], SQLite handles this as if the ON CONFLICT mode
** had been ABORT.
**
** Virtual table implementations that are required to handle OR REPLACE
** must do so within the [xUpdate] method. If a call to the 
** [sqlite3_vtab_on_conflict()] function indicates that the current ON 
** CONFLICT policy is REPLACE, the virtual table implementation should 
** silently replace the appropriate rows within the xUpdate callback and
** return SQLITE_OK. Or, if this is not possible, it may return
** SQLITE_CONSTRAINT, in which case SQLite falls back to OR ABORT 
** constraint handling.
** </dl>

*/
#define SQLITE_VTAB_CONSTRAINT_SUPPORT 1

/*
** CAPI3REF: Determine The Virtual Table Conflict Policy
**
** This function may only be called from within a call to the [xUpdate] method

  va_start(ap, op);
  switch( op ){
    case SQLITE_VTAB_CONSTRAINT_SUPPORT: {
      VtabCtx *p = db->pVtabCtx;
      if( !p ){
        rc = SQLITE_MISUSE_BKPT;
      }else{
        assert( (p->pTab->tabFlags & TF_Virtual)!=0 );
        p->pVTable->bConstraint = (u8)va_arg(ap, int);
      }
      break;
    }
    default:
      rc = SQLITE_MISUSE_BKPT;
      break;

  va_start(ap, op);
  switch( op ){
    case SQLITE_VTAB_CONSTRAINT_SUPPORT: {
      VtabCtx *p = db->pVtabCtx;
      if( !p ){
        rc = SQLITE_MISUSE_BKPT;
      }else{
        assert( p->pTab==0 || (p->pTab->tabFlags & TF_Virtual)!=0 );
        p->pVTable->bConstraint = (u8)va_arg(ap, int);
      }
      break;
    }
    default:
      rc = SQLITE_MISUSE_BKPT;
      break;