I ran gdb to find out more, and here's how sqlite3_declare_vtab()
exits:
102133 if( !db->pVtabCtx || !(pTab = db->pVtabCtx->pTab) ){
(gdb) n
102134 sqlite3Error(db, SQLITE_MISUSE, 0);
(gdb) print db->pVtabCtx
$1 = (VtabCtx *) 0x0
To explain further what I'm doing: My virtual table basically takes a
number of tables as arguments and creates a new table like a natural
join of the input tables, except that where a natural join would
create NULL values, the virtual table will create interpolated
values. The module does a number of other things as well, but I don't
think that's relevant here. So I can do:
create virtual table v1 using interpolate(tab1, tab2, tab3);
But then this will fail:
create virtual table v2 using interpolate(v1, tab4);
When I run in gdb, I see that pVtabCtx is nonzero in xCreate for v2
until it runs sqlite3_prepare_v2() with a statement which selects from
v1 (causing xCreate to be called for v1). After sqlite3_prepare_v2()
returns, pVtabCtx is 0.
Is this a bug, or is it intentional (possibly for a good reason)?
My xCreate function needs to run queries on the input tables to find
the column names needed for the vtab declaration.
-Steinar
Steinar Midtskogen <stei...@latinitas.org> writes:
> Hello,
>
> In certain cases when I try to create a virtual table,
> sqlite3_declare_vtab() returns SQLITE_MISUSE. Nothing appears to be
> wrong with the string I pass to the sqlite3_declare_vtab(). That is,
> if I execute the "create table" statement in that string, a regular
> table will be created - no error.
>
> Is there a way to get more hints why sqlite3_declare_vtab() fails?
>
> The only thing special when it fails is that xCreate, before the call
> to sqlite3_declare_vtab, has (successfully) run and finished
> statements (prepare/step/finalize) which involve a virtual table using
> the very same module. Is it forbidden to nest virtual tables this
> way? That is, having xCreate trigger a call to itself (using
> different arguments). I'm pretty sure that I don't use non-const
> static variables which could mess up things. Perhaps sqlite3 does?
>
> --
> Steinar
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
