On Wed, 1 Jan 2014 11:04:57 +0100
big stone <stonebi...@gmail.com> wrote:
> You're right :
> *"*CTEs ... add exactly zero to SQLite's capability."
>
> This is also right :
> "C Language ... add exactly zero to Intel X86 processor capability".
Dennis Ritchie said C is an idealized assembler over an idealized
machine. ;-)
> CTE ... bring capabilities to the users, by simplifying
> the use of the underlying tool.
CTEs would add complexity, not simplify.
You seem to think
with V as [query]
select ... from V;
is better than
select ... from ([query]) as V;
It's not. You may like it better, but objectively the query is only
rearranged. It's not shorter.
If implemented, readers of SQLite queries would be forced to master two
syntaxes instead of one. That's more complex, not simpler.
I suspect we differ on this point, that you think it's good to have
more than one syntax for the very same query. Is that the case?
Because that would be a distinct disagreement on what "good" is,
independent of CTEs per se.
You may claim
with V as [query]
select ... from V as a join V as b ... ;
is an improvement over
create view V as [query];
select ... from V as a join V as b ... ;
because the schema doesn't become "cluttered" with the V name.
Because that form of query is rare, the number of such views is small,
hence any "cluttering" is minor. Not to mention the named view has
advantages of its own, including communicating what the query means (in
the name) and potential reuse.
ISTM your case rests on a slender reed: it's good to have inline
views, to avoid single-purpose real views. Or, perhaps, that freedom of
expression is good. Do you really think SQLite syntax should be
altered on that basis?
--jkl
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
