[Scott Hess] > I think you're making unwarranted assumptions about the order your > custom function will be called. Even if you added "ORDER BY" to the > end of the query, that wouldn't necessarily order the calls to your > custom function. Even if you find a workaround which allows you to > implement something in the current version of SQLite, it wouldn't > necessarily work in a future version.
Yes, I'm fearing that. For instance, non-aggregate functions would be natural candidates for parallelisation on a multicore platform, and then the order will surely be broken. While the sqlite site declares that "threads are evil", it seems likely that people will ask for more performance on their 100 core CPU's, so it might be a dangerous bet to assume that sqlite never will go that path eventually. > Unfortunately, I can't offhand think of a reasonable solution for you, > I think I'd just use the SELECT to generate the data, while > calculating the moving average in my application code. Yes, but that reduces sqlite to just a way to store data. It would be nice to be able to use SQL and aggregate functions on the resulting moving average (in particular max() and min()). Perhaps the moving average can be implemented as a virtual table? One should think that the ability to calculate a moving average would be a pretty common request. But people do it in their application code instead? -- Steinar _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
