On Tue, 3 Sep 2013 18:37:42 -0500 Nico Williams <n...@cryptonector.com> wrote:
> > There's no need to qualify string literals, as it turns out. SQLite > > makes a reasonable choice in that context. When comparing a string > > literal to a column, the literal (in effect) takes on the collation > > of the column. > > But SQLite3 is dynamically typed. Consider a query that uses a UNION > query as a table source, where the corresponding columns of the > sub-queries use different collations. Each column has a type, and every character column has a collation. Each individual value, each row, is compared to the string literal on its own terms. When you say where NAME = 'George' the only reasonable thing to do is to compare each NAME with 'George'. Even if different NAMEs have different collations (as in a UNION, perhaps), each individual NAME has a particular collation, which governs the comparison. > It's easy to build contrived (and real) queries where SQLite3 can't > keep track of a collation -- not at run-time, much less at query > compile-time. I might regret this, but if it's easy could you perhaps provide an example? --jkl _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users