On Thu, Feb 13, 2014 at 11:44 AM, Clemens Ladisch <clem...@ladisch.de> wrote: > By design, SQLite uses dynamic typing, and keeps only the actual type of > the value. The declared type is a property of the *column*, not of the > value itself, so it is lost as soon as the value is no longer associated > directly with the table.
But the fact that SQLite values are dynamically typed is orthogonal to making a best-effort to carry the column typing through intermediate result sets (which are logically just like tables). The query parser obviously knows how to resolve columns to fetch the right values, so it could carry those columns declared type (if any) along, more often than it does now. Whether a query is ordered and must use a temporary table for sorting shouldn't matter IMHO, for example. I know the doc is careful to make little promises in this, yet it feels to me that it's more an implementation issue, than a design issue. And by that I'm not saying that the implementation is at fault or buggy, not at all, but when considering this problem logically with no regard for implementation concerns or how the VDBE VM works, there are clearly cases SQLite could know the declared type of the outermost select clause "columns", and does not currently provide it. I completely understand coding efforts going into other directions, but this is again does not feel like "by design" to me. My $0.02. --DD _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
