Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Let virtual table implementations know which SQL string is being executed #87

Merged
merged 4 commits into from
Dec 21, 2022
Merged

Let virtual table implementations know which SQL string is being executed #87

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
64b17b8
New sqlite3_module method: xPrepareSql()
lucasvr Dec 12, 2022
86826ae
vdbeExec: remove redundant goto on error path.
lucasvr Dec 19, 2022
9e10fd8
xPrepareSql: require iVersion >= 700
lucasvr Dec 19, 2022
25e2204
Rename method from PrepareSql to PreparedSql
lucasvr Dec 19, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions src/sqlite.h.in
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7076,6 +7076,8 @@ struct sqlite3_module {
/* The methods above are in versions 1 and 2 of the sqlite_module object.
** Those below are for version 3 and greater. */
int (*xShadowName)(const char*);
/** The methods below are for version 4 and greater. */
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's going to get ambiguous if/when SQLite adds some other field and bump the current version to 4, and we'd like to keep libSQL compatible for as long as possible. There's no perfect solution here, but in an (unmerged yet) pull request I used version "700", to indicate that it's a libSQL extension, and it makes the collision less likely to happen in the next few years. Perhaps the same trick could be applied here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense. HDF5 adopts a similar approach when dealing with I/O filters: a certain range of numbers is reserved for filters contributed by the community. I will follow your suggestion and will check for iVersion >= 700.

int (*xPrepareSql)(sqlite3_vtab_cursor*, const char*);
};

/*
Expand Down
17 changes: 15 additions & 2 deletions src/test8.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1293,6 +1293,17 @@ static int echoRollbackTo(sqlite3_vtab *pVTab, int iSavepoint){
return SQLITE_OK;
}

static int echoShadowName(const char *name){
assert( name );
return SQLITE_OK;
}

static int echoPrepareSql(sqlite3_vtab_cursor *cur, const char *sql){
assert( cur );
assert( sql );
return SQLITE_OK;
}

/*
** A virtual table module that merely "echos" the contents of another
** table (like an SQL VIEW).
Expand Down Expand Up @@ -1321,7 +1332,7 @@ static sqlite3_module echoModule = {
};

static sqlite3_module echoModuleV2 = {
2, /* iVersion */
4, /* iVersion */
echoCreate,
echoConnect,
echoBestIndex,
Expand All @@ -1343,7 +1354,9 @@ static sqlite3_module echoModuleV2 = {
echoRename, /* xRename - rename the table */
echoSavepoint,
echoRelease,
echoRollbackTo
echoRollbackTo,
echoShadowName,
echoPrepareSql,
};

/*
Expand Down
34 changes: 34 additions & 0 deletions src/vdbe.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8072,6 +8072,40 @@ case OP_VInitIn: { /* out2 */
}
#endif /* SQLITE_OMIT_VIRTUALTABLE */

#ifndef SQLITE_OMIT_VIRTUALTABLE
/* Opcode: VPrepareSql P1 * * * *
**
** P1 is a cursor opened using VOpen.
**
** This opcode invokes the xPrepareSql method on the virtual table specified
** by P1. The SQL text parameter to xPrepareSql is obtained from Vdbe* `p`.
**
*/
case OP_VPrepareSql: {
const sqlite3_module *pModule;
sqlite3_vtab_cursor *pVCur;
sqlite3_vtab *pVtab;
VdbeCursor *pCur;

pCur = p->apCsr[pOp->p1];
assert( pCur!=0 );
assert( pCur->eCurType==CURTYPE_VTAB );
pVCur = pCur->uc.pVCur;
pVtab = pVCur->pVtab;
pModule = pVtab->pModule;

/* Invoke the xPrepareSql method */
if( pModule->iVersion>=4 ){
if( pModule->xPrepareSql && p->zSql ){
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question - in which cases is p->zSql null? I wonder if the responsibility for checking and handling NULL shouldn't be pushed to the implementation of xPrepareSql - perhaps somebody would like to do something specific even for cursors that don't have the SQL text?

This is a genuine question, as I haven't implemented any virtual SQLite tables in my life (: if it doesn't make sense, then feel free to leave the code as is.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added that as a sanity check. A NULL value for p->zsql would be possible when handling the Init or Trace opcodes, but that is not expected when processing a valid SQL statement.

rc = pModule->xPrepareSql(pVCur, p->zSql);
if( rc ) goto abort_due_to_error; // TODO set and test error msg
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you elaborate on the TODO? As long as the implementation of xPrepareSql assigns a proper error code, it will be properly handled and printed in the code that follows abort_due_to_error.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was a reminder to test the error path, but I ended up leaving it behind by mistake. I will remove it.

}
}

if( rc ) goto abort_due_to_error;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this line looks redundant - it's already checked in line 8101, and line 8100 is the only one in this block that assigns to rc

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, indeed. Thanks for spotting that!

break;
}
#endif /* SQLITE_OMIT_VIRTUALTABLE */

#ifndef SQLITE_OMIT_VIRTUALTABLE
/* Opcode: VFilter P1 P2 P3 P4 *
Expand Down
2 changes: 2 additions & 0 deletions src/wherecode.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1415,6 +1415,8 @@ Bitmask sqlite3WhereCodeOneLoopStart(
int addrNotFound;
int nConstraint = pLoop->nLTerm;

sqlite3VdbeAddOp1(v, OP_VPrepareSql, iCur);

iReg = sqlite3GetTempRange(pParse, nConstraint+2);
addrNotFound = pLevel->addrBrk;
for(j=0; j<nConstraint; j++){
Expand Down
40 changes: 40 additions & 0 deletions test/rowvaluevtab.test
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,10 @@ ifcapable !vtab {

register_echo_module db

#############
# Test echo
#############

do_execsql_test 1.0 {
CREATE TABLE t1(a, b, c);
CREATE INDEX t1b ON t1(b);
Expand Down Expand Up @@ -92,4 +96,40 @@ do_vfilter4_test 1.4f {
SELECT a FROM e1 WHERE (b, c) IN ( VALUES(2, 2) )
} {{SELECT rowid, a, b, c FROM 't1' WHERE b = ?}}

######################################################################
# Test echo_v2. We simply want to ensure that OP_VPrepareSql executes
######################################################################

do_execsql_test 2.0 {
CREATE TABLE t2(a, b, c);
CREATE INDEX t2b ON t2(b);
INSERT INTO t2 VALUES('one', 1, 1);
INSERT INTO t2 VALUES('two', 1, 2);
INSERT INTO t2 VALUES('three', 1, 3);

WITH s(i) AS (
SELECT 1 UNION ALL SELECT i+1 FROM s WHERE i<10000
) INSERT INTO t2 SELECT NULL, NULL, NULL FROM s;
CREATE VIRTUAL TABLE e2 USING echo_v2(t2);
}

proc do_vpreparesql1_test {tn sql expected} {
set rc -1
db eval "explain $sql" {
if {$opcode=="VPrepareSql"} {
set rc 0
}
}
if {$rc != $expected} {
error "Unexpected result $rc, was hoping for $expected"
}
}

do_execsql_test 2.1 {
SELECT a FROM e2 WHERE (b, c) IN ( VALUES(1, 3) )
} {three}
do_vpreparesql1_test 2.1f {
SELECT a FROM e2 WHERE (b, c) IN ( VALUES(2, 2) )
} {0}

finish_test