On Sat, Jan 10, 2009 at 04:26:56PM -0600, Nicolas Williams wrote: > Incidentally, I think many, if not all queries that have an outer table > scan, and many, if not all joins that have an inner table scan but not > an outer table scan, could be programmatically modified to create a > scrolling cursor, forward and backwards. All that has to be done is: > pick one table whose rowid to extract, add the where clause for rowid < > or > than some variable, add the limit clause, and the sub-select for > paging backwards. But parsing the select just do that is hard, while > the SQLite3 parser is uniquely positioned to do it for the user. So > perhaps there's a small RFE here?
Actually, I'm sure that many queries can't be so modified and retain their semantics (queries using aggregates, ORDER BY something other than the rowid or index key (for queries where the engine scans an index instead of a table). So, never mind the idea of a generic SQLite3 cursor based on this idea. But it still makes good fodder for the wiki. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
