Further to sqlite pivot function, matrix functions, or any other result set
meta query language feature, I commented about this before with a concrete
suggestion. The core problem is the awkward complexity of building a
completely general virtual table (vtab) based eval("<sql>") or
meta("<sql>") which communicates correctly with the query optimizer.
Things have changed somewhat since I wrote those comments. After the
introduction of row values in 3.15 https://www.sqlite.org/rowvalue.html ,
at least, now the sqlite ecosystem can cope with efficient vector valued
data for passing parameters into and out of the hypothetical eval() or
meta() vtab module. Presumably there are more pleasant surprises like
rowvalues on the horizon?
Has anyone put thought into how completely general sqlite sql strings could
be executed with full optimizer support within vtab code so the properties
of the resulting rowset can be exposed in the result columns returning from
the desired vtab module?
Just a thought. Looking forward to the dazzling thread of replies!
On Tue, Mar 7, 2017 at 11:26 AM, Clemens Ladisch <clem...@ladisch.de> wrote:
> James K. Lowden wrote:
> > Clemens Ladisch <clem...@ladisch.de> wrote:
> >> Recursive CTEs make SQL Turing complete.
> >>
> >> But they cannot do everything.
> >
> > Isn't that a contradiction?
>
> Being able to emulate a Turing machine (or a register machine) means
> that there exists _some_ representation of the data, but not that it has
> the form you actually want. To get back to the pivot example: if I want
> multiple columns, what use are thousands of rows that encode the Turing
> machine's tape?
>
>
> Regards,
> Clemens
> _______________________________________________
> 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
