Skip to content

Suggestion: Allow binding Vec in SQLite with something like carray #1113

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.

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

Open
phiresky opened this issue Mar 16, 2021 · 2 comments
Open

Suggestion: Allow binding Vec in SQLite with something like carray #1113

phiresky opened this issue Mar 16, 2021 · 2 comments

Comments

@phiresky
Copy link

phiresky commented Mar 16, 2021

This is related to #656, #875, probably others. The problem is that Vec binding is currently only supported in PostgreSQL. In Sqlite this currently requires manually building a huge query string that can't by type-checked or cached.

SQLite includes a extension called carray that allows binding a list of values of primitives to a single bind parameter. It's basically the same thing as unnest() in PostgreSQL. It's implemented as an sqlite "virtual table" or table-valued-function and can be used like select * from foo where x in carray(?) or select * from carray(?) (for INSERTs). In Rust I guess either the C implementation could be integrated or a custom vtable could be registered. Rusqlite has an easy-to-use implementation of the same thing: https://docs.rs/rusqlite/0.24.2/rusqlite/vtab/array/index.html

@phiresky
Copy link
Author

phiresky commented Mar 16, 2021

As a comparison, the integrated table valued function json_each is similar and can be used similarily (but requires serialization):

create table test (a,b);
insert into test select a.value,b.value from json_each('[1,2,3]') a, json_each('[1,2,3]') b where a.key = b.key;
-- the where condition is needed since otherwise it uses the cartesian product

select * from test where x in (select value from json_each('[2,3]'));

@Hans-Wu-cn
Copy link

I also encountered a similar problem. Using vec as a parameter is inconvenient when using the in keyword

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants