@R.Smith I wasn't aware that recursive aggregate queries give wrong answers in 99% of all general use cases. In that case, it is obviously preferable to disable it.
On Sat, Sep 12, 2015 at 5:51 PM, R.Smith <rsmith at rsweb.co.za> wrote: > > > On 2015-09-12 10:58 PM, Aurel Wisse wrote: > >> The fastest solution is actually the temporary table: >> > > Glad you found a faster solution. > > Still Richard : How about allowing recursive aggregate queries again ? >> > > You say "allow" like it's something that worked and they blocked it out > for no good reason. > > It didn't work, your use case is a single accidental fringe that happened > to work by virtue of the MIN() operation's character in the specific query, > much in the way that if you throw a handful of seeds on a pavement and one > of them happens to roll all the way over to a mossy moist area and found it > could germinate, it is not a good reason to promote pavement-seeding - even > if you happen to be the observer from the mossy patch. > > Put another way: It isn't good to allow a convention that will "seem" to > do a certain thing or work a certain way, but then give a completely wrong > answer in 99% of cases - all because 1% happens to be correct. > > MIN() actually has two implementations, one aggregate and one as a simple > function, might be one could allow MIN() and MAX() if they always produced > the correct results... but then we need test-cases to ensure they always > give correct results, we need to maintain code that caters for it etc. and > all that to achieve a prize which is handled better and faster by a temp > table in the end. > > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- Aurel Wisse (514) 814-5421
