Roger Binns <rog...@rogerbinns.com> писал(а) в своём письме Fri, 03 Jun 2011 00:30:12 +0600:
> SQLite was actually in error IMHO. The subquery is the right hand side of > an equality and SQLite was looking for a single row/value. The query > generation code specifically added a LIMIT to ensure that only one row was > produced. SQLite ignored the LIMIT and hard coded the value one. This > "optimisation" resulted in the binding specifying that limit to be optimized > out causing the whole problem. I don't see much sense in specifying LIMIT value via binding parameter, in the first place. When SQLite prepares your query, it builds a query plan. And the most efficient query plan might depend on the given LIMIT value: a) SELECT ... LIMIT 1000 -> one query plan (full scan of the table data) b) SELECT ... LIMIT 1 -> another query plan (quick lookup in the index) c) SELECT ... LIMIT 0 -> third query plan (query get optimized away) Now how SQLite should build a proper plan for your query if you hide limiting value into bind parameter, so the actual value is unknown on prepare stage? That's why I consider such query "stupid" (okay, maybe it's too rough... let's say "silly" ;)) - you should either specify LIMIT 1 explicitly, or avoid using LIMIT there at all, SQLite will do that for ya. :) Regards, Serge _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
