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