On Fri, Sep 23, 2016 at 1:39 PM, Richard Hipp <d...@sqlite.org> wrote:
> On 9/23/16, Dominique Devienne <ddevie...@gmail.com> wrote: > > > > For a long time, I've wanted to bind the RHS of a IN operator of > arbitrary size, > > See the carray() table-valued function extension: > https://www.sqlite.org/draft/carray.html Thanks for the reminder. My RHS is a list of guids in the form of blob(16) values, so carray doesn't fit. I can of course make my own carray-like eponymous vtable, but honestly passing a pointer to an array who's lifetime is not managed by SQLite is a hack IMHO. This is what I wish for: sqlite3_bind_row_value( // or sqlite3_bind_array, either way sqlite3_stmt*, int, // bind index void *pApp, // access via sqlite3_user_data(), and passed in to callbacks below int (*xSize)(sqlite3_context*, void* pApp), // optional? but if provided, used by query planner int (*xItem)(sqlite3_context*, void* pApp), // returns SQLITE_OK or SQLITE_DONE (unless xSize required) void(*xDestroy)(void* pApp) ); This is like an "anonymous" "eponymous" "temporary" vtable, whose lifetime is managed by SQLite properly. It's a cross between a sqlite3_bind_* and sqlite3_register_*, and the sqlite3_context* allows to return one value at a time, with an optional cardinality method to allow the query planner to use the best plan, but w/o the sqlite3_value** argument since binding does not depend on runtime arguments. And by reusing the machinery of https://www.sqlite.org/c3ref/context.html, we can even leverage the recent https://www.sqlite.org/c3ref/result_subtype.html too. AFAIK, this is much easier than eponymous vtables, but more importantly it is safe, clean, with proper (temporary) lifetime semantics, and anonymous too. My $0.02. --DD _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
