On 25/01/14 03:37, James K. Lowden wrote:
On Fri, 24 Jan 2014 23:51:11 +0100
Petite Abeille <petite.abei...@gmail.com> wrote:
It's exactly the same as "SELECT ?", but a little bit easier to
write. (It behaves like with INSERT, but is now available in every
place where a SELECT would be allowed.)
Hmmm? seems rather pointless to me.
select 1 as value /* from thin air */ union all
select 2 as value /* from thin air */
? etc ?
Seems to be good enough. No point in hijacking a totally unrelated
construct. I would drop such complication if I had a say. There is
already a perfectly fine construct to conjure constants out of thin
air: select.
VALUES is a row constructor. You should be able to do
VALUES ( ( 'a', 'b', 'c' ) , ('d', 'e', 'f') )
as ( A, B, C ) as T
Wouldn't it be better instead of creating a new concept "row
constructor", to use the existing row constructors, also known as
virtual tables?
If we had the option of using virtual tables without first creating
them, and we also were able to have them at the front of the query
(automatically prepending a select * from ...) then VALUES above, could
be a virtual table [*].
So think of a virtual table named VALUES that gets as parameters the
values that you want it to emit. Then you can select from it, insert
from it and so on.
l.
[*] In addition if we permitted queries as parameters in virtual tables,
it would also enable virtual table composition.
An example of how this is done in madIS is below (XMLPARSE and FILE are
virtual tables):
XMLPARSE FILE 'xmldata.xml.gz';
or expanded:
select * from (XMLPARSE select * from FILE('xmldata.xml'));
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
