On Wed, Feb 20, 2013 at 09:25:54PM +0100, Petite Abeille scratched on the wall: > On Feb 20, 2013, at 2:15 PM, Richard Hipp <d...@sqlite.org> wrote: > > > SQLite automatically adds a LIMIT 1 to a scalar subquery. > > Yeah? that's a bit of a death trap though? would be much more productive > if SQLite would raise an exception instead of doing something covert > and random...
Not covert... works as documented: http://www.sqlite.org/lang_expr.html Scalar Subqueries A SELECT statement enclosed in parentheses may appear as a scalar quantity. A SELECT used as a scalar quantity must return a result set with a single column. The result of the expression is the value of the only column in the first row returned by the SELECT statement. If the SELECT yields more than one result row, all rows after the first are ignored. If the SELECT yields no rows, then the value of the expression is NULL. The LIMIT of a scalar subquery is always 1. Any other LIMIT value given in the SQL text is ignored. All types of SELECT statement, including aggregate and compound SELECT queries (queries with keywords like UNION or EXCEPT) are allowed as scalar subqueries. Not random either... at least, not any more random than any other query. Result order is never meaningful unless there is an ORDER BY. As for "productive", I suppose that depends on if you want SQL to find poorly thought out queries on behalf of the developer, or just assume the developer knows what they're doing and do the best it can with what it was given. For good or bad, SQL is definitely a "shoot yourself in the foot" language. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
