Sorry, this struck a bit of a sore spot with me, so I apologize for the small
rant... Feel free to completely ignore it.
You have every right challenging the views of anyone - It is welcome even (I think - cannot speak for everyone else though, but I
appreciate it). A rant however is probably less effective, but let's see...
CTEs are important for two reasons://.. many valid points to be addressed
below...//
Non-bug-related posts to this list often take the form of one of the following
few categories:
1. Underqualified programmers asking for query help to do their jobs that a
qualified programmer could easily do. Doesn't belong on the list -- I'm sure
there's a #sql-newbies list somewhere for things like this, and there should be
a form-letter answer forwarding people to that.
I'm sorry, are you saying this list is only for bugs and feature requests and helping people use SQLite in normal and mundane ways
do not belong here? If this is true, I shall take my leave immediately because I have no bugs to report and the dev-list is ample
forum for new functionality requests - and kindly point me to where helping people use SQL/SQLite (or gaining such help) is
acceptable, THAT be the list I meant to sign up with.
2. Feature requests from underqualified programmers that don't realize the
right way to do something. Doesn't really belong on the list, though they
mostly get shot down pretty quick or someone points out the obvious answer.
Whatever, doesn't take up much mental/email bandwidth. I can go either way on
this.
How would you tell that you don't know the right way to do something? Put another way, how would you know that the only way you
know how to do something is not the right way or not the best way? You cannot know something until you find it out, so if you are
unaware as to whether you seek a fix to how SQLite works, an understanding of how it works, or whether the way you do it is wrong,
how would you know which list to choose to post on?
That said, once you do ask and offer up your way of doing it, if it does get shown to be incorrect or that a better way exists -
that is a helpful learning experience. I think the words "shot down" is unfair. The only times I have seen direct harsh wording of
the kind you allude to used on here was in reply to persistant insistance on very obviously incorrect methodology, or rants.
3. True feature requests that are not implemented in SQLite and would be useful
to a set of users/developers in some way/shape/form and is not directly
workaroundable.
What I don't like is how often #3 requests gets shot down as being stupid.
Yes, often a feature request doesn't really fit with the general mantra of
SQLite, and it can be easily described as such. However, many things are in a
pretty grey area. For example, CTEs would fit fairly nicely with the general
mantra of SQLite, since it allows for making things smaller/simpler/more
explicit for the QO, but it's being shot down as a non-useful feature that can
be worked around. Well, can it? Or does sqlite perform the subselect multiple
times if you mention the same query a couple different times in subtly
different ways (case sensitive, etc.)? There are important nuances here before
completely dismissing something out of hand.
Again I am sorry, I do not think myself, Simon or anyone else "shot down the request as being stupid" or in fact do so "regularly".
In point of fact, I took great pains to explain that it is a good request and pretty valid too, and even now I admit to you it would
be a nice addition - what I explained was why it probably won't get added and then continued to offer alternate methods of achieving
what the OP was hoping to achieve. Is this not precisely what contributors here are for? Never once did I insinuate stupidity on
the part of the OP for even daring to utter such a silly request (paraphrasing a bit, I know) - Not sure how this invoked the rant,
but I sincerely hope you do not maintain this opinion.
Just because there is another way to do something doesn't mean it's not a valid feature
request to be prioritized with the rest of the feature requests. Saying "this is a
potential future feature someday, but due to [some architecture issue] it's actually
quite complicated to implement, and, as such, is unlikely to ever be actually
implemented" is a completely valid answer from a project management perspective.
Simply dismissing something out of hand without a thorough explanation of why, however,
isn't quite as valid.
Nobody dismissed the idea out of hand nor has the power to do so, though it's a hard sell but if it gains favour universally, or
even just in significant numbers, I'm sure the push for the feature might become paramount and as such likely to be implemented. As
of now I count only 2 requests for it and I am not even sure if the above is a real request for it or just a vehicle for delivering
an opinion. In addition, the requests so far have shown no gains (yet) in system function but only in human terms.
You are the one making the claims - I quote:
1 - "While a query optimizer can potentially deduce the usefulness of the right order to do subqueries in, often times, as a
programmer, I know that I need a single query that will reduce a large dataset to a very small one, and then I need a few nontrivial
operations over the very small dataset."
--and--
"CTEs would fit fairly nicely with the general mantra of SQLite, since it allows for making things smaller/simpler/more explicit for
the QO"
- OK, this looks valid on the outside. Show us a use case where it is true though and where the query optimizer either fails or
similar reduction in dataset size is not possible in a normal query or even possible but produce unacceptable amounts of additional
SQL code, OR where using CTE would so successfully hint to the QO that significant increases in efficiency or decreases in VM ops
would result. The devs are constantly looking for better optimizations, this would be great news.
2 - "Just saying "use multiple subselects" doesn't give any useful feedback about whether that will be properly optimized or not,
and what caveats there are to the optimization process. It also leaves you with a disgustingly long query in many cases."
- How does CTE "give useful feedback" on whether or not it will be properly optimized? Again, show us a use case for this claim, and
I promise you I would be the first to revoke my expressed position and join the requester list for this feature. Also, the word
"disgustingly" is a magnitude of taste - what disgusts you may be music or bile to another - it holds no tangible influence except
to express the self-perceived strength of your opinion. How long is too long? By which standard is this measured? Who agrees with
what exact length is unacceptable? Answers to these questions will be more valuable to the argument.
We are not holding the alternate position due to habit or immovability, but for
reason only.
A good reasoned argument with facts and case studies to back it up cannot be ignored, even by the stubborn of us. In sharp relief, a
rant mostly gets up-voted by those who fight for the cause, and scrutinized for error by those who oppose it, none of which help in
presenting the merit of the argument.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
