Thanks for the idea but the interface already handles that and does it without special names. The last example in my last post shows that d was correctly typed in the output because the interface noticed that it had the same name as an input column. Other problems are that it would still not handle propagation through expressions and would require that the user use special names different than the names in the input.
I appreciate these ideas but these or equally effective alternatives are already implemented and it is precisely these kludges that I was trying to avoid. With one R statement the user can switch back ends so unless sqlite works as smoothly as the alternative backends a user will choose one of those if they are doing a lot of date and datetime processing. For many applications the other advantages of sqlite would take precedence. The fact that sqlirte is included right in the R driver package is very convenient as it means there is nothing additional to install beyond the R driver. (H2 is also included in the R driver but in that case java needs to be installed.) Also the new windowing functions, CTEs and other features are great. Unfortunately in the widely applicable case of dates and date times the other databases just work and additional care needs to be taken with sqlite. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
