Re: [sqlite] Feature Request: Binding Arrays

On 3 Nov 2013, at 9:07am, Dominique Devienne wrote: > This is consistent with findings we've seen in our own software, where > rewriting queries to use joins instead of custom SQL functions sped up some > queries considerably. The SQLite engine completely understands

Re: [sqlite] Feature Request: Binding Arrays

Am 31.10.2013 14:09, schrieb Dominique Devienne: [Userdefined functions in conjunction with fast Exists-checks in "Userland" - vs. SQLites built-in indexing in case of In (List)] I'm not convinced by this. The "real table" can be quite large, several 100's to 100,000's rows (up to 1+ million

Re: [sqlite] Feature Request: Binding Arrays

On 01.11.2013 22:04, Alek Paunov wrote: After reading the whole tread I suspect that you have already considered the whole thing about the :memory: DB bridging the GUI with the real DB but I am curious why? Sorry - unfinished sentence: ... why you have rejected this approach?

Re: [sqlite] Feature Request: Binding Arrays

Hi Dominique, On 16.10.2013 11:40, Dominique Devienne wrote: We have an SQLite virtual-table heavy application with a lot of the GUI driven by SQL queries, and often times we have queries of the form ... create table t (name text, type text, primary key (name, type)); select * from t

Re: [sqlite] Feature Request: Binding Arrays

On 31.10.2013 18:37, Nico Williams wrote: On Wed, Oct 16, 2013 at 07:28:04AM -0400, Richard Hipp wrote: Please see http://www.sqlite.org/src/artifact/2ece66438?ln=13-75 I've been thinking for a while -ever since I happened upon jq(1)- that a marriage of jq and SQLite3 would be wonderful. jq

Re: [sqlite] Feature Request: Binding Arrays

Oh, and jq is at: https://stedolan.github.io/jq ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature Request: Binding Arrays

On Wed, Oct 16, 2013 at 07:28:04AM -0400, Richard Hipp wrote: > Please see http://www.sqlite.org/src/artifact/2ece66438?ln=13-75 I've been thinking for a while -ever since I happened upon jq(1)- that a marriage of jq and SQLite3 would be wonderful. jq is a JSON query language. It's a functional

Re: [sqlite] Feature Request: Binding Arrays

On Thu, Oct 31, 2013 at 2:45 AM, Olaf Schmidt wrote: > Am 29.10.2013 13:19, schrieb Dominique Devienne: > >> [...] >> First off, when you use functions like this, you basically rule >> out index use, even if some_column is indexed. That's not good. >> << WHERE col IN

Re: [sqlite] Feature Request: Binding Arrays

Am 29.10.2013 13:19, schrieb Dominique Devienne: So, after those functions are in place - where's the problem with: select * from table where InMySmallUnsortedArrayExists(some_column) select * from table where InMyLargerSortedArrayExists(some_column) select * from table where

Re: [sqlite] Feature Request: Binding Arrays

On Tue, Oct 29, 2013 at 2:06 AM, Olaf Schmidt wrote: > Am 16.10.2013 10:40, schrieb Dominique Devienne: > If I somehow missed a better work-around to this lack of array-binding, I'm > >> also interested of course, but obviously I'd prefer real array binding. >> > > Maybe

Re: [sqlite] Feature Request: Binding Arrays

Am 16.10.2013 10:40, schrieb Dominique Devienne: If I somehow missed a better work-around to this lack of array-binding, I'm also interested of course, but obviously I'd prefer real array binding. Maybe I'm missing something - but if I'd have a lot of "InApp- MemAllocations" in the form of

Re: [sqlite] Feature Request: Binding Arrays

On Wed, Oct 16, 2013 at 1:28 PM, Richard Hipp wrote: > Please see http://www.sqlite.org/src/artifact/2ece66438?ln=13-75 Thanks. Being familiar with vtables, I had imagined as much, even though stopped short of doing it in practice. This takes care of hiding the DML statements

Re: [sqlite] Feature Request: Binding Arrays

It is really useful feature. I have a use case where I need to log the data in continuous interval & store in database. If array type is supported by sqlite then in single row I can store data in array of time stamp & array of value. Is it specific to int type or any other data type can be

Re: [sqlite] Feature Request: Binding Arrays

> Since version 3.6.21, circa 2009-12-07. Note however that this capability > is not built in. It is an extension that you need to compile and link > separately. > > OK... Herewith my vote to make it standard then, like SQLITE_ENABLE_COLUMN_METADATA was enabled for the precompiled binary at some

Re: [sqlite] Feature Request: Binding Arrays

On Wed, Oct 16, 2013 at 7:40 AM, Paul van Helden wrote: > Fantastic! I've been wanting this for a long time. > > Since which version do we have sqlite3_intarray_x? > > Since version 3.6.21, circa 2009-12-07. Note however that this capability is not built in. It is an

Re: [sqlite] Feature Request: Binding Arrays

Fantastic! I've been wanting this for a long time. Since which version do we have sqlite3_intarray_x? On Wed, Oct 16, 2013 at 1:28 PM, Richard Hipp wrote: > Please see http://www.sqlite.org/src/artifact/2ece66438?ln=13-75 > > > -- > D. Richard Hipp > d...@sqlite.org >

Re: [sqlite] Feature Request: Binding Arrays

Please see http://www.sqlite.org/src/artifact/2ece66438?ln=13-75 -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Feature Request: Binding Arrays

On Wed, Oct 16, 2013 at 12:03 PM, Clemens Ladisch wrote: > Dominique Devienne wrote: > > select * from some_table where some_column in (...) > > > > 2) In other places we synthesize the query text by splicing list.join(", > ") > > in the in (list) where clause. > > > > Both

Re: [sqlite] Feature Request: Binding Arrays

Dominique Devienne wrote: > select * from some_table where some_column in (...) > > 2) In other places we synthesize the query text by splicing list.join(", ") > in the in (list) where clause. > > Both solutions are unsatisfactory, because ... 2) constantly reparse and > prepare queries, which can

[sqlite] Feature Request: Binding Arrays

We have an SQLite virtual-table heavy application with a lot of the GUI driven by SQL queries, and often times we have queries of the form select * from some_table where some_column in (...) where ... is coming from prior selections in the GUI, or filtering, etc... 1) In some places, we create