This reminds me of a plan to add RADAR dishes to cars to monitor other traffic and avoid collisions - brilliant idea but the detrimental effect on aerodynamics and limiting size-factor of already-built garages all over the world stifled enthusiasm.

Probably "Temporary Views" would be the exact thing that can achieve the same as CTE. Further simplification might be implemented on your code, if in fact you are designing a system and not using some other SQLite-reliant system (in which case CTE might really help you).

To emphasize what Simon said: SQLite does not support a full syntactic script engine with variables and the like and isn't likely to expand by doing it and/or include CTE for the simple reason that the cost tradeoff in DB-Engine size vs. added functionality is non-sensical. It has to function in many cases as a DB engine on embedded systems where space is a real concern, and those designers would dread the idea of devoting more memory in the name of readability - and it is probably fair to extend that sentiment to designers with non-embedded systems (I know it is true for me).

One might probably add a compile-time switch enabling or disabling (or including) a CTE component so that the feature and related space-consumption might be optional, but if you prefer CTE for your SQL, I am confident that compile-time switching won't be your favourite thing either. Further to this, the effort / pleasure ratio of adding it would probably prove larger than comfortable.

As an aside, proper use of comment-blocks and inline commenting (which both your code and SQLite allows) can make anything as clear you'd like.

Have a great day!
Ryan

On 2013/12/26 21:05, Simon Slavin wrote:
On 26 Dec 2013, at 6:57pm, big stone <stonebi...@gmail.com> wrote:

"sub-select" method :
- allows you to do only a part of what you can do in CTE,
- becomes more and more difficult to read as you add tables and treatment
in your sql.

With CTE in SQLite, it would be possible to:
- decompose your SQL treatment in clean intermediate steps,
- make your global algorithm "visible",
- do easily things currently impossible in 1 query with sub-selects.
It looks like you want VIEWs rather than sub-selects.  VIEWs enable all the 
things you listed above.

<http://www.sqlite.org/lang_createview.html>

They're a way of saving a SELECT command so it can be used as if the results 
are a table.

Simon.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to