> On Wed, Mar 5, 2014 at 4:59 AM, Chris <sqlite at lists.azureblue.org> wrote:
>
> > I'm a relative novice to sqlite (or sql in general), but I do understand
> > the value of variable substitution when building queries:
> >
> > e.g.
> > set someValue 23
> > db eval {SELECT something FROM myTable WHERE value=$someValue}
> >
> > It feels like there should be a comparable solution for IN, passing
> > instead a Tcl list, but I've failed to find it documented or had any
> > trial-and-errorr success.
> >
> > e.g.
> > set someTags {1 23 45}
> > db eval {SELECT something FROM myTable WHERE value IN ($someTags)}
> >
>
> Can't do this. SQL has no "list" or "array" datatype. So $someTags cannot
> be translated into an SQL value.
>
> One work-around:
>
> db transaction {
> db eval {CREATE TEMP TABLE someTags(x INTEGER PRIMARY KEY);}
> foreach x $someTags {db eval {INSERT INTO someTags VALUES($x)}}
> }
> db eval {SELECT something FROM myTable WHERE value IN someTags}
>
> --
> D. Richard Hipp
> drh at sqlite.org
Ok, fair enough. I thought that in the same way that sqlite looks for
binary vs. string representations of referenced vars and has alternative
ways of specifying variable to bind to ('@', ':'), it might also spot a
list object and internally expand it to "elem_0,elem_1,elem_2". Would
that be a useful feature, or does it introduce opportunities to draw the
wrong conclusion?
Chris
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
