But then in BASH, for example, the temp table would only last for the life of the initial connection, so you'd have to throw everything in one execution. This goes along the lines of just setting a variable. A BIG time question comes to scope of the life of the variable. Does it live for the entirety of the databases life? Does it live for that connection? Does it live for that transaction? Too many ways to have that play out that it just may not be worth while coding it into the SQLite base anyways.
I guess there are many different ways to skin this cat. Temp tables, going in and out of quotes, binding, etc. I was just curious whether variables were something to be, or are being considered, or, if it's something that's been outright "Will not do". I don't know of Postgres has variables or not, but that's server side, and Keith mentions, SQLite works off of single statements. On Sat, Jan 19, 2019 at 2:12 PM Scott Robison <sc...@casaderobison.com> wrote: > > > 1> create temp table vars(name, value); > 2> insert into vars values('count', 10); > 3> select * from test where i <= (select value from vars where > name='count'); > > That's just one example, of course. Multiple variations on the theme are > possible if one needs variables that live exclusively in SQL without using > a host language and that also survive for more than a single statement. > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users