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
